Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  Messages 1 - 25 of 57 - Collapse all  -  Translate all to Translated (View all originals)   Newer >
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
cyberdees  
View profile  
 More options May 24 2011, 11:26 am
From: cyberdees <cyberd...@gmail.com>
Date: Tue, 24 May 2011 08:26:48 -0700 (PDT)
Local: Tues, May 24 2011 11:26 am
Subject: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
What would web browsers look like today if we redesigned them from
scratch?
That's the question being posed by community member, David Regev — a
philosopher, Firefox enthusiast, and an aspiring interaction designer.

David has composed a blog post explaining his ideas, process and
initial concepts:
http://mzl.la/j1JXnW

Do check it out and get involved in the conversation, today!

Dees / @cyberdees

--
Desigan Chinniah
Firestarter, Innovator & Geek @ Mozilla Labs
http://desiganchinniah.com
+44.77.8643.3785

'cyberdees' on Twitter, Lanyrd, Upcoming, Last.fm, Flickr, LinkedIn


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Pierre  
View profile  
 More options May 24 2011, 12:46 pm
From: Pierre <connect.pwi...@gmail.com>
Date: Tue, 24 May 2011 09:46:49 -0700 (PDT)
Local: Tues, May 24 2011 12:46 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
Really interesting concept, David. Could this be Firefox 8 UI ? ;-)

I think I've already read some of your other suggestions elsewhere, in
particular a ZUI suggestion.

I can see some parts of your concept inspired by other Mozilla Labs
experiments (the unique Firefox/Ubiquity button reminds me of Home
Dash).

I see one minor usability problem : holding a key, the Alt key or
whatever, to enter text, is a bad idea.
How many times do you write an entire sentence (or even a few words)
in full caps while holding Shift ? I never do it. I always use the
Caps Lock instead. I only hold Shift if I have to capitalize only the
first letter of a word. And I guess a lot of people do the same.
Moreover, on some systems, Windows for instance if I'm not mistaken
(it's been a few years I'm on Mac OS X), holding the Alt key and
pressing another key activates the corresponding menu command
(identified by the underlined letter(s) in the menu command).
You should offer an on/off switch for the Ubiquity overlay, something
like a shorcut, preferentially configurable, to show or dismiss the
Ubiquity overlay. Or at least one key to show it, and then let the
overlay dismiss itself after a few milliseconds if no text is entered,
for example.

You should definitely elaborate more on your ideas, even though that's
a good start !
For example, I see a major issue about your suggestion for history
visualization. I've been using Firefox for something like, 4 years. I
visit, say, 100+ pages a day. I've never deleted my history. That
means I would have to scroll a loooooot to find a page that I visited
only 2 days ago. How would you deal with that ?

I can't wait to read the rest of the story ;-)

Sincerely,
Pierre

On May 24, 5:26 pm, cyberdees <cyberd...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Varemenos  
View profile  
 More options May 24 2011, 3:21 pm
From: Varemenos <akl...@gmail.com>
Date: Tue, 24 May 2011 12:21:33 -0700 (PDT)
Local: Tues, May 24 2011 3:21 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
>The location bar has to go
>It has many problems.

name few

>For one, it’s always visible and constantly takes up a large amount of space.

not everyone has a tiny screens. its good to think about low
resolutions but dont forget the rest

>Secondly, it’s hard to read, since people don’t really understand URLs

Ya the first timers dont, but its a very useful tool unless you dont
know how to understand it too.

Sorry if my comment sounds harsh.
Hope you understand that some people find the location bar useful
(just like the 'new' pretty much messed up addon bar in FF4 that
caused many people to go back to FF3.6 cause they miss the old
actually useful one)


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Damien Cassou  
View profile  
 More options May 24 2011, 4:00 pm
From: Damien Cassou <damien.cas...@gmail.com>
Date: Tue, 24 May 2011 13:00:02 -0700 (PDT)
Local: Tues, May 24 2011 4:00 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
If I understand correctly, editing URLs becomes possible only with the
mouse. Previously, one could simply use CTRL+L to edit the URL of the
currently visited page. It's now much slower as the user has to find
the place where the URL of the current page is visible (which is not
necessarily at the top of the document because of the 'Inline Tab
History' feature), hover it, and then press a key.

The rest looks exciting.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
jrbrusseau  
View profile  
 More options May 24 2011, 4:04 pm
From: jrbrusseau <jrbruss...@yahoo.com>
Date: Tue, 24 May 2011 13:04:06 -0700 (PDT)
Local: Tues, May 24 2011 4:04 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
I love the idea of moving parts of the chrome, like the address bar,
inline (like with mobile phones). The Ubiquity aspect is a little too
ahead of it's time for now but when it's ready I'll expect speech
recognition to be used with it.

I'll add that I believe ultimately tabs should be abandoned outright.
I think something like Panorama (Tab Candy) should replaced them in
the future.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 24 2011, 8:28 pm
From: David Regev <david.re...@gmail.com>
Date: Tue, 24 May 2011 20:28:26 -0400
Local: Tues, May 24 2011 8:28 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

Hello again, Pierre. I think you’re the biggest fan of my Firefox ZUI
mockup. It’s great to hear from you.

On Tue, May 24, 2011 at 12:46, Pierre <connect.pwi...@gmail.com> wrote:
> Really interesting concept, David. Could this be Firefox 8 UI ? ;-)

If I could somehow nudge Firefox’s interface in that direction, absolutely.
:)

I think I've already read some of your other suggestions elsewhere, in

> particular a ZUI suggestion.

Cool! In Part 2, I will discuss tab management in greater depth. (You can
see those ideas now if you read the longer piece on the Mozilla Wiki.) Much
of what I have to say is an evolution of those Firefox ZUI ideas. I won’t be
proposing a ZUI, however, as I think I’ve found a better solution, and we
already have a better ZUI(-like) interface in Firefox: Panorama.

I can see some parts of your concept inspired by other Mozilla Labs

> experiments (the unique Firefox/Ubiquity button reminds me of Home Dash).

Yes, the comparison has been made. It’s mostly superficial, though.

I see one minor usability problem : holding a key, the Alt key or whatever,

> to enter text, is a bad idea.

Good point. I should explain the reasoning behind this some more. Ubiquity
is the intellectual descendant of Humanized’s
Enso<http://www.humanized.com/enso/>(created by some of the same
people), which in turn descends from
Archy<http://web.archive.org/web/20080224100153/http://rchi.raskincenter.or...>,
which in turn is based on ideas from Jef Raskin’ *The Humane Interface*. In
both Enso and Archy, issuing a command was done *quasimodally* by holding
down the Command key (mapped to Caps Lock there) and entering the command
while holding the key. This was purposefully designed so that the system
would be modeless. The modal alternative would be pressing the key to bring
the system into Command mode, and then leaving that mode explicitly. All
modal interfaces suffer from the same types of problems, namely, mode
errors: you’re not always aware of what mode the system is in, leading you
to assume the system is in a different mode than it’s in, so the system
reacts to your input differently from what you expect. Additionally, there’s
the added mental overhead of having to keep track of the mode and needing to
exit the mode explicitly. This mental overhead doesn’t exist in a quasimodal
system: entering the quasimode is as easy as holding down a key, and leaving
the quasimode is as easy as letting go of the key. This is why Shift is used
overwhelmingly more often than Caps Lock. Finally, making Ubiquity
quasimodal makes it faster: you never really have to look at the screen to
see what (quasi)mode you’re in or if the system registered your keypress,
since you know physically if Ubiquity is up, based on if you’re holding down
its key. This means that you can type commands almost blindly, and very
quickly.

That’s the theory. In practice, Ubiquity’s developers must have made it
modal for a reason. I have no idea why. (Perhaps someone could chime in for
some background?) Perhaps the benefits of a modeless interface were
outweighed by the discomfort caused by having to type so much while holding
down one key. I don’t know. This is an issue that might actually vary
between people. Partly for this reason, in the wiki page, I suggested that
it should be possible to invoke Ubiquity modally, in addition to the
quasimodal way. I suggested that clicking the Firefox button would run
Ubiquity modally, while some sort of keyboard combination would do the same
(possibly hitting Alt,Alt quickly).

How many times do you write an entire sentence (or even a few words) in full

> caps while holding Shift ? I never do it. I always use the Caps Lock
> instead. I only hold Shift if I have to capitalize only the first letter of
> a word. And I guess a lot of people do the same. Moreover, on some systems,
> Windows for instance if I'm not mistaken (it's been a few years I'm on Mac
> OS X), holding the Alt key and pressing another key activates the
> corresponding menu command (identified by the underlined letter(s) in the
> menu command). You should offer an on/off switch for the Ubiquity overlay,
> something like a shorcut, preferentially configurable, to show or dismiss
> the Ubiquity overlay. Or at least one key to show it, and then let the
> overlay dismiss itself after a few milliseconds if no text is entered, for
> example.

I haven't used Caps Lock in years. :) (I find it’s far more useful when
mapped to Compose.) There’s a reason the key doesn’t even exist on the OLPC
XO. Having both Shift and Caps Lock additionally forces you to choose
between them. That extra time might be minuscule, but it is an additional
mental burden. Besides, in an ideal system, if you want to capitalize a long
string of text, what you would do is this: select the text, and run the *
capitalize* command (via Ubiquity, of course).

In a fully Ubiquitous Firefox, there would be no menus and no obscure
shortcuts. For each action, there would be one and only one command for it,
and there would be no alternative methods of invoking it. That means that
both Ctrl/Cmd and Alt are free for other purposes. And that it why I chose
Alt: it seemed like the most likely to be used by the actual Ubiquity
extension, once every command in the menus has been added to Ubiquity.
Finally, the point of removing the choice between different ways of doing
the same thing is to make the system more
*monotonous*<http://web.archive.org/web/20080221100719/rchi.raskincenter.org/index...>:
you never have to choose between alternate ways of doing the same thing, so
you quickly get used to doing that action, and you learn to do it faster and
faster. It becomes second-nature. It also has the advantage of being more
learnable.

You should definitely elaborate more on your ideas, even though that's a

> good start !
> For example, I see a major issue about your suggestion for history
> visualization. I've been using Firefox for something like, 4 years. I visit,
> say, 100+ pages a day. I've never deleted my history. That means I would
> have to scroll a loooooot to find a page that I visited only 2 days ago. How
> would you deal with that ?

Thanks. Balancing between brevity and too much detail is tough. The wiki
page is definitely on the side of too much detail.

My own browsing habits are very similar to yours (though it’s been 8 years
for me), so I deeply understand where you’re coming from. I’m not completely
sure, however, how what I’ve described would make finding an old page any
less difficult than it is now. Are you referring to the Back/Forward
dropdown? That could theoretically be taken care of by a Ubiquity command,
something like *back* *to* to invoke a list of the previous pages. That’s
just off the top of my head. The truth is that I think that Back/Forward is
broken in a tabbed-browsing environment, and Part 2 will deal with that. My
solution should answer your question (if I understood it correctly), and it
will hopefully also solve the problem of tab proliferation.

I can't wait to read the rest of the story ;-)

> Sincerely,
> Pierre

Thank you!
David

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 24 2011, 8:55 pm
From: David Regev <david.re...@gmail.com>
Date: Tue, 24 May 2011 20:55:30 -0400
Local: Tues, May 24 2011 8:55 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 15:21, Varemenos <akl...@gmail.com> wrote:
> >The location bar has to go
> >It has many problems.
> name few

What I gave in the post is a very short summary of the issues. I described
these issues in much more
detail<https://wiki.mozilla.org/User:David_Regev/Ubiquitous_Firefox#Step_2:_...>on
the wiki page. You might want to read that section, in addition to my
answers below.

>For one, it’s always visible and constantly takes up a large amount of
> space.
> not everyone has a tiny screens. its good to think about low resolutions
> but dont forget the rest

Indeed, but it’s not really about tiny screens (though it’s still more of an
issue on smaller screens). The problem is that the location bar is always
there. It never goes away. Like all administrative debris, it is a
distraction and takes away focus from what’s important: content. A system
where you’re not constantly staring at unnecessary chrome is much more
pleasant to use, regardless of screen size. If we can find an alternative
where this form of administrative debris need not be staring you all the
time, everyone will be better off. And what you care about—content—will have
more room to utilize.

>Secondly, it’s hard to read, since people don’t really understand URLs
> Ya the first timers dont, but its a very useful tool unless you dont know
> how to understand it too.

I think most people don’t, unfortunately. URLs are simply not very
human-readable. Jono Xia wrote a great
post<http://jonoscript.wordpress.com/2010/02/18/some-people-cant-read-urls/>about
it last year. We could try to present URLs in a more readable way, and
there has been some good progress in this area lately, but the location bar
is still a constraint on just how much you can do. For example, a breadcrumb
display of a URL has too many usability issues within the location bar. It
fits much better, however, within the design that I presented.

Sorry if my comment sounds harsh.

> Hope you understand that some people find the location bar useful (just
> like the 'new' pretty much messed up addon bar in FF4 that caused many
> people to go back to FF3.6 cause they miss the old actually useful one)

It’s no problem. I’m a power user as well, and find the location bar
extremely useful. That is why I tried to ensure that my design kept the
location bar’s advantages while removing its many disadvantages. Do you
think I’ve missed something?

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 24 2011, 9:08 pm
From: David Regev <david.re...@gmail.com>
Date: Tue, 24 May 2011 21:08:30 -0400
Local: Tues, May 24 2011 9:08 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 16:00, Damien Cassou <damien.cas...@gmail.com>wrote:

> If I understand correctly, editing URLs becomes possible only with the
> mouse. Previously, one could simply use CTRL+L to edit the URL of the
> currently visited page. It's now much slower as the user has to find the
> place where the URL of the current page is visible (which is not necessarily
> at the top of the document because of the 'Inline Tab History' feature),
> hover it, and then press a key.

Yes, you are correct. I think the benefits outweigh the small decrease in
efficiency for this particular action. After all, there’s no such thing as a
perfect system where every action is optimized to be as fast as possible.
That’s how we got all those obscure keyboard “shortcuts”. Ubiquity offers a
more consistent and sane way, while still being quick.

That said, I think there ways of optimizing for this action a bit while
remaining consistent within the interface. For example, suppose you’re
reading a page, and nothing is selected. You invoke Ubiquity. Ubiquity
should offer you a list of likely commands. One of those could be
*browse*followed by the URL of the current page. If you perform this
action a lot,
that option would be the first.

> The rest looks exciting.

Thanks!

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 24 2011, 9:17 pm
From: David Regev <david.re...@gmail.com>
Date: Tue, 24 May 2011 21:17:02 -0400
Local: Tues, May 24 2011 9:17 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 16:04, jrbrusseau <jrbruss...@yahoo.com> wrote:
> I love the idea of moving parts of the chrome, like the address bar, inline
> (like with mobile phones). The Ubiquity aspect is a little too ahead of it's
> time for now but when it's ready I'll expect speech recognition to be used
> with it.

Thanks. I suspect you’re right. Luckily, most of my design is not really
dependent on Ubiquity. Inline Tab History would still work, as will the
History Scroller (coming in Part 2). And I am *very* interested in finding
people to help me put together some extensions that implement some of these
changes.

Speech recognition with Ubiquity would be awesome! Imagine having that in
mobile Firefox.

 I'll add that I believe ultimately tabs should be abandoned outright. I

> think something like Panorama (Tab Candy) should replaced them in the
> future.

Absolutely! This thought will be even more relevant after Part 2.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Jonathan B  
View profile  
 More options May 24 2011, 4:33 pm
From: Jonathan B <jon.bailey...@gmail.com>
Date: Tue, 24 May 2011 21:33:13 +0100
Local: Tues, May 24 2011 4:33 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

Tabs shouldn't be abandoned, they allow the user to see at a glance what
they have open without performing a gesture or keystroke to open something
like Panorama. It would be like removing the task bar from windows. At least
not currently.

Instead maybe the bookmarks bar and tabs bar should become one, you are
unable to tell a bookmark from a tab. If you open facebook from your
bookmarks bar then it shows that, if you open google from your bar then it
shows that instead. If you then click on facebook icon again instead of
loading facebook it simply brings the previous facebook page you had open,
no loading, and if you had navigated off the homepage to say a photo then it
will show that photo again. Similar to what Apple are doing in OSX Lion, by
hiding the indicator in the dock which shows the application is open. You'd
still have Panorama in order to see all your tabs.

If you open site not on your bookmarks then it adds it to the end of the
bookmarks bar temporarily, similar to pinned and non pinned programs in
windows 7.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
jrbrusseau  
View profile  
 More options May 24 2011, 5:49 pm
From: jrbrusseau <jrbruss...@yahoo.com>
Date: Tue, 24 May 2011 14:49:45 -0700 (PDT)
Local: Tues, May 24 2011 5:49 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
Now that I've had a change to read your more detail Ubiquitous Firefox
Wiki page I can appreciate just how much though you put into this
concept. The "Inline Tab History"/Scrolltabs idea alone is a major
innovation. Combined with Panarama-like Zooming make it all the more
useful. As I said before I love the idea of displaying page
information inline.

It's a real shame that most people will just some up the whole article
as "OMG you're removing the URL bar!!!" without really reading it.
It's a very great idea that I hope to see implemented ASAP.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
fuska  
View profile  
 More options May 24 2011, 6:55 pm
From: fuska <rooo...@gmail.com>
Date: Tue, 24 May 2011 15:55:01 -0700 (PDT)
Local: Tues, May 24 2011 6:55 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
Very interesting ideas. My favourite are ubiquity hints and inline
page info. Inline history seems a bit adventurous, but I'm willing to
play with some experiments when they come

An always visible location bar is very useful, i.e. I miss it on OSX
finder

The quasimodal invocation of ubiquity is going to be polemic (as it
was with Enso) but I'm OK as long as I can customize the key. I rather
use the space key which is bigger, is centred and can be kept down
with both hands. The right arrow key can be used for typing the actual
space.

Hope it helps,
Fuska


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Chrome  
View profile  
 More options May 24 2011, 9:52 pm
From: Chrome <s.wang1...@gmail.com>
Date: Tue, 24 May 2011 18:52:57 -0700 (PDT)
Local: Tues, May 24 2011 9:52 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
I agree too that history visualization could definitely be improved.
For example, currently, the show all history feature in firefox only
allows you to see which sites you visited and when. I would like to
see a more tree-like visualization. So instead of just a list of sites
you visited, it could show that Site A led you to Site B.

Also, can you elaborate on the Inline Tab History part? I use Google
Reader and I'm not too sure what you are referring to. Is this like
bread crumbs?

Regarding the rest of your idea, I don't think I understand the
advantage of a ubiquity like UI for Firefox. I think ubiquity would be
useful for an application like Word where there are hundreds of
features and it is difficult to search for the one you want. However,
Firefox doesn't have that many features anyways and most people only
use a very tiny number of them. So, why would users prefer to type
words to access a particular command when a few clicks would do (I'm
assuming users would prefer less effort)?

Also, will you need to use a command to copy and paste (the humane
interface said that there should only be one way to perform an
action)? It seems pretty cumbersome having to type copy and paste
everything time you needed to perform this common action.

Finally, how will you introduce users to features such as restore
closed tab or restore closed window? Or Private Browsing? Open file?
Save page?


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
S. W.  
View profile  
 More options May 24 2011, 10:28 pm
From: "S. W." <s.wang1...@gmail.com>
Date: Tue, 24 May 2011 22:28:08 -0400
Local: Tues, May 24 2011 10:28 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
Can you elaborate on your inline tab history. I use Google Reader and
I'm not sure what you're referring to. Is this like bread crumbs?

But I definitely think the history can be improved. For instance,
currently in Firefox, "show all history" just lists the sites you have
visited. Wouldn't it be much more useful if the history was shown in a
tree like diagram that tells you that Site A led you to Site B and
etc?

Regarding the ubiquity part, I don't think I understand the purpose of
using ubiquity in a web browser. For a really complicated software
like Word with hundreds of features, ubiquity could help you search
for a feature. However, in Firefox, there are relatively few features
and (as shown in usage heat map) even fewer ones that people use
often. (Especially with Firefox 4, they are grouped much more
logically and with more commonly used features displayed more
prominently). So wouldn't users prefer to click twice or three times
to access that feature through the menu system rather than type
commands into ubiquity (since it's less effort)?

Would you have to type commands copy and paste to perform these
actions (this might get tedious), since the Human Interface does say
that there should be only one way to do things. And how would you
introduce users to other commands (besides Browse) such as private
browsing session, or save page, or open file, or undo closed tab (for
example)?


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Shale Craig  
View profile  
 More options May 25 2011, 1:53 am
From: Shale Craig <shalecr...@gmail.com>
Date: Tue, 24 May 2011 22:53:01 -0700 (PDT)
Local: Wed, May 25 2011 1:53 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?
I think that your idea is an interesting concept, and I believe I've
misunderstood a large part:
(I'm jumping into the discussion late, so if I missed something, tell
me)

In the "Inline Tab History" section of your article, you sketch the
Mozilla logo obscuring a portion of the Google homepage. Is this
intentional?

It would also be great if the logo was draggable (control/command
+drag) to and from any corner.

There may also be an opportunity to reduce the (horizontal) real
estate of individual tabs while keeping text space the same by
applying a "zipper pattern" to the tabs, instead of a "speedbump"
pattern. (zipper - tabs attached to the top and bottom)

On May 24, 9:17 pm, David Regev <david.re...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?" by jiyin yiyong
jiyin yiyong  
View profile  
 More options May 25 2011, 6:20 am
From: jiyin yiyong <jiyinyiy...@gmail.com>
Date: Wed, 25 May 2011 03:20:19 -0700 (PDT)
Local: Wed, May 25 2011 6:20 am
Subject: 回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

i apreciate the ideas
but,i think the tabs need to be redesigned too
in my view,tabs show the count and the sequence of icons
it's a waste of space to use the whole bar


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?" by David Regev
David Regev  
View profile  
 More options May 25 2011, 9:36 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 09:36:38 -0400
Local: Wed, May 25 2011 9:36 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 16:33, Jonathan B <jon.bailey...@gmail.com> wrote:
> Tabs shouldn't be abandoned, they allow the user to see at a glance what
> they have open without performing a gesture or keystroke to open something
> like Panorama. It would be like removing the task bar from windows. At least
> not currently.

Yes, not currently. I specifically chose to keep tabs for these thought
experiments. I think there might be a way to improve Panorama that would
make the tab bar less necessary, but that’s for another time.

Instead maybe the bookmarks bar and tabs bar should become one, you are

> unable to tell a bookmark from a tab. If you open facebook from your
> bookmarks bar then it shows that, if you open google from your bar then it
> shows that instead. If you then click on facebook icon again instead of
> loading facebook it simply brings the previous facebook page you had open,
> no loading, and if you had navigated off the homepage to say a photo then it
> will show that photo again. Similar to what Apple are doing in OSX Lion, by
> hiding the indicator in the dock which shows the application is open. You'd
> still have Panorama in order to see all your tabs.

> If you open site not on your bookmarks then it adds it to the end of the
> bookmarks bar temporarily, similar to pinned and non pinned programs in
> windows 7.

Yes! I proposed something
similar<https://wiki.mozilla.org/Talk:Firefox/4.0_Windows_Theme_Mockups#Merge...>a
while back. It’s kind of similar to what app tabs do, though there’s
no
way to close them while keeping the icon in the same location.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 25 2011, 9:43 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 09:43:21 -0400
Local: Wed, May 25 2011 9:43 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 17:49, jrbrusseau <jrbruss...@yahoo.com> wrote:
> Now that I've had a change to read your more detail Ubiquitous Firefox Wiki
> page I can appreciate just how much though you put into this concept. The
> "Inline Tab History"/Scrolltabs idea alone is a major innovation. Combined
> with Panarama-like Zooming make it all the more useful. As I said before I
> love the idea of displaying page information inline.

> It's a real shame that most people will just some up the whole article as
> "OMG you're removing the URL bar!!!" without really reading it. It's a very
> great idea that I hope to see implemented ASAP.

Thank you! I commend you for reading the entire longer piece. How many cups
of coffee were needed to get through it? :)

I would love to get some of these ideas implemented very soon. I think much
of this can be recreated via a few extensions, each implementing a specific
self-contained piece of the puzzle. I’ll talk more about that in Part 2. For
now, anyone who wants to work on extensions should definitely contact me (or
comment here).


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 25 2011, 11:18 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 11:18:03 -0400
Local: Wed, May 25 2011 11:18 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 21:52, Chrome <s.wang1...@gmail.com> wrote:
> I agree too that history visualization could definitely be improved. For
> example, currently, the show all history feature in firefox only allows you
> to see which sites you visited and when. I would like to see a more
> tree-like visualization. So instead of just a list of sites you visited, it
> could show that Site A led you to Site B.

Like this <https://wiki.mozilla.org/User:David_Regev/Firefox_ZUI>? :)

Also, can you elaborate on the Inline Tab History part? I use Google Reader

> and I'm not too sure what you are referring to. Is this like bread crumbs?

What Google Reader changed from many older readers (including the first
version of Google Reader) was the move from displaying one news item at a
time to displaying a ‘river of news’. So, instead of replacing the entire
content area with each new item every time you want to read something else,
all items are displayed together one right after another. The big advantage
is that you can just scroll down to read new things, and going back is as
simply of scrolling up. So, what you’re viewing is no longer a single news
item but a river of news items. This can also be compared to Gmail’s
transition from single messages to conversations. We can do the same for
tabs: the tab no longer represents a single page, but a whole history of
related pages.

The other similarity to Google Reader is that each item has a border and a
header.

 Regarding the rest of your idea, I don't think I understand the advantage

> of a ubiquity like UI for Firefox. I think ubiquity would be useful for an
> application like Word where there are hundreds of features and it is
> difficult to search for the one you want. However, Firefox doesn't have that
> many features anyways and most people only use a very tiny number of them.
> So, why would users prefer to type words to access a particular command when
> a few clicks would do (I'm assuming users would prefer less effort)?

Have you seen Ubiquity’s introductory
video<https://mozillalabs.com/blog/2008/08/introducing-ubiquity/>?
It’s very cool. But I’ll answer in more detail:

There are many reasons. This has been written about extensively elsewhere.
It all goes back to *The Humane Interface*, which ultimately led to
Ubiquity. Alex Faaborg wrong a great
piece<http://blog.mozilla.com/faaborg/2007/07/05/the-graphical-keyboard-use...>on
these types of interfaces a few years ago (pre-Ubiquity, I think). I
will
try to give a brief outline of the reasoning for this type of interface, but
I apologize if I fail to do it justice. It goes back to the advantages that
the command-line interface has over most graphical interfaces. For one, it’s
infinitely extensible: you can easily add a command without adding any
visual bloat whatsoever. With graphical interfaces, doing so would require
you to add yet another menu item or toolbar button or some other widget.
Secondly, it’s consistent. You issue commands by typing commands. With
graphical interfaces, you have to learn how to access each command: menu,
context menu, toolbar button, click, double-click, swipe, Ctrl-Alt-Shift-µ,
etc. It’s a lot to remember, and kind of a pain. On the other hand, command
lines have many problems, and I don’t think it’s necessary to list them
here. What Ubiquity does is attempt to carry over the advantages while
fixing the disadvantages. For one, instead of obscure commands, you get
natural language commands. The developers put a lot of effort into making
sure that you could use the most human-like sentences and it will guess
accurately what you mean. Secondly, it’s smart. Even if you type just a few
letters, it will suggest the most likely commands that you want to execute,
and learn which ones are most likely based on your behaviour. After a little
bit of training, you’ll be able to run many commands simply by typing just a
few characters, or even just one. Finally, Ubiquity introduces graphical
improvements that the traditional command line lacked, such as an
interactive preview.

You’ve undoubtedly seen interfaces like this before. Isn’t Google really a
textual command interface? People love using it because it’s so smart
(unlike the traditional command line), and so fast. Then there’s Firefox’s
“awesomebar”, which behaves much like the way I just described. It’s a
pleasure to use because it almost knows what I want, and it’s usually faster
than going through the Bookmarks or History menu, even though it’s less
graphical. The basic idea is that a good search implementation is usually
faster than browsing graphically. If you’ve ever used Windows’ search in the
Start Menu, or Quicksilver on the Mac, or GNOME Do, or other similar
interfaces, you know how much more pleasant it is to use these interfaces
over the ‘click, click, click’ way. And this is what Ubiquity tries to do
for the domain of commands.

But the most fundamental advantage to Ubiquity is that it’s ubiquitous
(hence the name). Normally, if you want to modify text in some way that only
your word processor does, you have to run that application (be it Word or
Google Docs) and use that function there. Commands are bound to
applications. So, each new application has to reinvent the wheel, and it
always has to be concerned with bloat. With Ubiquity, this craziness is not
necessary, since commands work everywhere (on the Web, that is). Instead of
running a word processor because you need, for example, to capitalize a
string of text, you install that command and can now run it anywhere.
There’s *a lot* of potential here.

 Also, will you need to use a command to copy and paste (the humane

> interface said that there should only be one way to perform an action)? It
> seems pretty cumbersome having to type copy and paste everything time you
> needed to perform this common action.

If you copy and paste a lot, Ubiquity should learn what you want to do with
just one letter. In fact, if you select a piece of text, I think that just
bringing up Ubiquity should bring up suggestions for that context, with *copy
this* being one of them (and the top choice if you use that command a lot).
So, using those commands should be almost as fast for people who need them a
lot, but not as fast for people who use other commands more often.

Finally, how will you introduce users to features such as restore closed tab

> or restore closed window? Or Private Browsing? Open file? Save page?

Those can all be exposed as commands, combined with well-designed previews.
For closed tabs, something like a searchable Closed Tabs or a History area
in Panorama would be awesome. These types of things should be visualized
graphically when possible, since that allows us to display such information
in a richer way, which is currently not done. Panorama has quite a lot of
potential for that.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 25 2011, 11:25 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 11:25:17 -0400
Local: Wed, May 25 2011 11:25 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 18:55, fuska <rooo...@gmail.com> wrote:
> The quasimodal invocation of ubiquity is going to be polemic (as it was
> with Enso) but I'm OK as long as I can customize the key. I rather use the
> space key which is bigger, is centred and can be kept down with both hands.
> The right arrow key can be used for typing the actual space.

The Alt key is the closest to Space, so I figured it would be the easiest
key on the keyboard to hold down while typing. Even then, I can definitely
see how it would be difficult to make full use of Ubiquity’s
natural-language commands and interactive previews if you have to hold down
a key the entire time. Even so, I think we should try to avoid modal
interfaces when we can. Ubiquity’s modality is pretty mild as far as modes
go, but I would still like to try and see if we can make it work
quasimodally.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 25 2011, 11:39 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 11:39:03 -0400
Local: Wed, May 25 2011 11:39 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Tue, May 24, 2011 at 22:28, S. W. <s.wang1...@gmail.com> wrote:
> And how would you introduce users to other commands (besides Browse) such
> as private
> browsing session, or save page, or open file, or undo closed tab (for
> example)?

Discoverability for other commands is not an issue for which I have an
amazing solution. Ubiquity already comes with a page that lists all
available commands. It’s a start, and there are many improvements that can
be done there. In the mockups, I added a little *Help* link to the dialogue.
Discoverability in general is an issue that graphical interfaces already
have. Many users never explore an application’s menus, and thus never learn
new commands without someone teaching them. With Ubiquity, if they want to
perform a certain action, they might actually try typing it in and seeing if
it’s there. If it’s not there, they could search for it and install it.
There’s a learning curve at the beginning for learning how Ubiquity works,
but the pay-off is great. Finally, last I checked, Ubiquity came with a cool
interactive tutorial when you first run it (much like in some video games).

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
David Regev  
View profile  
 More options May 25 2011, 11:53 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 11:53:41 -0400
Local: Wed, May 25 2011 11:53 am
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Wed, May 25, 2011 at 01:53, Shale Craig <shalecr...@gmail.com> wrote:
> I think that your idea is an interesting concept, and I believe I've
> misunderstood a large part:
> (I'm jumping into the discussion late, so if I missed something, tell me)

Not too late at all! I hope to see many more great comments.

In the "Inline Tab History" section of your article, you sketch the Mozilla

> logo obscuring a portion of the Google homepage. Is this intentional?

Yes. In that image, the Google homepage has been scrolled up a bit, so it
extends upwards beyond the display area. I simply made the Firefox button
large, but it can always be redesigned so as not to overlap with the content
area. This was just a mockup, after all.

It would also be great if the logo was draggable (control/command +drag) to

> and from any corner.

The ideal corner could easily be different. Whatever that location is, I
wouldn’t want to introduce yet another preference. Those should be
eliminated as much as possible. Instead of leaving these issues for users to
decide, we should figure out what the best choice is for most people.

There may also be an opportunity to reduce the (horizontal) real estate of

> individual tabs while keeping text space the same by applying a "zipper
> pattern" to the tabs, instead of a "speedbump" pattern. (zipper - tabs
> attached to the top and bottom)

I personally think that the tab bar would work better on the left (without
any text), but that question isn’t that important at the moment for the
problems I am trying to solve.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?" by David Regev
David Regev  
View profile  
 More options May 25 2011, 11:58 am
From: David Regev <david.re...@gmail.com>
Date: Wed, 25 May 2011 11:58:55 -0400
Local: Wed, May 25 2011 11:58 am
Subject: Re: 回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

On Wed, May 25, 2011 at 06:20, jiyin yiyong <jiyinyiy...@gmail.com> wrote:
> i apreciate the ideas
> but,i think the tabs need to be redesigned too
> in my view,tabs show the count and the sequence of icons
> it's a waste of space to use the whole bar

Definitely. Part 2 will present the beginnings of a redesign of how tabs
work. (You can see the mockup that’s coming up on the longer wiki
page<https://wiki.mozilla.org/User:David_Regev/Ubiquitous_Firefox#Step_3b:...>.)
There’s definitely room for improvement beyond that.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?" by Navid Zamani
Navid Zamani  
View profile  
 More options May 25 2011, 4:45 pm
From: Navid Zamani <navid.zam...@googlemail.com>
Date: Wed, 25 May 2011 13:45:02 -0700 (PDT)
Local: Wed, May 25 2011 4:45 pm
Subject: Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

I strongly disagree with what I read here. In the most rational way. :)

[This was originally posted as bug #*659717* <https://bugzilla.mozilla.org/show_bug.cgi?id=659717>. I post it in its entirety, so I don’t have to restructure it just for this.]

Title: *Make Mozilla the team of innovative leaders, instead of the team trying to be like the innovative leaders.*

URL: http://news.slashdot.org/story/11/05/25/1532246/Mozilla-Labs-the-URL-...

As someone who knows a lot about the psychology behind this, I can tell you that this is not meant as a trolling, nor as a insult or as a joke. It’s not attacking, but has the goal to improve the lives and works of the entire community, and all the users of the resulting works.
So even if your alarm triggers go off: This reaction is entirely normal, if one’s self-confidence looks like it’s attacked. Please hear me out anyway. As I respect you, and want to help rather than attack. Otherwise I wouldn’t care so much.

I’ll start like this:
What we see more and more, with Firefox & co, in the last time, is an apparent need, to change things in a certain way, that has a pattern of copying ideas of others, and ignoring that it alienates its users.
How and why is this ignored? Why is this happening?

Looking at the copying: If someone copies someone else, it nearly always is, because the copier feels that the original is superior to his ideas, which he sees as inferior.
This might well be the case. But in this case, it clearly isn’t, as the copied ideas are usually shunned and hated, even by those who previously apparently demanded it loudly.

So how come it’s done anyway? While clear evidence of it being a bad choice, is ignored?
Well, in psychology, we call this – and please don’t be offended, since I myself was a long-time victim of this, and it’s a extremely common thing for geeks — a “inferiority complex”.
Which interestingly, smart people are more susceptible for. (This is known as the Dunning-Kruger effect.)

The reason for this, according to current theories, is that we geeks usually are the weaker and more “un-cool” types in school. Getting bullied by the stronger sports-type guys, etc.
So we start to assume a insecure inferior follower role very early. While the bullies grow up to be “superior” “natural” leaders.
And us trying to be loved and accepted way too hard in the following years, makes it even worse, until it’s deeply ingrained into our behavior.

Even when we were actually superior all along, and now do the cool things, while the leader types either become managers… or burger flippers.

While we, today, still try to be accepted. But more importantly still don’t trust ourselves, and still don’t dare to go out there, and declare our own awesome ideas as /awesome/.
The difference to the copying of mediocre to bad ideas, is that this security and genuine enthusiasm drags people is. They get excited too.
It’s true leadership, and it’s the whole reason Steve Jobs’s product introduction events are so successful, that they created what is now officially declared a cult. (In case you missed the news. ;)

The thing is – and this is backed by decades of experience and studies in social dynamics and psychology – that this all… what we thought would be us… is actually something, we can change whenever we want. It’s not hard-wired. It’s just somewhat ingrained.
But: If the decision is made, to change it, usually it doesn’t stop until the end. Because it becomes a natural trigger, that is fired every time the old behavior kicks in. Until nothing of it is left, and the new behavior is always active. This elegantly compensates for it being ingrained.

⃗≫≫≫ So please… dare to make drastic changes! …but do it because of genuine enthusiasm and the self-security in your very own superiority, based on actually having those superior ideas.
Don’t try to be “as good” as someone else. Don’t even /try/ to be *better*. ≫ BE(COME) *better*. :)

That is all I have to say. I hope I inspired someone, to allow himself, to be as awesome, as he can be. And I hope I made everyone… users and developer alike… a bit happier in their lives, and with their Mozilla services.

And maybe, just maybe, Firefox will rule the world. :)

Reproducible: Always

Steps to Reproduce:
1. Find a big change in e.g. Firefox in the last 12 months. (E.g. the status bar removal, the URL bar removal plans.)
2. Look at the reaction of the users throughout the net.
3. Look at the complete ignorance of the users in following decisions.

Actual Results:  
Mozilla itself degrades its works to second class, by taking the role of a follower of “trends” & co, alienating the biggest part of its user base for the sake of the small lower-end of the Gaussian distribution curve that consists of the loudest and the dumbest ones, until people switch to what will have become the “original”, while the loudest and dumbest ones will still complain. For making life so hard, by them having to breathe, eat, shit, and use a computer... all by themselves *gasp*.

Expected Results:  
Mozilla takes a leadership position, by having the balls and spine, to stand for something efficient rather than just simple without power, and not looking at others, but having others look at itself.
Like Apple, minus the evilness, and minus the catering to that lowest end, but instead to all people, quiet too, and the neglected and insulted smart ones.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?" by nleskiw
nleskiw  
View profile  
 More options May 25 2011, 1:00 pm
From: nleskiw <njles...@gmail.com>
Date: Wed, 25 May 2011 10:00:13 -0700 (PDT)
Local: Wed, May 25 2011 1:00 pm
Subject: Re: 回复:Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

>For one, it’s always visible and constantly takes up a large amount of space.

And also tells me the EXACT URL I'm visiting. Useful info and I want
that on the screen at all times.

>Secondly, it’s hard to read, since people don’t really understand URLs.

I do understand URLs and I frequently edit them directly, enter them
directly, and use them to avoid phishing scams.  I demand to know
what's going on behind the scenes at all times.  The only protection
from phishing is constant vigilance.

>Moreover, it’s modal: it has a mode for displaying the current page’s location and a mode for entering your next destination.

So is vi, another tool I love. (You're not saying that Mozilla has
something against vi users are you?)

>It’s not always immediately obvious which mode you’re in and what the current text is indicating, and switching modes is not easy either.

If this confuses you you should reconsider taking basic computer usage
classes.
Ok, fine, let's say you can't afford classes.  Precede the URL with
[You are at:] [Go to:], or change the background colors.
Denote the modes.

>Finally, the destination-entering mode is merely an example of running one command, and we already have a better interface for running commands: Ubiquity.

Better is your opinion.  I would never stand for holding down [Alt]
while trying to edit or type in a URL.  I type with both hands.

Please keep in mind - you are pouring over every little nuance of this
application - the uninformed base of the populace ("people [who] don’t
really understand URLs") are using MSN or Yahoo to go to domains; they
don't care.  They don't want to grasp new innovated concepts.  They
want things to stay the same. If it's different from "The
Internet"(Internet Explorer), they will be even less likely to use
your product and the people who do already use your product are going
to feel alienated.  Their powerful tool is being "dumbed down" for the
masses.

-Nicholas

On May 25, 10:58 am, David Regev <david.re...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Messages 1 - 25 of 57   Newer >
« Back to Discussions « Newer topic