Firefox keyboard navigation tricks

I’ve been having some wrist issues lately, so I’ve switched to an ergonomic split keyboard (and made an appointment with an orthopedist). I’m also trying to cut way down on my mouse usage; since I mouse with my right hand and that’s the wrist with worse problems, the mouse is my prime suspect.

But how to navigate the web without using a mouse?

Turns out that many mouse navigation actions can be replaced by the plethora of undocumented keyboard shortcuts hiding inside Firefox. Here are the ones I’ve found most useful; maybe some will prove useful to you too.

(On a Mac, replace “ctrl” with “cmd” in all the following examples.)

• To follow a link via the keyboard: Hit the forward-slash key to enter Quick Search mode. Start typing the text of the link. The first few letters are usually enough. Once the link is highlighted, hit enter.
• To go back: Backspace/delete key.
• To enter a url: ctrl-L to focus the awesome bar, then start typing; optionally use the down arrow – or better yet, the tab key – to select a suggestion, and then hit enter to go to the selected url. (I find the tab key much easier to hit from the home row than the down-arrow key, and they both move down through awesome bar suggestions.)
• To do a search: ctrl-K to focus the search box. I typically hit ctrl-T for a new tab, then ctrl-K to focus the search box, then type my search term, then hit enter to do the search.
• To go to a bookmark: typing “* keyword” into the awesome bar – asterisk, then a space, then the keyword – will filter the awesome bar suggestions to show only bookmarks matching the keyword. You can think of the asterisk as representing the bookmark star icon. The whole interaction is ctrl-T for new tab, ctrl-L to focus the bar, asterisk, space, keyword, tab to select the bookmark, enter key to go to it. Sounds like a lot of work, but for me it’s still faster than hunting through my labyrinthine bookmark menu with the mouse.
• To switch to a tab: much like the asterisk filter for bookmarks, a percent sign will restrict awesome bar matches to currently open tabs. “% keyword” will show only the open tabs that match (by url or page title) the keyword. E.g. I often use “% bug” to show all my Bugzilla tabs. So ctrl-L to focus the bar, percent space keyword, tab key to select the right suggestion, enter key to focus the tab. Again, I actually find this faster than hunting for tabs with the mouse.
• There are many more filters besides * and %, too. You can find them documented at Mozillazine.
• Another way to switch to a tab is by its position: ctrl-1 focuses the leftmost tab, ctrl-2 the second leftmost, etc. I generally don’t find this as useful as switching by names, but it can be great for app tabs, if you always have the same app tabs open in the same order. So for example ctrl-1 for me will always be WordPress, ctrl-3 will be my Zimbra calendar, ctrl-7 is the Test Pilot mercurial repo, etc.

What all these keyboard interfaces have in common is that they’re based on recall, not recognition — they work best if you know exactly what you want, and can call it by name. They’re not very good for things you’re used to recognizing by icon or by spatial location (e.g. if you’re used to getting to a certain page by clicking the second link in your bookmark bar, you’d have some adjustment to do.)

(Not Firefox related, but I’ve also mapped the ctrl key to the caps lock on my keyboard, which makes using Emacs a lot more pleasant, since I no longer have to do contortions with my left pinky to trigger commands there.)

Anybody have any more keyboard navigation tips to share? (Or tips for fighting RSI?) The comments are open.

 

It’s Not About The Version Numbers. (It’s about extension compatibility and long-term support)

“Why did my Firefox suddenly go from 3.6 to 4.0 to 5.0 in the space of half an hour?” asked my friend on the phone, in the middle of what was otherwise a conversation about role-playing games.

“Because the automatic updater system is working?” I said.

“Was Firefox 4 really so broken that you had to kill it after three months?” he asked. Except he used a ruder word than “broken”.

“No, not at all”, I said, remembering the giant launch party we had had for Firefox 4. It did feel kind of like we told everybody “Firefox 4 is the greatest thing ever, and it’s finally here! Download it now! OK now it’s obsolete already.”

“It’s just that we’ve got this new rapid-release schedule going”, I continued, “where we push out the new releases every three months, so that users always have the latest bug fixes and speed improvements and stuff.”

“OK, well, it says that Perapera-kun (the extension I use to translate Chinese) is no longer compatible. I really needed that extension.”

Oops.

 

Design Lunch: Home Tab design post-Firefox-4

Design Lunch is back this week. Back with a vengeance !

John Wayne Hill is one of our interns, working with the User Experience team this summer, and he’s working on the design of the new Home Tab post- Firefox 4. He’s looking for feedback on his ideas for the design.

For some more context on what the Home Tab is going to be, you might want to check out Alex Faaborg’s blog post “Browsing Your Personal Web”, as well as the Winter 2009 design challenge which invited people to submit Home Tab designs.

As always, the Design Lunch is at the Mountain View office, in Ten-Forward, at 12:30pm pacific time this Thursday (June 4). You can watch it remotely on Air Mozilla and/or call in by phone to ask questions; see instructions here.

Hope to see you there!

 

Design Lunch – Alexander Limi on “100 Papercuts”

Alexander Limi recently started a Reddit thread to ask the Reddit hive mind about their pet peeves with Firefox:

What I’m after is more the “one hundred paper cuts”, the stuff that annoys you on a daily basis, and that I could help with getting prioritized as a User Experience / User Interface person.

Over 2300 comments later, Limi has his answers, and those are what he will be sharing with us at this week’s Design Lunch. It will be Thursday at 12:30pm Pacific time, and will be recorded and broadcast on Air Mozilla. Call-in info is here.

 

The Test Pilot menu study and its impact on Firefox

Alex Faaborg writes about how the Test Pilot menu item study is influencing the redesign of the Firefox menu bar.

Nothing much to add right now except to say that it’s very satisfying to see Test Pilot having a concrete impact, and that I’m proud to have been part of this work!

 

Quick update on Ubiquity and Firefox 3.6

In this post I promised a new release of Ubiquity to be compatible with Firefox 3.6. It’s been a while so I thought I should update you on that.

The situation is a little complicated, because there are two “branches” of Ubiquity development: the 0.1 line and the 0.5 line, which differs significantly.

We’ve released an update to the 0.1 line, Ubiquity 0.1.9.1, which works with Firefox 3.6. It can be downloaded from Addons.mozilla.com.

The Ubiquity 0.5 codeline is turning out to be more difficult to update to Firefox 3.6 than we anticipated. (i.e. there are actual incompatibilities that produce parser problems; we can’t just tweak install.rdf and release.) We’re going to have to find some time to do some serious hacking and bug-fixing on it before we can release a compatible 0.5.x version.

Ultimately, I’d prefer to re-merge the codelines and have only a single version; having 2 is confusing and there’s no real reason for it.

But for now, at least you can use Ubiquity 0.1.9.1 on Firefox 3.6.

 

Some People Can’t Read URLs

The site ReadWriteWeb recently did an article called Facebook wants to be your one true login. The contents of this article are something I’ll address in another post. What I want to talk about today has nothing to do with the actual contents of the article, and everything to do with the fact that this article was for some period of time one of the highest hits on Google for the search “Facebook login”.

The comments thread on the article filled up with over a thousand comments from confused and frustrated people asking “Now how do I log in?” and “The new design sucks!”.

That’s right. These people had been relying on a Google search for “Facebook login” to get to the Facebook login page. When they ended up at ReadWriteWeb instead, they didn’t know that they were in the wrong place. They thought that the Facebook login page had changed, and they weren’t happy about it. ReadWriteWeb has now put up a gigantic disclaimer on the article to explain that they are not Facebook and explain how to get there.

This whole chain of events seems destined to go down in Internet history as an amazing pile-up of failure.

Reactions seem divided into two camps. One camp is having a great laugh at the stupidity of the users – after all, how could they look at a page with a red masthead, titled “ReadWriteWeb”, featuring a news article, and think they were on the Facebook login page? How could they be smart enough to figure out how to leave a comment, but too dumb to know what site they were on?

The other camp, for example an article from blogger Funkatron called We’re the stupid ones is pointing the finger at the software world for assuming that everyone knows as much about computers as we do, and more specifically at Google – after all, isn’t this in some way Google’s screw-up for returning the wrong result?

Well, the name of this blog is “Not the User’s Fault”, so much as I would like to have a laugh at stupidity and then move on, I think it’s better to try to understand what this must have been like from those users’ point of view, and see if there’s anything we can learn from the whole boondoggle.

 

Two opinions on 3.6 tab behavior

My wife strongly dislikes the new Firefox 3.6 tab behavior (where tabs opened from links appear immediately to the right of their parent tab, instead of at the extreme right of the tab bar).

I do like the new behavior, because by keeping related tabs closer together, it reduces the amount of time I have to spend interacting with the tab-bar scroll buttons (my least favorite UI element in all of Firefox).

She dislikes it for consistency reasons: when you open a new blank tab, it still appears at the far right. So now tabs can appear in two different places, depending on where you opened them. It violates the principle of consistency, which is generally considered one of the most important UI principles. This inconsistency hasn’t really bothered me personally. I’m not sure why; maybe it’s because opening a tab through a link, and opening a new blank tab, feel like different actions to me. There’s a difference in what I’m thinking about. But I can certainly understand how it feels like a consistency violation to other people.

My wife also doesn’t like that there’s no way to change Firefox back to the old behavior without going through about:config. (If you’re interested: type “about:config” in the location bar and hit enter, then do a search for a preference named browser.tabs.insertRelatedAfterCurrent and set it to True or False, as you like.)

 

What would you do with a Firefox home tab?

For Firefox 4, we’re thinking of replacing the home button with a home tab. It would be a mini-tab, not taking up any more space than the current home button; it would still be “click to go home”, but “home” would be a special page that is always open in a tab.

If the contents of that special page are useful, this could be a great feature. Because the home tab is part of the browser, like an extension, it would be able to do things that a normal web page can’t, like use statistics about your browsing habits to show you useful things. On the other hand, if the contents of the home tab aren’t useful, then it’s a pointless feature.

Given that… what would you put on the home tab?

That’s the question asked by the latest Mozilla Labs Design Challenge, which is open right now. If you have some ideas, go check it out!

 

Test Pilot to study Firefox crashes?

Blake (who generated all the cool graphs I’ve been using to present Test Pilot results) has used the session data from the Week-in-the-Life study to form an interesting hypothesis: That Firefox crashes per user follow a power-law distribution. If true, the power-law distribution means that “mean crashes” and “typical experience” are two very different things.

I should emphasize that the Week-in-the-Life study was not really designed to look at crashes, so I’d rather do a follow-up study specifically targeting this hypothesis before I support it with any confidence. But, as Blake says:

If our crash data follows a similar distribution, the average crash per user metric tells us little about the experience of a typical Firefox user.

Anecdotal evidence supports this hypothesis. While we all know people who swear by Firefox’s stability, we also know people who complain of frequent failures.

…

With this in mind, I suggest we use Test Pilot to run a longitudinal study of true Firefox crashes.

Agreed! And it’s great to see more hypotheses coming out of the Test Pilot data!