Fwd: Re: tigert's mockups and HTML

Tuomas Kuosmanen tigert at novell.com
Wed Sep 22 13:18:20 EEST 2004


On Tue, 2004-09-21 at 09:14 -0700, Christian Hammond wrote:
> ----- Forwarded message from Mike Hearn <m.hearn at signal.QinetiQ.com> -----
> 
> - Those mockups appear to assume a very high screen resolution.
>   I'm not convinced packing so much information into a notification
>   like that makes sense, especially when they all have to be equal
>   width in order to look good stacked.
> 
>   Tuomas solves this by not solving it, all his mockups show the
>   notifications sprouting from the tray area, with only one visible
>   at once.

Yes, I have a high resolution screen :-)

But those are just mockups of the notifications themselves. The reason I
am "not solving it" is because I did not think of that part of the
problem yet. We probably need some kind of a "paging" thing that just
contains all the queued notifications in one place instead of filling
the screen with ones :-) That is a separate issue to solve, but is not
related to whether the notes should be HTML or not.

> - What is HTML? Sure there's a spec but we know how well that's
>   followed. You could say XHTML instead, but then that's not
>   actually implemented very much. I think KHTML does not support
>   XML properly for instance.

Whatever that works for, say, Gecko. It'd rock if CSS was supported, it
would make themes possible and easy so the notes could be styled with
your desktop theme.

> - It feels like massive overkill. I don't think it's useful to pack
>   so much text into such a little notification like his Planet
>   Gnome example. It'd be smarter to have just the summary, body
>   and the actions (Send IM | Send mail etc) and then leave the
>   presence and timestamp info for a separate window that pops up
>   when you click it.
> 
> 
> - We actually have code written, debugged (mostly) and working
>   for the current scheme. Allowing arbitrary HTML layout means
>   rewriting most of the current GUI code in the server, especially
>   if you want action links to go anywhere and such.
> 
> In other words, I think allowing arbitrary HTML for notifications has a 
> far higher cost than benefit. If people want to display that level of 
> information it's better done in a dedicated window that pops up when the 
> notification is activated.

Notifications should be passive, meaning they never steal window focus
and do not necessarily need user interaction - so in that sense adding
"more info" buttons that pop up windows and stuff is against our
principle here. 

This is why HTML (or whatever markup) is important here: To be able to
embed richer content to the note, so information can be expressed
better. For example, if you woke your laptop from sleep in the morning,
your IM app could show a notification of your current buddy list when it
reconnects - so you can have an overview of who is online. Having this
table of users and idle times etc be laid out nicely with good
typography and visual layout will make it easier to glance through the
information. It is not just overkill, it is about style and how to
represent data.

> Alternative thought: we could have a request which simply opens up a 
> window then docks arbitrary app-supplied widgetry using XEMBED into it. 
> The server manages window layout/stacking/animation, and the client 
> manages everything else.

That we could also do - like the Dashboard / presence tiles etc would be
great in a mail notification etc.

But the whole idea here is to avoid distraction. When I am working on
for example an icon, I do want to know if Jakub sends me an IM. But I
might be in the middle of something, so having a notification window
come and go is good - I get the idea but I dont have to go and close the
window (or move it aside) to first do my work. I can instead stay
focused on the thing at hand, and once I have a suitable moment, I can
click the GAIM icon to view the queued messages. The notification did
its job - caught my attention  without forcing me to do anything else.

The easier the note is to read and parse through, the better it does its
job. I do feel that having rich content does help in this. It does not
mean everythign will be cluttered - there are people who can design good
stuff. :) Just because the spec ALLOWS you to put all kinds of there,
does not mean you should without a reason.

> However, again, I think it'd be better to have a simpler spec and 
> consistency rather than having a bunch of wierd looking notifications 
> because people wanted to cram more stuff into a little popup than is 
> really usable ...

Weird stuff will and continue to exist :-) Giving a box of crayons to a
kid doesnt make everyone a master painter, but neither does witholding
crayons from everyone to avoid the mess :) If the spec is too
restricting, no applications will use notifications. I think we should
not try to restrict stuff - lets rather focus on giving good toolbox for
people who have interesting, new and good ideas.

//Tuomas

-- 
Tuomas Kuosmanen <tigert at novell.com>




More information about the xdg mailing list