Need to improve UI design process
Blake Ross
Ian Hickson
> Solution: Have someone like Matthew Thomas, Ben Goodger, Jennifer
> Glick, Jesse Ruderman, Aaron Leventhal or myself (per Matthew's
> half-recommendation; I'm not quite as confident ;-) approve front-end
> changes before they're checked in. To alleviate what's sure to become
> an immediate concern: changes will not be rejected because they are
> not perfect; they will instead, be rejected if they don't improve the
> user interface in any way, and instead detract from the usability of
> it (as decided by one of the aforementioned people, or whomever the
> community deems qualified to make such decisions). I talked this idea
> over with Matthew, and he was initially interested in it, but later
> expressed concern that -- as he's already scrambling to catch up with
> all the User Interface Design bugs -- he wouldn't have time to do
> this. I think that, if this system is put into place and works as
> intended, the number of User Interface Design bugs will begin to
> stabilize, because UI will already have been given at least some
> feedback before being modified. The fact that others besides Matthew
> would be able to approve such UI changes would also help (the time
> problem). Lastly, I don't think this is the overwhelming task it
> might seem; daily perusals of Bonsai show that the front end isn't
> changing as much as some might think.
Yes yes yes!!!
--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
Stuart Ballard
>
> Solution: Have someone like Matthew Thomas, Ben Goodger, Jennifer
> Glick, Jesse Ruderman, Aaron Leventhal or myself (per Matthew's
> half-recommendation; I'm not quite as confident ;-) approve front-end
> changes before they're checked in.
Speaking as nobody in particular: This gets my vote! What would it take
to make it official moz.org policy?
Stuart.
Zach Lipton
Pine.WNT.4.31.01041...@HIXIE.netscape.com, "Ian Hickson"
<i...@hixie.ch> wrote:
> On Sat, 14 Apr 2001, Blake Ross wrote:
>
>> Solution: Have someone like Matthew Thomas, Ben Goodger, Jennifer
>> Glick, Jesse Ruderman, Aaron Leventhal or myself (per Matthew's
>> half-recommendation; I'm not quite as confident ;-) approve front-end
>> changes before they're checked in. To alleviate what's sure to become
>> an immediate concern: changes will not be rejected because they are
>> not perfect; they will instead, be rejected if they don't improve the
>> user interface in any way, and instead detract from the usability of
>> it (as decided by one of the aforementioned people, or whomever the
>> community deems qualified to make such decisions). I talked this idea
>> over with Matthew, and he was initially interested in it, but later
>> expressed concern that -- as he's already scrambling to catch up with
>> all the User Interface Design bugs -- he wouldn't have time to do
>> this. I think that, if this system is put into place and works as
>> intended, the number of User Interface Design bugs will begin to
>> stabilize, because UI will already have been given at least some
>> feedback before being modified. The fact that others besides Matthew
>> would be able to approve such UI changes would also help (the time
>> problem). Lastly, I don't think this is the overwhelming task it
>> might seem; daily perusals of Bonsai show that the front end isn't
>> changing as much as some might think.
>
> Yes yes yes!!!
I'll try to ping mpt on irc and get him to look at this since he is
currently email-less. UI:DF QA gives his vote though!
Zach
Steve Morrison
>
> Solution: Have someone like Matthew Thomas, Ben Goodger, Jennifer Glick, Jesse Ruderman, Aaron Leventhal or myself (per Matthew's half-recommendation; I'm not quite as confident
> ;-) approve front-end changes before they're checked in.
It seems as though the UI should have an owner just like other components have owners
with approval rights. I would think this would be someone from UE - I'm surprised that
there isn't more enforcement of specs. I think the problem you might run into is that
developers see feedback from UI folks as just another source of more work, and when
it's a whole lot more work to implement changes they think of as small or inconsequential,
they will say it's not a priority and move on...
-steve
Neil
>Yes yes yes!!!
>
I'll have who^Hat he's having :-)
Gervase Markham
> Jesse Ruderman, Aaron Leventhal or myself (per Matthew's
> half-recommendation; I'm not quite as confident ;-) approve front-end
> changes before they're checked in.
Absolutely.
On a related note, we need some sort of expedited review process for
simple FE changes. FE changes are, by definition, local and are not going
to cause global regressions as might be caused by, e.g. changes to the
parser. Yet still it takes up to two weeks to get a three line Javascript
patch checked in (and I can provide bug numbers if you don't believe me.
:-)
If we don't sort this, we will get a whole bunch of bugs with tiny patches
piling up in UI-DF, waiting for review or super-review.
Anyone got any good ideas on this also?
Gerv
Matthew Thomas
>...
> It seems as though the UI should have an owner just like other
> components have owners with approval rights.
We already do, as <http://mozilla.org/owners.html> shows: Don Melton. Oh
wait, *that* can't be right ...
> I would think this would
> be someone from UE
Really? Someone from who UE, exactly?
> - I'm surprised that there isn't more enforcement
> of specs.
I think there are three main reasons for that.
(1) Perhaps 95 percent of Mozilla's UI isn't covered by a spec. (Where's
the spec for the context menu for HTML form submission buttons? ...)
This leads developers to either (a) guess, or (b) use 4.x as a crib
sheet (which leads to copying 4.x's mistakes as well as its nicer
points).
(2) Those specs which do exist are often very vague, and don't give the
detail required to prevent endless debates in Bugzilla reports.
(3) Where UI changes are suggested and approved, there is not a rapid
process for updating the spec to match. As a result, the specs get
left behind.
> I think the problem you might run into is that developers
> see feedback from UI folks as just another source of more work, and
> when it's a whole lot more work to implement changes they think of as
> small or inconsequential, they will say it's not a priority and move
> on...
>...
Of course. And developers don't notice many of the UI faults in Mozilla
-- firstly because they are very good at dealing with appalling UI (just
look at Bugzilla's UI, for example), and secondly because they are far
too used to using Mozilla to realize what it must be like for someone
using it for the first time.
--
Matthew `mpt' Thomas, Mozilla UI Design component owner
Worse is better! Freedom is slavery! Ignorance is strength!
Blake Ross
have owners
> with approval rights.
It does (Navigator's, anyway). Ben Goodger. He was one of the people I
mentioned.
> I would think this would be someone from UE - I'm surprised that
> there isn't more enforcement of specs.
What UE team? What specs? I'd say the best UE person and spec writer
Mozilla has is Matthew Thomas. He was one of the people I mentioned as
well.
> I think the problem you might run into is that
> developers see feedback from UI folks as just another source of more work,
and when
> it's a whole lot more work to implement changes they think of as small or
inconsequential,
> they will say it's not a priority and move on...
Looking at the UI now, I don't see how it could become _less_ of a priority.
The feedback wouldn't be extensive. At best, it would probably be "why not
align those buttons to the right instead of centering them?" or "How about
putting that label above the tree instead of below?"
If they're not willing to listen to such simple feedback, then sure, they
can move on...without checking in the patch.
--Blake
Niko Pavlicek
I think your system clock is wrong ;-)! I get the following date for
your post: 01/04/18 1:42 and it is 01/04/17 23:47 here and I live in
Germany. But you live in USA, don't you?
Niko!
--
e-mail
: niko_p...@web.de
web
: - http://www.pavlicek.de: private HP
- http://www.html-online.de: Einführung in HTML
- http://www.los-angeles2019.de: Blade Runner Fanpage
----------------------------------------------------------------
Steve Morrison
>
> > It seems as though the UI should have an owner just like other components
> have owners
> > with approval rights.
>
> It does (Navigator's, anyway). Ben Goodger. He was one of the people I
> mentioned.
Ok, someone who isn't direly overworked :)
> > I would think this would be someone from UE - I'm surprised that
> > there isn't more enforcement of specs.
>
> What UE team? What specs? I'd say the best UE person and spec writer
> Mozilla has is Matthew Thomas. He was one of the people I mentioned as
> well.
Well, I thought netscape ue group would be exerting more control over
the UI but, as a reasonable default. But whatever...Maybe my comment is
that it shouldn't have come to this (you folks complaining on the newsgroups)
but it has, so, lets move forward and not bicker about how it should've been...
-s
Peter Trudelle
> Steve Morrison wrote:
> > It seems as though the UI should have an owner ... with approval rights.
>
> We already do, as <http://mozilla.org/owners.html> shows: Don Melton.
Heh. Even if we update that page, let's not confuse XPApps (pronounced
"Nav-i-ga-tor") component ownership with UI ownership.
> > I would think this would be someone from UE
>
> Really? Someone from who UE, exactly?
I thought we had agreed on a couple of UI owners a year ago, Ben Goodger for
mozilla, and German Bauer for Netscape. I'm not sure when/if that changed,
or who the right owners are, but I think that each product needs a
dedicated, strong UI designer, who owns the look/feel/interaction, yea even
the feature set thereof.
> > I'm surprised that there isn't more enforcement of specs.
Take a look around, we don't *enforce* much of anything.
> (1) Perhaps 95 percent of Mozilla's UI isn't covered by a spec. <snip>
> This leads developers to either (a) guess, or (b) use 4.x as a crib
> sheet...
or (c) do whatever pleases them, a common default which is often strongly
influenced by ease of implementation.
> (2) Those specs which do exist are often very vague, and don't give the
> detail required to prevent endless debates in Bugzilla reports.
While detailed specs can be nice, doing them well costs a lot in up-front
time and resources, and doesn't necessarily result in a better
implementation. I think we might actually get optimal results and save
time by sketching out the UI, prototyping in XUL/JS, and refining as we
go. This seems to work pretty well for the best designer/implementers we
have. Of course, as we find out what works, it would be great if someone
would capture the decisions in updated specs.
> (3) Where UI changes are suggested and approved, there is not a rapid
> process for updating the spec to match. As a result, the specs get left
> behind.
Approved by who?
> Of course. And developers don't notice many of the UI faults in Mozilla--
> firstly because they are very good at dealing with appalling UI (just look
> at Bugzilla's UI, for example), and secondly because they are far too used
> to using Mozilla to realize what it must be like for someone using it for
> the first time.
Keep in mind that mozilla developers and other technical contributors are
themselves the target users for mozilla; whereas other derivative products
are trying to reach vastly different customers and end users. What's sauce
for the goose is not always good for the gander.
Peter
Neil
>(c) do whatever pleases them, a common default which is often strongly influenced by ease of implementation.
>
Or by the fact that since the few UI guys (and gals?) that there are
around are so overburdened that I can't even get a decision on messenger
toolbar menubuttons. Fortunately I'm so lazy that I won't make a
decision so you aren't getting any menubuttons :-)
Gervase Markham
> time and resources, and doesn't necessarily result in a better
> implementation. I think we might actually get optimal results and save
> time by sketching out the UI, prototyping in XUL/JS, and refining as we
> go.
This is only possible if it's simple and easy to make the incremental
improvements, rather than being a two-week process from patch to checkin.
<sounds like broken record.>
Gerv
Blake Ross
for
> mozilla, and German Bauer for Netscape. I'm not sure when/if that
changed,
> or who the right owners are, but I think that each product needs a
> dedicated, strong UI designer, who owns the look/feel/interaction, yea
even
> the feature set thereof.
Sure, I agree completely that Ben should be owner. What I don't understand
is why bad UI keeps getting checked in without the UI owner ever being aware
of it (the view source UI being one recent example). Perhaps the easiest
solution here is just to make Ben be the superreviewer for UI (he's
currently only listed for css and skins; at the very least, he should be
xpfe also).
> or (c) do whatever pleases them, a common default which is often strongly
> influenced by ease of implementation.
Yeah, this is what I was trying to prevent with my proposal. XUL is so easy
that spending a couple extra seconds making your UI more usable shouldn't be
a problem. We generally don't accept poor code based on ease of
implementation, so I don't think the case should be any different with the
interface.
> While detailed specs can be nice, doing them well costs a lot in up-front
> time and resources, and doesn't necessarily result in a better
> implementation. I think we might actually get optimal results and save
> time by sketching out the UI, prototyping in XUL/JS, and refining as we
> go. This seems to work pretty well for the best designer/implementers we
> have. Of course, as we find out what works, it would be great if someone
> would capture the decisions in updated specs.
I agree somewhat (although I'd probably prefer prototyping in VB, because
it's a bit easier). I think at this stage it's unreasonable to ask for a
spec for everything, given the resources available, but I think core
features certainly need to be designed in advance. If they're not, you end
up with the same situation we're in now with the autocomplete widget -- it
needs to be completely rewritten because the first one, well, sucked, and
apparently wasn't thought out ahead of time (the same seems to hold true for
wallet, the forms manager, and all that). Not that the second autocomplete
widget is based off a spec either...
> Approved by who?
Well, if my proposal was accepted (which, although it's met positive
feedback thus far, probably isn't going to happen) it would be all or some
of the people I listed, or whomever the community deems qualified to make
such decisions. Keep in mind that this is just entry-level UI approval, of
course, and not meant to establish some dictatorial control over the UI
(which would still be discussed by everyone, as always, in the User
Interface Design component).
> Keep in mind that mozilla developers and other technical contributors are
> themselves the target users for mozilla; whereas other derivative products
> are trying to reach vastly different customers and end users. What's
sauce
> for the goose is not always good for the gander.
Good point.
--Blake
Stuart Ballard
>
> Well, if my proposal was accepted (which, although it's met positive
> feedback thus far, probably isn't going to happen) it would be all or some
> of the people I listed, or whomever the community deems qualified to make
> such decisions.
Which begs[1] the question - what needs to be done to make it happen?
There have been dozens of approving posts and more-or-less zero strong
disapprovals (some implementation concerns but that's all) - so how
would it get made into official mozilla.org policy?
I'm talking about an official change to the policy documents to make
them say that as well as r= and sr=, any change that modified the user
interface would also require uir= from one of the people on your list.
Presumably it would be dri...@mozilla.org who would have to make that
decision - are any of them in on this discussion? Should they be?
Stuart.
[1] Or is it "raises"? I know that phrase is a favorite among
grammar-pedants...
Christian Mattar
I'd say: File a bug under mozilla.org/misc or something.
Then CC drivers and mitchell and annoy them till they agree.
Christian
Henri Sivonen
<blak...@telocity.com> wrote:
> Solution: Have someone like Matthew Thomas, Ben Goodger, Jennifer Glick,
> Jesse Ruderman, Aaron Leventhal or myself (per Matthew's
> half-recommendation; I'm not quite as confident ;-) approve front-end
> changes before they're checked in.
...
> I'd love to hear some community feedback on this.
I think it is a very good idea. UI needs more careful attention.
--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/
Henri Sivonen
<blak...@telocity.com> wrote:
> > I think the problem you might run into is that
> > developers see feedback from UI folks as just another source of more
> > work, and when it's a whole lot more work to implement changes they think of as small
> > or inconsequential, they will say it's not a priority and move on...
>
> Looking at the UI now, I don't see how it could become _less_ of a
> priority.
BTW, to see a visualization of this, take a look at my Mac OS X browser
comparison chart and notice the distribution of green and red in
different parts of the chart:
http://www.pp.htv.fi/hsivone1/OS-X-browsers.html
Ben Goodger
too.
So here's some thoughts
- Most of the patches I've been seeing lately are infrastructure or
syntax changes, and I haven't been seeing a great deal of UI additions,
so I'm not sure how well this would work, but I intend to try it: I'm
going to start requesting a screenshot of proposed UI additions to the
Navigator module before they get checked in. This is to ensure they pass
/basic/ UI and polish guidelines. I'm not going to insist on major UI
overhauls or rewrites in cases where a UI situation already exists just
to make a small change. I will insist however that the small change
doesn't make the situation worse, and is in the right spirit.
Yes there are some parts of the app that need some considerable effort
UI-wise, but I think that at this point, we need to reach a level of
basic polish so we don't send Mozilla 1.0 out the door looking like a
turd.
I expect to draw a hard line on whether or not some UI is allowed to go
into the Navigator component (in this past week I've already requested
one recent change be backed out). I suggest that the other people on
blake's list serve as "UI reviewers" as well. I recommend anyone with a
patch that adds new or unplanned UI clear their basic approach with
someone from this list.
-Ben
Matthew Thomas
>...
> Heh. Even if we update that page, let's not confuse XPApps
> (pronounced "Nav-i-ga-tor") component ownership with UI ownership.
> I thought we had agreed on a couple of UI owners a year ago, Ben
> Goodger for mozilla, and German Bauer for Netscape. I'm not sure
> when/if that changed, or who the right owners are, but I think that
> each product needs a dedicated, strong UI designer, who owns the
> look/feel/interaction, yea even the feature set thereof.
Heh. Even if we have that, let's not confuse UI design with
implementation. It's certainly possible for a good programmer (such as
Ben Goodger) to also be a strong UI designer; but that's no more likely
to be the case than that, say, a construction worker will also be a good architect.
>...
> While detailed specs can be nice, doing them well costs a lot in
> up-front time and resources, and doesn't necessarily result in a
> better implementation. I think we might actually get optimal results
> and save time by sketching out the UI, prototyping in XUL/JS, and
> refining as we go. This seems to work pretty well for the best
> designer/implementers we have.
>...
The problem there is that if you only have incremental improvements and
refinements, you only get to what mathematicians call a `local maximum'
of the (multi-dimensional) usability function. There might be a much
higher peak of usability elsewhere, but you'll never find it because the
path between your local maximum and the highest peak is surrounded by valleys.
For example, I've been thinking through the UI for downloading files for
quite a while (with the help of a couple of other people), and I've come
to the conclusion that the only sane UI -- the only UI which won't break
accepted UI guidelines on Windows or Mac OS in some way -- is to have a
download manager listing current (and previous) downloads
<http://bugzilla.mozilla.org/show_bug.cgi?id=25995>. How can you get
there incrementally from where we are now? You can't. In fact, getting
there would require reversing a number of current or near-future
incremental improvements to the current UI.
>...
> > (3) Where UI changes are suggested and approved, there is not a
> > rapid process for updating the spec to match. As a result, the specs
> > get left behind.
>
> Approved by who?
Currently, they're approved or denied by the module owner. Changing that
situation is what Blake was proposing, but the problem of specs not
being updated would probably exist regardless.
> > Of course. And developers don't notice many of the UI faults in
> > Mozilla -- firstly because they are very good at dealing with
> > appalling UI (just look at Bugzilla's UI, for example), and secondly
> > because they are far too used to using Mozilla to realize what it
> > must be like for someone using it for the first time.
>
> Keep in mind that mozilla developers and other technical contributors
> are themselves the target users for mozilla; whereas other derivative
> products are trying to reach vastly different customers and end users.
> What's sauce for the goose is not always good for the gander.
Firstly, that implies that advanced users wouldn't also benefit from UI
improvements, and I don't think that's the case. Just because developers
are very good at dealing with appalling UI doesn't mean that they're not
*extremely* good at dealing with excellent UI.
Improving Bugzilla's UI a small amount, for example, would result in a
large increase in the number of developers and other technical
contributors who were willing to take part in the QA effort.
Unfortunately, as Mozilla's UI has slowly been getting better over the
past couple of years, Bugzilla's UI has (overall) slowly been getting worse.
Secondly, many of Mozilla's derivative products (Galeon, K-meleon,
Skipstone) go to the trouble of writing their own UI from scratch. What
this means about the state of Mozilla's UI is left as an exercise to the reader.
And thirdly, as I've often said before, the commercial distributors of
XPFE-based Mozilla derivatives (i.e. Netscape -- I can't comment on
Beonex, because I haven't seen it) have, so far, shown themselves to be
utterly incapable of adapting Mozilla's UI to suit less technical users.
Which is why I think that if the Mozilla Organization doesn't produce a
base UI which aims to be suitable for the largest possible number of
users (rather than just the experienced ones), no-one will. And that can
only be bad for the project as a whole.
--
Matthew `mpt' Thomas, Mozilla UI Design component owner
Peter Trudelle
> Peter Trudelle wrote:
> I think that each product needs a dedicated, strong UI designer, who owns the
> > look/feel/interaction, yea even the feature set thereof.
>
> Heh. Even if we have that, let's not confuse UI design with
> implementation. It's certainly possible for a good programmer (such as
> Ben Goodger) to also be a strong UI designer; but that's no more likely
> to be the case than that, say, a construction worker will also be a good architect.
We are certainly in complete agreement there. We already have module owners for the
implementation, hence the need for UI design owners.
>I think we might actually get optimal results and save time by sketching out the
UI, prototyping in XUL/JS, and refining as we go.
> The problem there is that if you only have incremental improvements and
> refinements, you only get to what mathematicians call a `local maximum'
> of the (multi-dimensional) usability function.
Uh, I never proposed limiting changes to incremental improvements. That would be
lame.
> For example, I've been thinking through the UI for downloading files for
> quite a while (with the help of a couple of other people), and I've come
> to the conclusion that the only sane UI -- the only UI which won't break
> accepted UI guidelines on Windows or Mac OS in some way -- is to have a
> download manager listing current (and previous) downloads
> <http://bugzilla.mozilla.org/show_bug.cgi?id=25995>.
Well, when I hear the phrase "the only sane UI", a little bell goes off in my head; but
I agree that lighter weight download feedback is desirable. BTW, I've added a crazy
suggestion to the bug.
> > Keep in mind that mozilla developers and other technical contributors
> > are themselves the target users for mozilla; whereas other derivative
> > products are trying to reach vastly different customers and end users.
> > What's sauce for the goose is not always good for the gander.
>
> Firstly, that implies that advanced users wouldn't also benefit from UI
> improvements, and I don't think that's the case.
Hmm, I didn't mean to imply any such idiocy. My point was that target users for
Netscape and mozilla are very different, so the optimal UI for each may not be the
same.
> Secondly, many of Mozilla's derivative products (Galeon, K-meleon,
> Skipstone) go to the trouble of writing their own UI from scratch. What
> this means about the state of Mozilla's UI is left as an exercise to the reader.
Perhaps this says more about their desire to use Gecko, and their familiarity with
native GUI builders than anything else. Other derivative products use XPFE, with
many (>>3) saying that is what attracted them to mozilla in the first place.
> I think that if the Mozilla Organization doesn't produce a base UI which aims to be
> suitable for the largest possible number of users (rather than just the experienced
> ones), no-one will. And that can only be bad for the project as a whole.
I consider this a very worthy goal; it would be great if mozilla.org (and Netscape)
aimed for it.
Peter
Peter Trudelle
I'm talking about an official change to the policy documents to make
them say that as well as r= and sr=, any change that modified the user
interface would also require uir= from one of the people on your list.
Presumably it would be dri...@mozilla.org who would have to make that
decision - are any of them in on this discussion? Should they be?
Peter
Blake Ross
Henri Sivonen
<trud...@netscape.com> wrote:
> > Secondly, many of Mozilla's derivative products (Galeon, K-meleon,
> > Skipstone) go to the trouble of writing their own UI from scratch. What
> > this means about the state of Mozilla's UI is left as an exercise to
> > the reader.
>
> Perhaps this says more about their desire to use Gecko, and their
> familiarity with native GUI builders than anything else.
No, the main point is using a native GUI *builder*. The point is using
the *native GUI*.
Given the choice between Mozilla with the current non-native UI and a
Cocoa AppKit-based browser embedding Gecko as a subclass of NSView, I'd
immediately choose the one with the AppKit UI.
In Mac user group discussions I have observed people preferring OmniWeb
over Mozilla. And OmniWeb doesn't even support HTML 4 and CSS1! The UI
really counts when the users make their pick.