Novelty and copying (was Re: Status bar, again -- and beyond)
Mike Shaver
I think we should "copy" very heavily from other browsers where they
have addressed something we want to address in a way that fits our
needs: V8's fast number-to-string conversion, Nitro's regexp engine,
everyone's image libraries, various startup optimizations, a number of
design elements in our own JS engines. Some of these come from other
browsers, some from other non-browser technologies or experiences. It
runs both ways, as it should: you can see Firefox design principles in
Chrome and IE, including but well beyond even just the user interface.
V8's vaunted Crankshaft appears...very similar in structure and
design to the HotSpot JVM, and good on them.
Being different from Chrome's UI for the sake of being different is
unwise, and extremely dangerous. It would let them lock us out of
good solutions, among other issues. Just as a programmer's job is not
"write and design code" but rather "produce software", a UX designer's
job is not "come up with something novel" but rather "provide a great
user experience".
It's categorically not a signal at all that our UX team is less
skilled than theirs: nobody (*nobody*) good at their job designs
everything from whole cloth, and everyone good at their job borrows
liberally from solutions that work well, or match our needs at the
time. Having our UX team reinvent something just so that we can say
we're different from Chrome is a waste of scarce resources. We should
be different where the way in which we will be different provides a
lot of value, to our users or to the web, and we should shamelessly --
literally, I mean: without feeling shame -- reuse and learn from the
work of others.
Chrome is a fine baseline, IMO, for addressing some of the things we
wanted to improve in FF4. As with JS performance, in some cases we
will exceed them, but where we can yet an easy win by copying them to
reach parity quickly, it will let us focus our energy on our unique
issues and opportunities (our about dialog, about:addons, the add-on
bar, large-scale tab management, etc.)
Progress display (background tabs, message selection, XHR and other
non-load feedback, etc.) is not a totally solved problem, for any
browser. As we continue to iterate and to deliver that iteration more
frequently, we'll impose both change and differentiation on users, and
there will always be people complaining or mocking that we "just"
copied Chrome, as though interpreting someone else's designs for our
context were easy or inherently wrong. In my opinion, those people
are keeping the wrong score.
I'll reply more specifically to Brendan in a bit, as I have a somewhat
different recollection of various FF3 and later events, and as Firefox
module owner I should be contributing to the public discourse more
than I am.
Mike
sabret00the
> unwise, and extremely dangerous. It would let them lock us out of
> good solutions, among other issues. Just as a programmer's job is not
> "write and design code" but rather "produce software", a UX designer's
> job is not "come up with something novel" but rather "provide a great
> user experience".
Were we different for the sake of being different or did we simply opt to think outside the box? The UX Team spent the best part of a year explaining the rationale behind their decisions in regards to the interface redesign and made some astounding points that won me over on many decisions. The same can't be said for some of the recent reversions/regressions. If the job of the UX Team is to provide a great user experience, why are we doubting our teams ability to do it's job? Yes we can borrow from other browsers, yes we can be inspired by other browsers. But cloning other browsers is a whole different story, especially when such decisions are contrary to all the research and paid man-hours that have gone into the design proposals. Had there have been an issue with the design direction, this stuff should've been discussed in the design phase, not the production phase. And at the very least, make an argument that matches the quality of the reasons behind the original proposal.
Mike Shaver
>> Being different from Chrome's UI for the sake of being different is
>> unwise, and extremely dangerous. It would let them lock us out of
>> good solutions, among other issues. Just as a programmer's job is not
>> "write and design code" but rather "produce software", a UX designer's
>> job is not "come up with something novel" but rather "provide a great
>> user experience".
>
> Were we different for the sake of being different or did we simply opt to think outside the box?
I read your post (the quoted part) as specifically differentiation,
rather than any stifling of creativity by explicitly aiming to match
Chrome's user experience details. Do you think that was an
unreasonable reading of that text?
I agree that the case for the addition of the status-overlay was not
as thoroughly described as one might like, though much of the
explication that I saw for previous changes was post-facto in bugs,
rather than a priori, as I expect will be the case here. I may not be
following the right threads or wiki pages, though, I fully admit.
As far as advocacy goes, bugzilla is just a bad place for long-form,
many-participant discussion, which is why people tell you that it's
not welcome *there*.
Mike
Brendan Eich
The issues I raise are not about copying vs. being original _per se_. There are lots of ways to be original, with most likely to be duds as designs. It's a very large search space.
The issue I tried to focus on was more about process: late implementation vs. design, late-breaking changes, user feedback, more coherent designs triaged to incompleteness and incoherence during a release process.
Of course there's a kernel of design art to this issue: if we broke people's eye-muscle memory in a way that was novel and (by nearly universal acclamation) winning, we would do that. We should want to.
If some other browser does that, good for them -- we can copy.
So in principle we are not bound to look just like other browsers (which all look too much like Mosaic still). We aren't bound to add novelty for its own sake. I hope this is not controversial.
Something else I observed: we don't seem to incrementally improve UI enough. Andreas Gal of all people (no offense, just sayin' -- JIT and GC hacker :-P) just hacked up a patch (https://bugzilla.mozilla.org/show_bug.cgi?id=628179) to make the Find bar go away on page navigation, an easy fix.
In conversations with design folks, I gather the Find bar is considered to have many problems and be in need of a re-design. That goes against long-standing open source memes of incremental improvement and "patch early and often", which we see in other areas more (but not always; old modules do rust and lack of attention anywhere can cause latent bugs to bite).
I don't want to overstate this observation. We surely do make incremental improvements to UI, too. But it seems to me that a combination of conservatism for fear of rocking the boat, and a fairly top-down design orientation that favors putting together a new, boat-rocking-in-a-good-way (but big and hard to realize fully in one release cycle) paper or wire-frame design, make us do less incrementally than we ought.
/be
Omega X
The issue raised ultimately seems to be fear of change and fear of
teaching users new functionality of staple features.
There is little risk when making changes other browsers have already
made. That way, there's no where else for the user to go but backward.
But however, when a change is unfamiliar the risk is higher. Fear sets
in and an opt out is made. This is a risk that Microsoft is taking once
again with Internet Explorer 9's interface. But even as they decide to
take a new direction, its is ultimately mitigated by giving users an opt
out of the change with its tab bar. This is no different than the Tab
Bar position in Firefox 4.
This is also the difference with the current status and link target
location. 1. Placed in the Location Bar, 2. Placed at the bottom in an
overlay. Neither of the two is an option left to users.
Now, no matter what's said here. The upper ranks have made their
decision. No amount of UX Team research and development can change
generations of familiarity it seems. However, at least give the user the
new road and let them take a familiar route should they desire.
A suggestion should it ever be considered may simply be this:
1. Status Text & Link Target in the Location Bar by Default.
2. Status Text & Link Target in the Bottom Left overlay as Option 2.
Create a simple menu item a'la Tab Bar to toggle.
Now whatever is ultimately decided to be default is left up to whatever
private meetings by the Mozilla Illuminati. But not giving the option
after trying to revert functionality this late in the game is a mistake.
--
==================================
~Omega X
MozillaZine Nightly Tester
Brett .
Also, add-ons have forever been spread between either the status bar or the location bar. Adblock's up there, greasemonkey's down there. Why on earth do we want to retain this lack of consistency? Because it's been there since Windows XX from the ninties?
Brendan Eich
How about responding to user feedback, you know, those lab rats you think need retraining for their own good? What I see, ignoring intentions (which are too often "good" on all sides), is a tendency to make design an a-priori system that ignores user feedback.
In this system, negative user feedback can be dismissed, making theory virtually unfalsifiable. Also, I focused on the way larger designs get triaged and incompletely implemented. This is a real problem, even for the status bar removal, which left UX design folks I talked to unhappy with what was actually going to ship.
We need to cast a colder eye on a-priori theory. This is not Mozilla's way. We do a-posteriori science better. And bad user feedback always comes back to project leaders, including lead Illuminatus-of-buck-stopping (me). But I'm not the one who made anyone change anything (again). See Dao's more thoughtful reply nearby in this group.
So, *maybe* the hovered link should be in the URL bar. But it's not a slam dunk, and it's different from all other browsers without nearly-universal acclamation that it wins, and we remove the status bar too late (for 2010 Firefox 4 relealse: yes, August was too late; September definitely; November, everyone knew).
The add-ons bar is now UI deadwood for almost all users, even with hovered link in the URL bar. Was this really the plan? Not from the old threads and bugs I have read. Come on! The status bar removal is from everyone's honest feedback, including UX design and front end people, hardly a stunning success.
Tabs on top had a stronger argument from tested theory as well as obvious practical experience in other browsers. No way are they "the same" as removing the status bar.
Thinking critically about concrete particulars is essential to good design.. Theory and lab-rat games prove little, since you can train rats to do all sorts of silly things.
/be
EE
> I agree with shaver, we should be free to copy. Hyatt credited and copied or synthesized ideas and concrete design elements from Opera, NetCaptor, and OmniWeb in creating the early tabbed browsing in Mozilla and Phoenix. Good designers copy as well as originate.
>
> The issues I raise are not about copying vs. being original _per se_. There are lots of ways to be original, with most likely to be duds as designs. It's a very large search space.
>
> The issue I tried to focus on was more about process: late implementation vs. design, late-breaking changes, user feedback, more coherent designs triaged to incompleteness and incoherence during a release process.
>
> Of course there's a kernel of design art to this issue: if we broke people's eye-muscle memory in a way that was novel and (by nearly universal acclamation) winning, we would do that. We should want to.
>
> If some other browser does that, good for them -- we can copy.
>
> So in principle we are not bound to look just like other browsers (which all look too much like Mosaic still). We aren't bound to add novelty for its own sake. I hope this is not controversial.
>
> Something else I observed: we don't seem to incrementally improve UI enough. Andreas Gal of all people (no offense, just sayin' -- JIT and GC hacker :-P) just hacked up a patch (https://bugzilla.mozilla.org/show_bug.cgi?id=628179) to make the Find bar go away on page navigation, an easy fix.
>
> In conversations with design folks, I gather the Find bar is considered to have many problems and be in need of a re-design. That goes against long-standing open source memes of incremental improvement and "patch early and often", which we see in other areas more (but not always; old modules do rust and lack of attention anywhere can cause latent bugs to bite).
>
> I don't want to overstate this observation. We surely do make incremental improvements to UI, too. But it seems to me that a combination of conservatism for fear of rocking the boat, and a fairly top-down design orientation that favors putting together a new, boat-rocking-in-a-good-way (but big and hard to realize fully in one release cycle) paper or wire-frame design, make us do less incrementally than we ought.
>
> /be
I do not see the point of copying something just because another browser
did it, though. Can a browser not be distinctive and do things its own
way if that is more useful to its users?
If Chrome does away with menu bars, does Firefox have to do that as
well? If Safari puts the reload button on the right end of the address
bar, does Firefox have to do that? If neither Opera nor Safari has a
throbber, does Firefox automatically have to eliminate the throbber?
It seems to me that logic should be used in the browser design. The
status bar was removed supposedly because it took up too much space. It
is therefore replaced by an addons bar which uses even more space. Why
is that logical? Would someone explain that?
Brendan Eich
"I do not see the point of copying something just because another browser did it, though."
No one said that was the reason for any change. We don't mindlessly copy anything that any (one) other browser does; we don't carelessly seek and impose novelty either. Clear?
Now, what is a good design that might be novel and win user acclaim? That I have no easy answer for, but it needs better ways of engaging users (addons, maybe), and a user-testing framework (testpilot).
/be
Dao
> Also, I focused on the way larger designs get triaged and incompletely implemented. This is a real problem, even for the status bar removal, which left UX design folks I talked to unhappy with what was actually going to ship.
It's not just incomplete implementation. The design was faulty, as Jesse
pointed out when it was made public:
http://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/#comment-1951
Super Bisquit
in having a mozilla JIT compiler when LLVM and CLang are available? Have any
of you actually tried building the code on something besides i386 and amd64?
It's shitty and full of holes. It is dependent on x86 only system calls.
A good programmer would assume that better code needs less resources. I've
built firefox 3.6 and xulrunner on a powermac B&W G3 with a 400MHz processor
and 384M RAM. Holy fucking shit, it fucking worked. Oh, and I did this using
FreeBSD.
How long will it be before a small project like xxxterm- which proves to be
more configurable, safer ,and lower on resources- takes the place of
firefox?
Ever think about setting a maximum ram limit on the browser? Running it in a
jailed environment? Having it setup with strict permissions?
It's pretty fucking pathetic when the mozilla developers know less than an
average user.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Brendan Eich
LLVM and Clang are too big and ahead-of-time to implement a JavaScript JIT. Anyone who knows about LLVM knows this (we use LLVM for Rust's back end).
But, I want what you are smoking! Could do without the shitty language you use, though, that's a drag.
PowerPC support for our JS JITs (both of them) are coming, thanks to folks working with Bloomberg -- yes, the Bloomberg terminal has SpiderMonkey in it.
Process isolation is coming too, first to Firefox mobile. But now that I've read your whole worthless rant, I see you are a troll. Bye!
/be
Omega X
> Mozilla Illuminati, good one!
>
> How about responding to user feedback, you know, those lab rats you think need retraining for their own good? What I see, ignoring intentions (which are too often "good" on all sides), is a tendency to make design an a-priori system that ignores user feedback.
>
> In this system, negative user feedback can be dismissed, making theory virtually unfalsifiable. Also, I focused on the way larger designs get triaged and incompletely implemented. This is a real problem, even for the status bar removal, which left UX design folks I talked to unhappy with what was actually going to ship.
Mozilla has done that for years now. Suddenly this is a detriment? All
those years of making changes for the better good and the status bar is
the straw that broke the camel's back? No less THIS close to release?
>
> We need to cast a colder eye on a-priori theory. This is not Mozilla's way. We do a-posteriori science better. And bad user feedback always comes back to project leaders, including lead Illuminatus-of-buck-stopping (me). But I'm not the one who made anyone change anything (again). See Dao's more thoughtful reply nearby in this group.
>
Yes, I have read Dao's input. And I would like to think that no one here
is blaming you personally. But I've been around long enough to see this
happen more than once. Its the same every time a controversial move is
made. A private meeting is held, a decision is made and that's that. The
buck stopper shows up, tells everyone how its going to be and that's the
end. I think the last time it got this bad was when Mike Connor was the
buck stopper.
> So, *maybe* the hovered link should be in the URL bar. But it's not a slam dunk, and it's different from all other browsers without nearly-universal acclamation that it wins, and we remove the status bar too late (for 2010 Firefox 4 relealse: yes, August was too late; September definitely; November, everyone knew).
>
> The add-ons bar is now UI deadwood for almost all users, even with hovered link in the URL bar. Was this really the plan? Not from the old threads and bugs I have read. Come on! The status bar removal is from everyone's honest feedback, including UX design and front end people, hardly a stunning success.
>
How many slam dunks are actually considered "slam dunks" when the
decision is first made? Especially in the browser world? How many of
those implementations were instant successes and how many of them were
won over time?
> Tabs on top had a stronger argument from tested theory as well as obvious practical experience in other browsers. No way are they "the same" as removing the status bar.
>
> Thinking critically about concrete particulars is essential to good design.. Theory and lab-rat games prove little, since you can train rats to do all sorts of silly things.
>
> /be
Not the same? Really? How many browsers actually had Tabs on Top before
it was considered a stronger argument from tested theory? How many of
those lab rats were taught that Tabs on Top was superior before it
became obviously practical?
This is exactly what I was talking about. Waiting for others to follow
through before its considered universally beneficial.
Hopefully whatever is decided in the end is a compromise that everyone
can be satisfied with rather than a just stop gap that no one really wants.
Brendan Eich
Tabs on top was in multiple other browsers, originally in Chrome (because of process-isolated rendering) but then in other browsers. User feedback was mixed to positive.
Link hover status as a potentially cropped URL on the right of a URL bar or Ominbox? No other browsers.
The distance shift from tabs below toolbars to tabs on top was small, too, in pixels or any other measure, compared to the status bar removal's relocation of hovered link URL from bottom left to top right.
Again, this does not mean we can't be first with some innovative UI change. It has to be pretty awesome, though. The status bar removal was not awesome.
/be
Jesper Kristensen
> Are you talking to me? I'm going to assume you're not a troll (which could be a big mistake).
Brendan, could you please either thread your reply or quote the post you
are replying to? It is confusing to read your posts when what you are
replying to is nowhere in sight.
Jesper
Brendan Eich
My reply was to EE's post:
https://groups.google.com/d/msg/mozilla.dev.apps.firefox/BquPhOdPrvs/kbmHRqX9Gd0J
I'm using Google Groups' "new" interface. Is it failing to set References: and other headers correctly? Let's see what it does with this one.
/be
Erunno
for left-to-right readers due to a simple but very noticeable fact:
It's not left-aligned thus offering no fixed starting point from which
users can quickly scan an URL from the beginning like the old
implementation in the status bar does (left lower corner). One always
has to concentrate for a short moment in order to search for the
beginning which gets annoying and taxing fast. And I've read people
complaining about this not only on English forums but on German ones
as well. There's no way around that fact except hand-waving it away
Obi-Wan style ("There is no problem!"). It's actually distressing that
the current design managed to leave the design stage and become
implemented without such glaring issues being addressed. Brendan
actually nailed it: It is an invasive change for little gain except
some for some esoteric design (and maybe security) considerations.
Philip Chee
On 31/01/2011 02:59, Brendan Eich wrote:
> I agree with shaver, we should be free to copy. Hyatt credited and
> copied or synthesized ideas and concrete design elements from Opera,
> NetCaptor, and OmniWeb in creating the early tabbed browsing in
> Mozilla and Phoenix. Good designers copy as well as originate.
FYI: He also copied a lot from Multizilla which introduced tabbed
browsing to the old Mozilla Suite before Hyatt got round to it.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Philip Chee
> PowerPC support for our JS JITs (both of them) are coming, thanks to
> folks working with Bloomberg -- yes, the Bloomberg terminal has
> SpiderMonkey in it.
Actually Cameron Kaiser from TenFourFox is the guy working on the
PowerPC JIT. No idea where you got the idea that Bloomberg was involved.
Brendan Eich
> On Sun, 30 Jan 2011 13:29:44 -0800 (PST), Brendan Eich wrote:
> > PowerPC support for our JS JITs (both of them) are coming, thanks to
> > folks working with Bloomberg -- yes, the Bloomberg terminal has
> > SpiderMonkey in it.
>
> Actually Cameron Kaiser from TenFourFox is the guy working on the
> PowerPC JIT.
Cameron's great. Sorry for not mentioning his work.
> No idea where you got the idea that Bloomberg was involved.
From Bloomberg.
I know, I'm not supposed to know more than you about anything. Yeesh.
At least the troll was humorous, playing buzzword bingo with Clang (C
and C++ offline compiler front end; btw, http://blog.mozilla.com/respindola/),
LLVM (we have people using and contributing to it), and JIT as if they
fit in the same sentence.
/be
Brendan Eich
Man, that was a long time ago.
IMHO hyatt did better than all of his inspirations.
/be
Philip Chee
> On Jan 30, 10:08 pm, Philip Chee <philip.c...@gmail.com> wrote:
>> On Sun, 30 Jan 2011 13:29:44 -0800 (PST), Brendan Eich wrote:
>> > PowerPC support for our JS JITs (both of them) are coming, thanks to
>> > folks working with Bloomberg -- yes, the Bloomberg terminal has
>> > SpiderMonkey in it.
>>
>> Actually Cameron Kaiser from TenFourFox is the guy working on the
>> PowerPC JIT.
>
> Cameron's great. Sorry for not mentioning his work.
>
>> No idea where you got the idea that Bloomberg was involved.
>
> From Bloomberg.
>
> I know, I'm not supposed to know more than you about anything. Yeesh.
Sorry I was the guy who talked Cameron into contributing his TenFourFox
patches to our tree. And I did search bugzilla before talking to Cameron
but perhaps my bugzilla-fu wasn't strong enough. And as I told Mike, I
*thought* I was CCed to the right bug and there was no mention of
Bloomberg there.
sabret00the
> rather than any stifling of creativity by explicitly aiming to match
> Chrome's user experience details. Do you think that was an
> unreasonable reading of that text?
That doesn't make sense to me, it doesn't read right. I'm saying that as professionals, the Chrome UI was considered in full and yet we chose to go in our own direction supported by more than tradition/muscle-memory. You can't stifle change in the name of it being different to what people are used to.
> As far as advocacy goes, bugzilla is just a bad place for long-form,
> many-participant discussion, which is why people tell you that it's
> not welcome *there*.
Personally I find it better than here which doesn't work properly and is wholly harder to follow. I'm a huge advocate of forums, but Google Groups are broken. But ultimately, all that was asked for was the rationale behind the decision.
sabret00the
sabret00the
> did it, though. Can a browser not be distinctive and do things its own
> way if that is more useful to its users?
> If Chrome does away with menu bars, does Firefox have to do that as
> well? If Safari puts the reload button on the right end of the address
> bar, does Firefox have to do that? If neither Opera nor Safari has a
> throbber, does Firefox automatically have to eliminate the throbber?
>
> It seems to me that logic should be used in the browser design. The
> status bar was removed supposedly because it took up too much space. It
> is therefore replaced by an addons bar which uses even more space. Why
> is that logical? Would someone explain that?
The Addon Bar is optional, the Status Bar in it's implementation was fundamental. Also given the way that Addon Bar landed, it seems to take up a lot more room, that will be rectified. Can you use the Addon Bar to retain the functionality of the Status Bar? Yes. Can you use it in a whole new manner? Yes. Do you need it to be there? No.
Jean-Marc Desperrier
> I'm a huge advocate of forums, but Google Groups are broken
You can register instead to the mailing-list as well as to the
newsgroups. The new GG interface that breaks the references is also
awful for those reading the messages :-)
Omega X
They weren't all rhetorical.
But again, it doesn't matter what's said here. The decision was made.
Robert Kaiser
> I'm using Google Groups' "new" interface. Is it failing to set References: and other headers correctly? Let's see what it does with this one.
Apparently, it's failing at that, yes. I have noticed that a lot of the
thread-breaking messages lately comes from Google Groups - they have
suffered from a number of problems for some time, but I guess it got
even worse... :(
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Gervase Markham
> I'm using Google Groups' "new" interface. Is it failing to set
> References: and other headers correctly? Let's see what it does with
> this one.
It's sucking :-( Could you please perhaps work around it for now with
more generous quoting?
Thanks :-)
Gerv