Fwd: Re: tigert's mockups and HTML

[Rodrigo Moya]

On Thu, 2004-09-23 at 09:12 -0700, Christian Hammond wrote:
> On Thu, Sep 23, 2004 at 05:00:40PM +0300, Tuomas Kuosmanen wrote:
> > On Thu, 2004-09-23 at 02:30 -0500, Shaun McCance wrote:
> > > Besides that, the last thing we need is some yahoo developers (you know,
> > > the kind that skin their apps) breaking the whole accessibility stack by
> > > setting all sorts of weird colors and crap, "because it looks good".
> > > 
> > > You want *good* design?  Let's face it.  A lot of developers couldn't
> > > design their way out of a paper bag.  We don't make developers reinvent
> > > the look of buttons and menu items.  Because they'll usually do a crappy
> > > job of it.  They create a button with the appropriate function in the
> > > toolkit they're using.  And then it looks like every other button in
> > > every other application.  And it works.
> > > 
> > > Good design comes from developers (authors, content creators, etc.)
> > > specifying the structure of things (which they're really quite good at),
> > > and real designers (like you) saying how that structure should look.
> > 
> > Yeah. What I am suggesting now is something that enables people like me
> > to design stuff. A "toolkit". Not a styleguide. This spec is about the
> > technical building blocks for notifications. I just want to make sure
> > the building blocks are powerful enough.
> > 
> > What we eventually want is stylesheets and a styleguide as of what CSS
> > classes etc to use to make the notifications look good. That is what the
> > developers would use.
> > 
> > Just like how Gnome HIG shows how to make a good looking UI with GTK. 
> > You can do horrible stuff with GTK as well. But when there is the HIG,
> > it is easy for developers to use a consistent style so all Gnome apps
> > look consistent.
> > 
> > > HTML isn't even a very good document markup language, and it certainly
> > > isn't easy to implement well.  HTMl wasn't very good at marking up web
> > > pages, and it was even worse at marking up email.  I really doubt it
> > > would somehow manage to prove itself in simple notification messages.
> > 
> > HTML still is used widely and more or less works. It might not be
> > academically beautiful, but it gets the job done. You suggest we create
> > yet another markup system? 
> > 
> > One of the good things with HTML is that it is familiar for us designer
> > guys, so we can do our part of making the notifications look good. It
> > sounds silly to come up with yet another markup language to learn just
> > for this. And to me it sounds good that we could have CSS to separate
> > the actual content of the message from the representation.
> > 
> > I mean, if the look of the notification would come from a stylesheet and
> > the whole thing would be rendered by Gecko or such, we could just create
> > alternative stylesheet for accessibility needs - like high contrast and
> > large font etc (and just for different "normal" themes too) - this
> > sounds like a good thing to me.
> 
> There are valid points on both sides. I like Rodrigo's idea of having
> html as an extension property. Say, stuffing it in a hint. We don't
> want to require HTML, because that'd be pointless for a lot of
> desktops, but if the implmentation wants to support HTML, by all
> means...
> 
> When I write things like this, I like to think about all the extreme
> situations it can be used in. I have a couple Zaurus PDAs, and I very
> much want to get D-BUS working on that, and Galago, and a notification
> implementation. That's a pretty light-weight device, and I wouldn't
> want an HTML renderer on it. I wouldn't even want to have to parse
> each message to remove the HTML, and *hope* that it still displays in
> some sane form. That's a major issue. Console usage is another.
> 
> So, what do people think of keeping the body simple with maybe basic
> markup (which can be easily filtered out, at least easier than CSS +
> tables + everything else) and adding an html-body hint?
> 
I think a simple markup (like the one used in glib and GTK+ labels)
would work for most cases, and for those which won't work, having the
html body as an extension property would work. So you've got my vote for
doing this :)
-- 
Rodrigo Moya <rodrigo at gnome-db.org>