13 May, 2013 § 5 Comments
Well, we were “jamun”. This past week we shut off the Jamun project branch of Australis and moved our focus to the UX branch.
What does all this mean?
In a nutshell, this means that the Australis customization rewrite has progressed enough to the point that we feel it is ready to start getting much broader testing. We’re in the final stretch of the project, and we want our changes to reach testers at a faster pace.
Here’s where we stand today:
* Most customization workflows are possible. Not all UI migrations are complete.
* Most polish on the edges isn’t there. It does however look pretty close on Windows and Mac now.
* Some final graphics are missing, but they’re not far away.
Wait, wait, what are we talking about here?
Ah, okay, I’ll take a step back. A while back, in fact, a looooong time ago… there was a presentation from the Firefox UX team about a new browser UI refresh and rewrite of our customization workflows. It turns out that many users don’t know that Firefox is customizable. Some users accidentally customize their browser and don’t know what went wrong. Then, there’s this super-tiny super-expert user group that has figured out how to customize Firefox and they *adore* it.
So, what are we doing about it?
Well, the first thing that we’re doing is making entering and exiting customization of Firefox much easier. No longer will a user have to right-click on a special portion of a toolbar and choose “Customize…”. This was way too hard to find for the vast majority of users. We’ve left that same entry point there, but we’ve also created a very visible “Customize” button.
Sounds good, where is this Customize button though?
Great question! Another goal of Australis is to unify the user experience between Windows, OS X, and Linux. On Windows and Linux, Firefox has an “Application Menu” in the top-left corner of the browser. We’ve moved this menu to the right-side of the navigation toolbar and it will now be visible on all three platforms. We’ve also been hard at work trying to make this menu easy to use and navigate. The Customize button is located at the bottom of this menu.
Another really cool thing about this menu is that it will be customizable. When you enter Customization mode, you’ll be able to add, remove, and rearrange items in the menu as well as items on the toolbars.
Here’s a screenshot of what the Customization mode looks like today on Windows:
As I mentioned earlier, all of this is still very much a “work-in-progress”, so it’s expected that people will find bugs and rough edges. If you’d like to play with it today, you can download the UX Nightly builds and give it a run. The UX Nightly builds will update daily with new changes to the customization.
Please let us know about any bugs that you find by filing a bug in Bugzilla in the Firefox::Theme or Firefox::Toolbars component (and mark the bug as blocking bug 770135). If you don’t feel comfortable doing the above, then just leave a comment on this blog post and I or someone else will file the bug for you.
8 March, 2013 § 21 Comments
If you’ve ever tried to read a plain-text file in Firefox, you may have noticed that we didn’t have an option to apply word wrapping to the text. New in today’s Firefox Nightly build, we are now applying word wrap to plain text documents by default.
For example, this file is very hard to read when the lines aren’t wrapped. The lines scroll offscreen horizontally, and the user has to use the horizontal scrollbar on the bottom of the screen to read the file (yuck!). Here’s a screenshot of what I’m talking about:
With word wrapping applied, the text is much easier to read and the line length will adapt to the size of the browser window:
Some documents aren’t ideal for word wrapping, and to aid that we have made it easy to disable the feature. To toggle whether the document is wrapped on a case-by-case basis, you can change between the “Wrap Long Lines” stylesheet and “No Style”.
If you’d like to disable the feature entirely, you can go to
about:config and set the
plain_text.wrap_long_lines preference to
5 February, 2013 § 5 Comments
Last week I was in Toronto, ON with the rest of the Firefox Desktop team. We met for a week and discussed a number of topics that we want to get moving in Q1 and Q2 of 2013.
On Monday we had a 2013 overview by Johnath where he gave a similar talk that he has been doing at the MozCamps around the world. This was nice for us because it is not often that we get to see how Firefox and Mozilla are talked about at these events (I was lucky enough to attend the MozCamp in Poland in 2012 though).
We also got a deep dive in to the various personas of Firefox users in a presentation given by Bill Selman. Bill talked about there being seven distinct groups that users fall into. These range from “evergreens” to “wizards”, and we talked about what features to add/remove to help these users, as well as how to go about making changes to the software so as not to adversely affect these users.
On Tuesday we did an “ideation” activity, also known as brain storming , where we wrote down ideas of things that we would like to change with Firefox. After writing these down on post-it notes, we then grouped them together with other like-minded ideas on the wall and named the groups. On Tuesday afternoon we paired up in small teams to try to tackle some of these issues.
I spent Wednesday, Thursday, and Friday focusing on three small projects.
On Wednesday I worked with Dão Gottwald and Felipe Gomes on a simple slow start-up feature. The feature works by keeping track of the previous 5 start-up times. If the average startup time is greater than our threshold (currently 1 minute, with plans to lower it), then we will show a notification bar at the bottom of the browser window.
With help from Matej Novak, we got some nice whimsical text for the notification bar. When the user clicks on the “Learn how to speed it up” button, they are taken to a page on SUMO that can guide them towards a faster start-up time. Not pictured in the below screenshot, but part of the feature, is a second button that says “Don’t tell me again”. Stephen Horlander created the turtle icon.
On Thursday I worked with Stephen Horlander to see what parts of our user interface can have animation added to them. I wanted to work on a feature that is toggled often, thus having higher visibility. Stephen spent some time looking at transitioning the site-identity information in our location bar, and I spent some time working on adding a transition for the Find toolbar. You can follow along with my work in bug 836867.
A project that I had started a while ago but never finished was a refresh of Firefox’ in-content error pages. I got a few requests to resume that work and on Friday I unbitrotted Blair’s patch for bug 676795. That work is now awaiting Blair’s feedback and I’ll keep working on the bug when I get time.
On Friday night, I went with Paolo Amadini and Marco Bonardo to see the Johnson Report’s concert (starring the Firefox desktop team’s own Mike Conley on the guitar). The concert was at Lee’s Palace on Bloor St, and I must say that Mike and his band had an amazing performance. A funny kicker to the story is that each attendee to the show got a raffle ticket. Paolo, Marco, and I left early to catch the midnight subway back to the hotel and gave our raffle tickets to Mike’s girlfriend. We found out on Monday that she won the guitar!
23 July, 2012 § 25 Comments
Almost exactly a year ago I wrote about applying Fitts’ Law to commonly used buttons. Fitts’ Law is pretty well known among user experience professionals and front-end developers as it can be used to make commonly accessed user interface elements much easier to target. Hick’s law is probably less known, but its effectiveness is just as great.
Hick’s law “describes the time it takes for a person to make a decision as a result of the possible choices they have.” This law can be applied to the number of options for a question on a form, the number of dishes offered on a restaurant menu, as well as the number of menu items on a context menu.
In the case of Firefox’ context menus, we were able to remove a very seldomly used menuitem (“Send Link…”), and combine the “Reload” and “Stop” buttons.
Our new heatmap data showed us that only 0.89% of users clicked on the “Send Link…” menuitem. This is not really a surprise, given that the location for the majority of webpages can be found by looking at the location bar. This is in contrast with “Send Image…” which was used by 3.34% of users. “Send Image…” likely has higher usage because the majority of image URLs are not available in the primary UI.
Combining “Reload” and “Stop” gives us another nice win because the two states are mutually exclusive and the combination reflects the default state of the two actions in our location bar. Making this change led to discussions about removing the “Forward” menuitem when it is disabled, similar to how we remove the Forward button in the navigation toolbar when it is disabled. While removing the “Forward” menuitem would align with internal consistency, it would also make the remaining menuitems more ambiguous (“Back” and “Reload”).
The disappearance of the Forward button in the navigation toolbar does not make the Back button ambiguous. The back button is visually connected to the location bar (signifying a relationship between the two items), and the arrow describes moving backwards. If the context menu only contained “Back” and “Reload”, or potentially “Back” and “Stop”, then there is a much greater chance of confusion as to what “Back” really does. In other words, the presence of “Forward” helps to provide a navigational context for the other menuitems in their group.
19 January, 2012 § 2 Comments
For a long time, one or two members of the Firefox UX team received the majority of feedback and ui-review requests. Sometimes an the requestee goes on vacation, leading to slow feedback loops and stalled work.
The reality is that submitting patches that alter the user interface of Firefox doesn’t need to be a scary or long process. I’ve been working with the UX team to put together a set of steps that contributors can take when they want to get feedback or ui-reviews from the UX team.
Asking for general direction?
There are times where you may not know in which direction to go. There is nothing wrong with implementing what you think will provide the best user experience or implementing multiple variations of your idea. Sometimes the experience of implementing another idea may show advantages and disadvantages in the design and help with your decision making.
If you still have some general questions about design, please don’t hesitate to join the #ux channel on IRC. If somebody doesn’t answer your questions, just ask again in a few hours (people may be sleeping due to timezone differences).
Looking for specific feedback or ui-review on your patch?
If you’re about to upload a patch and request feedback or ui-review, please link to either a screenshot, screencast/video, and/or try-server builds that contain the patch.
Here are links to some good software that can be used to create screenshots and screencasts:
- TechSmith Jing (free and paid version makes PNG screenshots, free version makes SWF videos, paid version makes MP4 videos)
- TechSmith Camtasia Studio/Camtasia:Mac (useful for detailed/longer screencasts)
- Quicktime X/Player included on Snow Leopard and higher can do screen recordings (File > New Screen Recording)
- Miro Video Converter (to convert videos to WebM format for easy viewing in the browser)
Please attach your screenshots/screencasts to the bug, since Bugzilla will probably outlive an external media hosting website.
After attaching your media, please flag the special UX email address, email@example.com, for feedback or ui-review.
Expectations of the UX team
The UX team has a goal of responding to feedback and ui-review requests within 48 hours.
Special thanks go out to Jennifer Morrow (Boriss), Frank Yan, Matthew Noorenberghe, David Lawrence, Ann Ignacio, Henry Langi, and Alex Limi for their help in putting this all together.
For more information
If you have any changes that you would like to make or to see the most up-to-date version of this document, please see the page on developer.mozilla.org.