Fwd: Re: tigert's mockups and HTML

Thu Sep 23 10:30:49 EEST 2004

On Wed, 2004-09-22 at 13:19 +0300, Tuomas Kuosmanen wrote:
> On Tue, 2004-09-21 at 14:24 -0400, Sean Middleditch wrote:
> > The entire toolkit can be abused.  We live with just having a HIG and
> > admonishing developers that make fugly/unusable apps.  Given that
> > HTML/images _can_ be used for some impressive notifications that not
> > only are pretty, but also packed with useful and relevant information,
> > it seems a shame to ban them just because some developers may be
> > tasteless or incompetent.
> 
> Yeah, this is exactly my point. Just because the spec allows you to eat
> as many burritos as you can for a fixed price does not mean you should.
> 
> But it would be just silly to try to restrict developers by making a
> spec that does not allow anything. That causes people to just reinvent
> the wheel with the fancy chromed hubcaps themselves.. :

So which spec are we to specify?  HTML 4.0?  XHTML 1.1?  Which level of
CSS is going to be required?  By passing the buck and saying "we support
HTML" (which nobody will), you'd be creating the same guess-and-check
crap that web developers deal with.  Application developers will have to
check to see how their HTMl renders in GNOME, and how it renders in KDE,
etc.  Because there will be differences.

And you're *NOT* going to support HTML.  You want little fragments that
resemble HTML markup.  You're not actually proposing every notification
be wrapped with <html> and include a <head> and <body> and all that
stuff, are you?  If you're not, then you are NOT proposing we use HTML.

Which then leads us to messages like this:

Your computer is about to explode!  <p>Exploding computers can cause
harm to you and your immediate surroundings.</p>  It is recommended that
you leave the area of your computer immediately.

Now how does our "HTML" renderer interpret this wondeful pernicious
mixed content?  "Oh, I see some text, all right.  Oh wait, a block-level
element.  I guess I should stick the text before this in some sort of
block as well.  Hmm, now more raw content."

> It is not about overkill content. Like Sean said so well, it is about
> small things to make a snippet of information easier to read and
> understand with a glance. Having means to display rich content makes it
> possible. Read "Envisioning Information" by Tufte if you want to
> realize your designer skillz suck.. ;)

Design Schmesign.  How many books do you want me to reference that will
show this is a bad idea from a document markup point of view?  This
ain't art class.  We have to deal with the practical constraints of what
verious types of markup actually accomplish.

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.

> Besides, speed is not the worst issue here, if your friend becomes
> online, it is not a disaster if the popup shows up a whopping 2 seconds
> later. Or if your battery is about to end, it's not a question of
> milliseconds. Memory usage is the bigger problem here, but we should try
> to make Gecko more efficient then - having a HTML renderer is useful for
> a lot of things. We have one in the help system too.

Well, that's fine for Gnome.  Almost.  I mean, Yelp uses gtkhtml2, and
Evolution uses gtkhtml3.  And despite the similarity in name, they have
almost nothing to do with each other.  And then we have Gecko for our
web browser.  So yeah, we have three renderers to choose from.  And KDE
has khtml going on, so they'll manage as well.

What about more lightweight desktops like XFCE?  The actual users are
very likely running a web browser or something, but as far as I know,
XFCE doesn't have an HTML renderer in its dependancy stack.  So is this
actually an effort to have massive cross-desktop compatibility, or is it
just a private little club for KDE and GNOME?

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.

--
Shaun