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:Like this <https://wiki.mozilla.org/User:David_Regev/Firefox_ZUI>? :)
> 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?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
The other similarity to Google Reader is that each item has a border and a
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 anHave you seen Ubiquity’s introductory
> 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)?
It’s very cool. But I’ll answer in more detail:
There are many reasons. This has been written about extensively elsewhere.
You’ve undoubtedly seen interfaces like this before. Isn’t Google really a
But the most fundamental advantage to Ubiquity is that it’s ubiquitous
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)? ItIf you copy and paste a lot, Ubiquity should learn what you want to do with
> seems pretty cumbersome having to type copy and paste everything time you
> needed to perform this common action.
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.