tigert's mockups and HTML
alex at beatniksoftware.com
Thu Sep 23 20:54:26 EEST 2004
So either I am smoking crack, or all the rest of you are. I'm not sure
which is true, but let me try to explain why I think its not me...
1) Notification actions... -Look- at every single screenshot tigert has
produced. Notice that almost all of them have -actions- (some have
multiple) related to the notification. Notice also that performing
actions like "send im", "send mail", "empty trash", cannot be
accomplished by firing up a browser with a url. This means that somehow
you are going to have to attach -code- to their activation. Are you
really willing to make a "How to attach code to html links in a
desktop-neutral, html-renderer neutral setting" spec to complement the
notifications-are-html spec? And then implement this spec for every
2) Embedded widgetry... now, maybe you guys are CSS masters. I am not.
I suspect that most open-source developers are not. Yet you are willing
to force them to use CSS if they want to render say, a progress bar (as
tigert used), or to do dynamic expanding (tigert's newest screenshot).
Instead of letting people use the native widgetry they already know, to
accomplish these things trivially.
Now it seems to me that both of these are solved by using XEMBED.
XEMBED?? Yes, XEMBED.
Let a developer use a desktop's standard widgets. If the developer
wants to render pretty HTML, she can do so by using an HTML widget she
already knows, and can really manipulate, and which best fits the task
at hand. She can connect actions to events in the native widgetry,
using connection points she already understands, and calling the code
she has already written. She can pack widgets together to create a rich
display, without having to learn new languages.
The basic point is this: None of us have any idea what people will want
to do with notifications. Tigert just came up with a use today that
seems to me to be valuable and interesting, and which is -completely
unsupported- by how the spec currently stands (or even what has been
proposed). Are we going to go through the spec alteration process every
time a feature like this comes up?
On Thu, 2004-09-23 at 12:12, 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
> 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?
More information about the xdg