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!
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:
> 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
>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)
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.
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.
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.
>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?
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.
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.
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.
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.
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.
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?
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)?
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:
> 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.
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
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.
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).
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.
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)?
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.
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.
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).
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.
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
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.
>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:
> 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.