New Theme/UI Work Initiated

4 views
Skip to first unread message

Stephen Horlander

unread,
Feb 21, 2010, 11:22:35 PM2/21/10
to dev-apps...@lists.mozilla.org
Last week I filed several bugs for the new Theme/UI work. This project has been in the design stages for the last several months [1].

Dao has already landed the first bug pertaining to the new toolbar button style (https://bugzilla.mozilla.org/show_bug.cgi?id=544999).

Now that bugs have been filed and changes are making their way into the tree I was hoping we could have a centralized location for discussion. Discussing the implementation and impressions here instead of scattered over multiple bugs.


Initial Bugs for Reference:
* #544815 (https://bugzilla.mozilla.org/show_bug.cgi?id=544815) - Allow for placing Tabs over the Navigation Bar with option for Tabs under the Navigation Bar
* #544816 (https://bugzilla.mozilla.org/show_bug.cgi?id=544816) - Attach combined Stop/Go/Refresh button to the Location Bar
* #544817 (https://bugzilla.mozilla.org/show_bug.cgi?id=544817) - Create Bookmarks Widget with placement dependent on Bookmarks Bar status
* #544818 (https://bugzilla.mozilla.org/show_bug.cgi?id=544818) - Progress “Line” indicator for background loading tabs
* #544819 (https://bugzilla.mozilla.org/show_bug.cgi?id=544819) - Create a basic Home Tab linking to the current Home Page
* #544823 (https://bugzilla.mozilla.org/show_bug.cgi?id=544823) - [Meta] Theme Visual Refresh
- #544820 (https://bugzilla.mozilla.org/show_bug.cgi?id=544820) - [Windows] Theme Visual Refresh
- #544821 (https://bugzilla.mozilla.org/show_bug.cgi?id=544821) - [OS X] Theme Visual Refresh


[1] https://wiki.mozilla.org/Firefox/Projects/3.7_and_4.0_Theme_and_UI_Revamp

Mike Beltzner

unread,
Feb 22, 2010, 2:20:29 AM2/22/10
to Stephen Horlander, dev-apps...@lists.mozilla.org
On 2010-02-21, at 8:22 PM, Stephen Horlander wrote:

> Now that bugs have been filed and changes are making their way into the tree I was hoping we could have a centralized location for discussion. Discussing the implementation and impressions here instead of scattered over multiple bugs.

Sounds good to me! Are there particular topics that are currently under discussion? Maybe provide a precis and add some links back to bug comments for good measure?

cheers,
mike

Blair McBride

unread,
Feb 22, 2010, 2:58:54 AM2/22/10
to dev-apps...@lists.mozilla.org
Is there a bug for Linux theme refresh?

- Blair

Stephen Horlander

unread,
Feb 22, 2010, 10:41:49 AM2/22/10
to Mike Beltzner, dev-apps...@lists.mozilla.org
On Feb 22, 2010, at 2:20 AM, Mike Beltzner wrote:
> Sounds good to me! Are there particular topics that are currently under discussion? Maybe provide a precis and add some links back to bug comments for good measure?


Some topics that currently have a lot of discussion include:

* Implementation of tabs above/below the navigation bar (https://bugzilla.mozilla.org/show_bug.cgi?id=544815#c27)
* Discussion of new toolbar button style (https://bugzilla.mozilla.org/show_bug.cgi?id=544999#c15)
* Are the proposed colors for the combo stop/go/reload too distracting? (https://bugzilla.mozilla.org/show_bug.cgi?id=544816#c3)
* Merits of progress bars on tabs (https://bugzilla.mozilla.org/show_bug.cgi?id=544818#c5)
* New appearance is bland (https://bugzilla.mozilla.org/show_bug.cgi?id=544820#c8)


- Stephen

Stephen Horlander

unread,
Feb 22, 2010, 10:43:26 AM2/22/10
to Blair McBride, dev-apps...@lists.mozilla.org
On Feb 22, 2010, at 2:58 AM, Blair McBride wrote:
> Is there a bug for Linux theme refresh?

Not yet. There were some lingering questions about some Linux theme aspects. I am updating the mockups+wiki then I will file the Linux bugs (taking a little longer than anticipated).

- Stephen

RyanVM

unread,
Feb 22, 2010, 11:59:30 AM2/22/10
to
One thing I've noticed when playing around with tabs on top using the
Strata 0.6b3 theme on Windows 7 is that the tabs disappear in
ChatZilla. The only way to switch between rooms is to use the menu at
the top. Not sure if it's specifically a theme bug or a ChatZilla bug,
but I figured I'd at least bring it to your attention as something to
look at for when tabs on top becomes official on nightlies.

Gijs Kruitbosch

unread,
Feb 22, 2010, 3:09:17 PM2/22/10
to RyanVM

ChatZilla uses a <tabs> list and a stack of browsers, not a tabbrowser. I'm
guessing that in the browser, Strata hides the ordinary <tabs> and displays
their own "faked" versions which have progress bars etc. etc. (assuming that's
what it does, I've never used it) - but hides the <tabs> so generally that it
takes those in CZ away as well. I doubt that'd be a problem in the Fx 4 theming
case, although I could be wrong.

~ Gijs

Alex Faaborg

unread,
Feb 22, 2010, 6:04:28 PM2/22/10
to dev-apps-firefox@lists.mozilla.org List, Stephen Horlander
Should also note the list of required platform bugs for the new theme
work. Reposting from dev-platform:

> Now that we are starting to implement the theme I've been going
> through the design mockups to find any cases where we need to add
> additional functionality to our platform:
>
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=546831&hide_resolved=1
>
> If anyone is looking for really high value contributions, that list
> of bugs is super important to us (after all without these changes
> all we have are pretty mockups :)
>
> Since we don't really have a release determined for the new theme,
> we can't really set these to block any release in particular yet.
> However all of these platform requirements could be considered
> "blocking the theme," which is the purpose of the meta tracking bug
> 546831


-Alex

On Feb 21, 2010, at 11:20 PM, Mike Beltzner wrote:

> On 2010-02-21, at 8:22 PM, Stephen Horlander wrote:
>
>> Now that bugs have been filed and changes are making their way into
>> the tree I was hoping we could have a centralized location for
>> discussion. Discussing the implementation and impressions here
>> instead of scattered over multiple bugs.
>

> Sounds good to me! Are there particular topics that are currently
> under discussion? Maybe provide a precis and add some links back to
> bug comments for good measure?
>

> cheers,
> mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

AaronMT

unread,
Feb 23, 2010, 3:15:06 PM2/23/10
to
Can someone point to me a bug number or wiki page that discusses the
idea of a joint integration of the location (awesome bar) and the
search box?

Alex Faaborg

unread,
Feb 23, 2010, 4:57:52 PM2/23/10
to AaronMT, dev-apps...@lists.mozilla.org
> Can someone point to me a bug number or wiki page that discusses the
> idea of a joint integration of the location (awesome bar) and the
> search box?


The current goal is to get an alpha quality version of the theme
landed in the nightly build as as possible, so we haven't really taken
that into full consideration yet. There are of course a lot of
advantages and disadvantages, including but probably not limited to:

=Advantages=
-simpler UI in terms of number of elements

-falls back to web search when you can't find something with the
awesome bar

-faster to use, because mentally you don't have to decide which of the
two elements you want to use for your particular search (~50-200ms)

-an integrated bar sets us up nicely for introducing ubiquity style
commands to the Firefox UI, where the user can do things beyond
particular kinds of searches by adding commands (adding an event to
their calendar, placing a VOIP call, adding to their netflix queue,
etc.)

=Disadvantages=
-Many users are scared to edit the text of a bar they don't
understand, in fear of "breaking the code of the Web" so placing "/
B000HZFDPK/sr=1-4/qid=1266811262/ref=noref?ie=UTF8&s=" in what is now
the search bar may effectively (but not literally) take their search
bar away

-It's impossible to immediately start providing search suggestions
without the violating the user's privacy

It seems like there were other aspects to the decision, but that's
everything that comes to mind.

-Alex

Asa Dotzler

unread,
Feb 23, 2010, 5:13:07 PM2/23/10
to
On 2/23/2010 1:57 PM, Alex Faaborg wrote:
>> Can someone point to me a bug number or wiki page that discusses the
>> idea of a joint integration of the location (awesome bar) and the
>> search box?
>
>
> The current goal is to get an alpha quality version of the theme landed
> in the nightly build as as possible, so we haven't really taken that
> into full consideration yet. There are of course a lot of advantages and
> disadvantages, including but probably not limited to:
>
> =Advantages=
> -simpler UI in terms of number of elements
>
> -falls back to web search when you can't find something with the awesome
> bar
>
> -faster to use, because mentally you don't have to decide which of the
> two elements you want to use for your particular search (~50-200ms)
>
> -an integrated bar sets us up nicely for introducing ubiquity style
> commands to the Firefox UI, where the user can do things beyond
> particular kinds of searches by adding commands (adding an event to
> their calendar, placing a VOIP call, adding to their netflix queue, etc.)
>
> =Disadvantages=
> -Many users are scared to edit the text of a bar they don't understand,
> in fear of "breaking the code of the Web" so placing
> "/B000HZFDPK/sr=1-4/qid=1266811262/ref=noref?ie=UTF8&s=" in what is now

> the search bar may effectively (but not literally) take their search bar
> away
>
> -It's impossible to immediately start providing search suggestions
> without the violating the user's privacy
>
> It seems like there were other aspects to the decision, but that's
> everything that comes to mind.
>
> -Alex

Privacy is also a major concern. With "search suggestions" your search
query is being sent to Google or Bing or whoever before you even hit
enter. If you merge search and addressing, you start to have privacy
concerns about addresses being sent to search providers when you didn't
intend.

- A

Alex Faaborg

unread,
Feb 23, 2010, 6:31:53 PM2/23/10
to Asa Dotzler, dev-apps...@lists.mozilla.org
> Privacy is also a major concern. With "search suggestions" your
> search query is being sent to Google or Bing or whoever before you
> even hit enter. If you merge search and addressing, you start to
> have privacy concerns about addresses being sent to search providers
> when you didn't intend.

Right, we would obviously never do that without a specific action
being carried out by the user to indicate that they wanted the
information sent. So for instance, if we had a unified bar and a
notion of ubiquity style commands, the user could enter "google
[search terms]" and then the initial terms would be sent to google,
and the autocomplete results could provide real time suggestions.

The downside is that either typing the command to scope the search
("google"), or using the mouse to set the specific context of the
unified bar to a particular engine, both end up taking more time than
targeting the search bar in the main window.*

So the issue isn't privacy (since we would never violate it) as much
as if people who want search suggestions would prefer a default of
simpler UI that is a little slower to access suggestions, or a more
complex UI (two bars) that can provide search suggestions quickly.

Since the search field on the Home Tab will be providing suggestions,
and will have the focus by default, you could argue that suggestions
still remain the same sequence of actions away (single mouse click,
start typing). However this is a path that search bar users will not
necessarily be familiar with.

Overall I think I'm probably on the side of trying to make a unified
bar work, with the search bar being moved to the customization
palette, but we still need to map out exactly what all of the
potential issues are before we can decide what the best approach is.

-Alex

* This could theoretically end up being offset by the decision time
between the two bars, although it's really hard to capture decision
time and thereby prove that a unified bar ends up saving more time
overall.

Jennifer Boriss

unread,
Feb 23, 2010, 6:48:32 PM2/23/10
to Alex Faaborg, Asa Dotzler, dev-apps...@lists.mozilla.org
We also need to decide empirically if a unified bar integrates with how people search and use the web. I think we should consider the design speculative until we can answer that question. Perhaps it would be useful to make a completely separate build which combines these and recruit volunteers to use it for a more extended period of time as a separate test pilot study. Walk-up user testing unfortunately can't answer the question of what user behavior looks like over an extended period of time, so perhaps asking for guinea pigs could give us insight.

Axel Hecht

unread,
Feb 24, 2010, 2:26:49 AM2/24/10
to
I know that some folks use the suggestions in the bar in replace for a
search, i.e., to use google's calculate stuff, they just hit suggestions
and no real search. That's a techie edge case, of course.

Axel

Asa Dotzler

unread,
Feb 24, 2010, 2:38:44 AM2/24/10
to
On 2/23/2010 11:26 PM, Axel Hecht wrote:
> I know that some folks use the suggestions in the bar in replace for a
> search, i.e., to use google's calculate stuff, they just hit suggestions
> and no real search. That's a techie edge case, of course.
>
I don't think that's just a techie edge case. Suggestions expose
themselves rather well when a user engages with the search bar and I
think people quickly learn the value of using it as a spelling
suggestion tool or a unit conversion tool, etc.

- A

Alex Faaborg

unread,
Feb 24, 2010, 2:46:46 AM2/24/10
to Asa Dotzler, dev-apps...@lists.mozilla.org
While I initially mentioned a way for the user to explicitly opt in
ahead of the search terms being entered (set the context of the bar
with the mouse, or type" google"), we could also explore opting in
after they started typing something. For instance if there are no or
few results, the bottom item could be "Show google suggestions" and
when selected the information is sent. Still not as clean
interactively as having a separate bar, but another potential way to
approach the privacy issue.

-Alex

D-Kalck

unread,
Feb 24, 2010, 3:35:08 AM2/24/10
to
On 24 fév, 00:48, Jennifer Boriss <jbor...@mozilla.com> wrote:
> We also need to decide empirically if a unified bar integrates with how people search and use the web.  I think we should consider the design speculative until we can answer that question.  Perhaps it would be useful to make a completely separate build which combines these and recruit volunteers to use it for a more extended period of time as a separate test pilot study.  Walk-up user testing unfortunately can't answer the question of what user behavior looks like over an extended period of time, so perhaps asking for guinea pigs could give us insight.

Sorry Jennifer, I used the wrong button.
I don't think it need a separate build to run this test pilot study,
Omnibar could be used instead.

Jennifer Boriss

unread,
Feb 24, 2010, 3:56:21 AM2/24/10
to D-Kalck, dev-apps...@lists.mozilla.org
That's a good point, that it's already available as an extension. I know Limi has been using the combined bar for awhile now, with positive results. Perhaps we should be asking users to try out Omnibar and report back to us in a more explicit way.

----- Original Message -----
From: "D-Kalck" <darre...@gmail.com>
To: dev-apps...@lists.mozilla.org
Sent: Wednesday, February 24, 2010 12:35:08 AM
Subject: Re: New Theme/UI Work Initiated

_______________________________________________

Frank

unread,
Feb 24, 2010, 12:26:10 PM2/24/10
to

Well, not much discussion about any of them here I notice, Stephen. :)

Which ones of the above concerns/interests you most? ....and we'll go
from there. I'm happy to discuss any points you like.

- Frank

Gervase Markham

unread,
Feb 25, 2010, 7:36:12 AM2/25/10
to
On 23/02/10 23:31, Alex Faaborg wrote:
> The downside is that either typing the command to scope the search
> ("google"), or using the mouse to set the specific context of the
> unified bar to a particular engine, both end up taking more time than
> targeting the search bar in the main window.*

Pressing Ctrl-K could both focus the unified bar and add the prefix
(e.g. "google " or "bing ") for the current default search provider.

Gerv

k m

unread,
Feb 25, 2010, 7:49:34 AM2/25/10
to
1. Firefox comes with more than one search engine installed. How does
the user change search engines for different queries in a Chrome-like
Omnibar?

2. Will we still have the ability to add many search engines in a
Omnibar-like UI?

3. There doesn't seem much of a difference in screen real estate
between the two tab versions

4. Background tab titles as per the mockups are too dark

5. Considering the fact that most of Firefox's growth comes at the
expense of IE, isn't there a possibility the new users might balk at
learning a different UI (Firefox with default Tabs-on-top)?

Why do we concern ourselves with nativity in Windows when Microsoft,
3rd party developers and most users don't care. It is entirely
different with Mac, but I don't think users want an UI based on
Windows (now please don't ask me for a research to substantiate my
claims, you know very well I cant produce one). Any UI which is
intuitive, pleasant and sleek will be great.

The new mockups are way better than the ugly 3-3.5 UI. Kudos to the UI
team.

Robert Kaiser

unread,
Feb 25, 2010, 8:13:47 AM2/25/10
to
k m wrote:
> 1. Firefox comes with more than one search engine installed. How does
> the user change search engines for different queries in a Chrome-like
> Omnibar?

You mean a SeaMonkey-like smart location bar? :P
(Don't think Chrome has invented everything...)

But yes, that's an interesting question, I wonder about it every time I
think about how we could integrate more of the searchbar functionality
in SeaMonkey's location bar. And I haven't found an ideal solution yet.
Maybe the Firefox folks will. :)

> Why do we concern ourselves with nativity in Windows when Microsoft,
> 3rd party developers and most users don't care.

Good point. Actually, browsers next to media players and MS Office are
usually the first apps where those companies producing both an OS and
apps are breaking native look-and-feel to introduce the next-generation
look-and-feel they are likely to break in those apps first again to
introduce yet another next-generation look-and-feel.

Robert Kaiser

Zack Weinberg

unread,
Feb 25, 2010, 1:37:39 PM2/25/10
to Alex Faaborg, Asa Dotzler, dev-apps...@lists.mozilla.org
Alex Faaborg <faa...@mozilla.com> wrote:

> While I initially mentioned a way for the user to explicitly opt in
> ahead of the search terms being entered (set the context of the bar
> with the mouse, or type" google"), we could also explore opting in
> after they started typing something. For instance if there are no
> or few results, the bottom item could be "Show google suggestions"
> and when selected the information is sent. Still not as clean
> interactively as having a separate bar, but another potential way to
> approach the privacy issue.

Is anyone else familiar with the (now) Webkit-based browser Epiphany?
It has a unified search/URL bar which just puts "Search for <whatever
you typed> on <search engine>" entries at the bottom of its completion
dropdown. One entry for every configured search engine. I found this
enormously more convenient than having to decide which search engine I
wanted before typing keywords (Omnibar) or type and then click to
get the search engine choice (the ff3.5 UI). You don't get
autosuggestions, but I never missed them.

zw

Asa Dotzler

unread,
Feb 25, 2010, 1:40:11 PM2/25/10
to Zack Weinberg, Alex Faaborg, dev-apps...@lists.mozilla.org

This is similar to how the old Mozilla Suite and Netscape 6-8 behaved.
This is also how Fennec works.

Unfortunately, it seems somewhat incompatible with search suggestions as
provided by the search provider unless you have a default or you show
suggestions from each provider.

- A

Robert Kaiser

unread,
Feb 25, 2010, 2:14:53 PM2/25/10
to
Zack Weinberg wrote:
> Is anyone else familiar with the (now) Webkit-based browser Epiphany?
> It has a unified search/URL bar which just puts "Search for<whatever
> you typed> on<search engine>" entries at the bottom of its completion
> dropdown. One entry for every configured search engine.

SeaMonkey has that entry for the one search engine the users defines as
the default, but doesn't it get very large when doing this for multiple
engines?

Robert Kaiser

Alex Faaborg

unread,
Feb 25, 2010, 2:50:28 PM2/25/10
to k m, dev-apps...@lists.mozilla.org
> 1. Firefox comes with more than one search engine installed. How does
> the user change search engines for different queries in a Chrome-like
> Omnibar?

This mockup is really out of date, but gets in the general direction
of how the user could set the context of the bar using the mouse:

http://people.mozilla.com/~faaborg/files/labs/taskFoxi1.png

In retrospect placing the button on the left and inserting the command
word on the right feels strange, it would probably flow better if both
were on the right. I do like how this smoothly transitions users from
being mouse driven to being more keyboard driven.

> 2. Will we still have the ability to add many search engines in a
> Omnibar-like UI?

The entire discussion about a unified bar is super hypothetical at
this point, but yeah I can't imagine we would ever consider limiting
user's options.

> Why do we concern ourselves with nativity in Windows when Microsoft,
> 3rd party developers and most users don't care.

Because the Web browser is one of the most central and important
applications on the user's system, we want it to mesh with it's
surroundings. This isn't really an aesthetic decision as much as an
interactive one. If we expose our brand too much, or do anything that
really makes Firefox stand out from the other general purpose
applications the user is moving between (file system, word processor,
etc.), we run the risk of distracting the user and momentarily moving
their train of thought away from the task they are completing.
Ideally the app mentally fades away, like when you are driving a car
and realize that you haven't been consciously thinking about driving
as your mind has been wandering (but nonetheless were operating the
car perfectly).

Of course the process of starring at a mockup intently and judging it
is pretty antithetical to the notion seeing how a product wears over
long periods of time. But it's important to consider long term usage,
or even better try the nightly builds with the new theme and see how
distracting it is. The overall theory is that good interface don't
impose themselves on the user, they become an extension of the user.

-Alex

k m

unread,
Feb 25, 2010, 4:36:14 PM2/25/10
to
On Feb 25, 6:13 pm, Robert Kaiser <ka...@kairo.at> wrote:
> k m wrote:
> > 1. Firefox comes with more than one search engine installed. How does
> > the user change search engines for different queries in a Chrome-like
> > Omnibar?
>
> You mean a SeaMonkey-like smart location bar? :P
> (Don't think Chrome has invented everything...)

Oops! Sorry I have not used SeaMonkey yet. I will rectify that soon.

@Alex Faaborg

Both the Taskfox mockup and the Omnibar addon can make the Location
Bar look too busy with the Bookmark, RSS, Stop/Reload/Go icons nearby.

>> Why do we concern ourselves with nativity in Windows when Microsoft,
>> 3rd party developers and most users don't care.

>Because the Web browser is one of the most central and important
>applications on the user's system, we want it to mesh with it's
>surroundings. This isn't really an aesthetic decision as much as an
>interactive one. If we expose our brand too much, or do anything that
>really makes Firefox stand out from the other general purpose
>applications the user is moving between (file system, word processor,
>etc.), we run the risk of distracting the user and momentarily moving
>their train of thought away from the task they are completing.
>Ideally the app mentally fades away, like when you are driving a car
>and realize that you haven't been consciously thinking about driving
>as your mind has been wandering (but nonetheless were operating the
>car perfectly).

If a Word Processor and a Browser look similar, there is a possibility
the User might get confused. He would accidentally select the word
processor instead of the browser. When reading articles on the Web it
is sometimes difficult to identify whether the author is using Mac-
Safari or Mac-Firefox in his screenshots. It is only at a second
glance by looking at the icons one can identify the correct browser.
Firefox is losing its brand-identity.

The way Microsoft is Ribbonizing its Apps, in the future for Firefox
to look native it has to implement some sort of Ribbon it its UI. The
iPhone, iPad and Mac have nearly the same UI and it is quite
reasonable to assume OSX 10.7 won’t be dramatically different. But
Win2k, XP, Vista/7, Windows Mobile 6.5, Windows Mobile 7/Zune and the
Office/Live services all have completely different UI (same with Linux
distributions). Nobody knows what Windows 8 UI is going to look like,
it could very well be a mixture of Aero and Zune with a Ribbon. With
Fennec about to be implemented in Android and maybe Windows mobile 7
in the future, it makes sense to have a unique Firefox UI. I don’t
think it is easy on you guys to create separate UIs for the dozens of
OSs Firefox is going to be implemented in the future.

It makes sense to add a native icon for Help, Security, Privacy etc.
but to have similar UIs for a 3rd party Program seems illogical. If
the UI shouldn’t distract the user, the problem is, it is already
distracting. The big back button lends asymmetry to the UI, the orange
App button, differently colored reload/stop/go buttons, pulsing green
progress bars in the background tabs, the same below the navigation
bar in the active tab, yellow/gray bookmark icon, RSS button can all
distract the user. As long as the UI isn’t garish but pleasant to use
with a unique Firefox identity, users wouldn’t have any reason to
complain.

When the Mozilla-Firefox community is actively campaigning for
different causes through various media outlets, one wonders why it
voluntarily sacrifices its identity when it is directly interacting
with the user.

My disagreement is not with the mockups it is with the policy.

Sorry about the rant.

k m

unread,
Feb 25, 2010, 4:41:04 PM2/25/10
to

Alexander Limi

unread,
Feb 25, 2010, 4:51:27 PM2/25/10
to k m, dev-apps-firefox
On Thu, Feb 25, 2010 at 1:41 PM, k m <121...@gmail.com> wrote:

Yes, we are improving the tab behavior:
http://blog.stephenhorlander.com/2010/01/29/tab-animation/

Making the close behavior better is part of that, not shown in those
specific examples, though.

--
Alexander Limi · Firefox User Experience Team · http://limi.net

k m

unread,
Feb 26, 2010, 4:53:34 AM2/26/10
to

Thats great! Seems like a lot of awesomeness to look forward to in
Firefox 4 (D2D, Layers, Jaegermonkey, new UX, etc)

Dawid

unread,
Feb 26, 2010, 9:38:14 PM2/26/10
to
Hello Mr Stephen,

Let me talk about my ideas for the interface which you created.
Obviously I hope to be treated in a serious manner, appropriate to the
work that I spent to invent the things which I invented. Then, I am a
Firefox user for many years and unlike many people on this forum I'm
not a computer scientist or graphic. I'm a one from all simple users
for which you invent things. But now one of us, simple users, invented
a few beautiful things which could seriously make your project better.

I have a new project of the Firefox menu. My idea is really very well
thought out. I recently had another little worse idea. But now my
idea is much better. I also improved my presentation. I would like
very much to know what you think about my ideas. Otherwise, my work
goes to waste. Please, give me a chance to share my ideas with You.
Check my blog: davidpohl.wordpress.com

All are also invited !!!

Dawid

unread,
Feb 26, 2010, 9:38:23 PM2/26/10
to

Peter Lairo

unread,
Mar 1, 2010, 4:48:33 PM3/1/10
to

I have about 20 search engines - 10 of which I use regularly. I have yet
to hear a suggestion for incorporating searches in a unified
URL-search-kitchen-sink-bar that doesn't make things worse.

Sometimes less isn't more. Sometimes it's just less. ;-)
--
Regards,

Peter Lairo

Bugs I think should be fixed ASAP:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444
https://www.mozdev.org/bugs/show_bug.cgi?id=22003

Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis

Peter Lairo

unread,
Mar 1, 2010, 4:49:17 PM3/1/10
to

That will be useless for most users - who never ever ever use shortcuts.

David McRitchie

unread,
Mar 1, 2010, 7:24:49 PM3/1/10
to
Peter Lairo" <Pe...@Lairo.com> wrote in message news:b_-dnSyiZpbBqxHW...@mozilla.org...

> On Thu. 25.02.2010 13:36, Gervase Markham wrote:
>> On 23/02/10 23:31, Alex Faaborg wrote:
>>> The downside is that either typing the command to scope the search
>>> ("google"), or using the mouse to set the specific context of the
>>> unified bar to a particular engine, both end up taking more time than
>>> targeting the search bar in the main window.*
>>
>> Pressing Ctrl-K could both focus the unified bar and add the prefix
>> (e.g. "google " or "bing ") for the current default search provider.
>
> That will be useless for most users - who never ever ever use shortcuts.

I only know of one person who does not use any shortcuts, or at least refuses
to learn any more.

If you don't use Ctrl+K, or ? mark how is one supposed to use Tags.
Okay with me, if you got rid of tags it's the most misused / abused and
inconsistent feature in Firefox. Just thought of a use for them and they
don't work with "+" in bookmarks sidebar of Library list and confuse
practically all users within bookmark properties. Not the least of which
was hiding of keyword which is actually a part of a bookmark; whereas,
tag had to be added by chaining within the database.

To me Google Chrome put themselves into a bad position by removing
the search bar that I don't think they can get out of without adding
extra buttons and drop-downs, and they aren't even present by default.

Ctrl+K is used in Firefox, Google chrome and
Opera. IE uses Ctrl+E, and Safari in Windows uses Ctrl+Alt+F , and
Firefox (also), Opera (also), IE (only) uses Ctrl+E.

But teaching people how to use their browser is a part of browser tutorials, which seem
to have disappeared, in favor of putting the latest additions (often near useless additons
and disfucntional at best) in ones face.

I certainly do not want to lose the search bar as it is useful for redoing
search after checking out webpages or as a notepad to check things out.
Fixing the mess of wasted space on toolbars would go a lot further than removing
useful features. I can have all of my toolbars and icons from extensions and
loads of tabs 1 - 120 or more in less space than the mock-ups. Make that
just over half, unless the title bar was fixed by removing about 5-10 pixels in
height.

k m

unread,
Mar 2, 2010, 5:46:26 AM3/2/10
to
On Mar 2, 5:24 am, "David McRitchie" <firefo...@verizon.net> wrote:
> Fixing the mess of wasted space  on toolbars would go a lot further than removing
> useful features.    I can have all of my toolbars and icons from extensions and
> loads of tabs 1 - 120 or more  in less space than the mock-ups.  Make that
> just over half,  unless the title bar was fixed by removing about 5-10 pixels in
> height.

Yes, reducing the padding will reclaim some space. A Safari-like
tabbar with the tabs hanging from the navigation/bookmark toolbar can
help in further reducing the space usage. Or atleast reduce the
padding in the small button mode, there doesn't seem to be any height
difference between the large and small button modes except for the
back button.

David McRitchie

unread,
Mar 2, 2010, 9:01:26 AM3/2/10
to
"k m" wrote...

Not just a little space between icons, a lot of space, and a LOT more space
is lost on the vertical toolbar heights, especially the navigation bar. Note
I have very large width location bar and search bar and I use them, both
are wider than the combined width of navigation/search bar distributed.
http://www.mvps.org/dmcritchie/icons/ff_colorized_profiles.png
Tabs, compress to smaller than icon size, and can see 28 tabs in the tabs drop-down
plus tab search bar (drop-down not shown).
http://www.mvps.org/dmcritchie/firefox/tabs.htm
Wasted space as seen in Firefox mock-up and of my own toolbars
also please note that I have the title showing on my Title bar, and no win7 effects
http://img15.imageshack.us/img15/9835/20100223mockupcomments.png
Wasted space in toolbars in Firefox, IE, Opera
http://www.mvps.org/dmcritchie/vista/vista.htm
Most of wasted space is in the navigation toolbar, the wasted space on my
own toolbars is in the title bar below the buttons, and text would have to
be centered vertically to save space.
Navigation/Location Bar Minimal Height | userstyles.org
http://userstyles.org/styles/9349


Martijn

unread,
Mar 2, 2010, 11:47:56 AM3/2/10
to David McRitchie, dev-apps...@lists.mozilla.org

Fwiw, large toolbars are not necessarily wasted space for me.
I like big buttons, because it's easier for me to click on them.

Regards,
Martijn


>   _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

David McRitchie

unread,
Mar 2, 2010, 5:35:57 PM3/2/10
to
"Martijn" ...

> Fwiw, large toolbars are not necessarily wasted space for me.
> I like big buttons, because it's easier for me to click on them.

To me wasting space is not a valid option, in any case I 'm sure I would be just as comfortable
with my choices if using a Netbook as I am on my laptop, or using a 20.5 inch monitor to extend
my laptop. This encompasses use of squeezed down toolbars (Styles), and keyboard shortcuts
(both Firefox and Windows) in using Firefox as well as extensions. I have three different styles
for the navigation bar two for me depending on my eyes, and one for presentations so anybody
can read the location bar.


Peter Lairo

unread,
Mar 3, 2010, 1:40:58 PM3/3/10
to
On Tue. 2.3.2010 11:46, k m wrote:
> A Safari-like
> tabbar with the tabs hanging from the navigation/bookmark toolbar can
> help in further reducing the space usage.

Upside-down tabs make no sense at all (the Mac sucks here). The tabs
belong to the pages and thus should be "attached" to the web pages. I'm
baffled anyone would advocate upside-down tabs.

BTW: And what is all this obsession with minimizing vertical space? It's
gone so far as to sacrifice useful functionality (tiny button targets,
no full page title in window header), usability (no dragable window
header), and visual appearance (looks cramped). I feel like I'm watching
lemmings run off a cliff.
--
Regards,

Peter Lairo

The browser you can trust: www.Firefox.com
Reclaim Your Inbox: www.GetThunderbird.com

Reply all
Reply to author
Forward
0 new messages