I'm lost in a mountain of bugmail so this reply is a week or two late,
but never mind.
Gervase Markham wrote:
>...
> 1) UI polish.
>
> <sigh> Where to start? We need to clearly define who the buck stops
> with on the UI. Is it Ben Goodger?
It belongs, like any other aspect of the code, with the relevant module
owner. For Navigator, that is (unofficially) Ben Goodger. For mail/news
(gee, giving that app a decent name might be a nice 1.0 requirement:-),
it is Seth Spitzer (who generally defers to Jennifer Glick on UI
matters). For Composer, it is (IIRC) Charley Manske.
> We need to get specs for
> everything, and get them agreed.
That is impossible for two reasons. Firstly, to write proper specs for
bits of front end, in most cases, takes more time and effort than
actually writing the code for that front end. You need to use English
rather than XUL and JS, you need to come up with mockup graphics, and
you need to explain why you're doing what you're doing.
Secondly, in a free software project nobody will ever agree on anything
UI-related. :-)
> This means people committing to
> writing them, and Netscape publishing its specs for debate.
I would love to be able to disconnect my modem for a couple of months
and write lots of UI specs -- but I'm always haunted by the possibility
that someone, somewhere, may be adding a `Close' button to a window, or
introducing another pestilent confirmation alert in mail/news, or some
other UI evil, when I might prevent it by commenting now. Quick, time to
check my bugmail again ...
>...
> It's difficult to define hard 1.0 criteria for the UI. "All specs in
> <list> implemented"?
>...
Given the current poor state of Mozilla's UI, I'd actually be pleased if
we managed to reach a considerably lower standard than that. I'd like to
see the following three basic conditions met:
(1) All controls which are intended to be visible are visible.
For example, Mozilla's Preferences dialog currently has a top-level
category called `Offline and Disk Sp...'. Explore the subcategories,
and you find such gems as `Helper Applicati...', `Message
Compos...', and `Software Install...'. You can never see the rest of
those labels. Clumsy.
(2) All windows fit in 640*480 by default, without breaking the previous
condition.
For example, the Account Manager currently doesn't come close to
fitting in 640*480, making mail/news pretty unusable if you're on a
laptop or other machine with that resolution.
(3) All visible and enabled UI elements do *something*, even if that
thing is buggy.
For example, when the Page Info window has focus, none of the menu
items do anything at all. That is completely unacceptable.
There are other basic standards we should be meeting, but which we
probably don't have a hope of reaching in the next few months. Pulling
some random benchmarks out of a hat:
- At least half of a random sample of Hotmail users, trained on
Internet Explorer, should be able to use Mozilla Navigator to log in
to their Hotmail accounts within 30 seconds. We would fail this,
because: * the UI is sluggish; * click-selects-all isn't turned on
by default; * the Go button in Navigator's toolbar isn't visible by
default; * pressing Enter doesn't submit a Web page form; * etc.
- There should be no case where we make the user wait for more than
two seconds without giving some sort of feedback that everything is
ok. Currently (on my fairly new 450 MHz iMac, at least) we often
seize up for ten or twenty seconds with nothing more than an
unmoving watch cursor. Compared with the speed and responsiveness
of Internet Explorer 5.5 on my flatmate's '486 Windows box, this is
not very impressive.
- Everything which can be migrated from 4.x should be. Window size and
position, column order in the mail/news thread pane, preferred
fonts, all of these things we should be migrating but currently
aren't.
>...
> 4) End-User Documentation
>
> This is obviously desireable. Do we make it a 1.0 criteria? How much
> is sufficient? Is anyone stepping up to the plate to write a Mozilla
> manual? (In XHTML with funky stuff, naturally.)
>...
Yes, but not until the UI stops moving. Red Hat are having trouble with
this, for example; they're currently trying to write a basic tour of
Mozilla (not to be confused with user help!) for their own distribution,
but they're having trouble with the UI changing under them.
Given that (broadly speaking) no-one reads help docs anyway, getting the
UI right is infinitely preferable to freezing it early for the sake of
help docs. However, if we *do* want decent help docs, we need an
exemption for them to be frozen after the rest of the localized text in Mozilla.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
