June 23rd, 2010
Firefox UX Team update: Wrapping up the first Firefox 4 beta
What the Firefox UX team is up to this week
The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we also try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.
New & noteworthy
This is the final week before we do the code freeze for Firefox 4 beta 1, and some UI changes have started making their way into the nightly builds.
There will be several more betas before Firefox 4 enters the release candidate stages, and we’d like to make it very clear that what’s in Firefox 4 beta 1 is not feature complete — neither on the UI side, nor on the functionality side. Mozilla subscribes to the “traditional” definition of beta releases — they are checkpoints where we lock down the code & functionality of the product, ship it to our testers and volunteers, and get feedback on selected parts of the whole picture. This isn’t like Gmail, which was “in beta” for 5 years, and most people were using it as their main webmail account anyway.
The main things to keep in mind for the upcoming beta 1 release of Firefox 4 on the UX front are:
- The UI is not in any way close to the final shipping product, as most of the work done so far has been infrastructure work that can support the new menu approach, the new theme, & cetera.
- The platform differences will be quite large, Windows will have features that do not exist in the Mac OS X version or the Linux version. This doesn’t mean we love any of these platforms any less, or that we’re not implementing those improvements on those platforms — just that the features and UI changes tend to land at different times on different platforms.
- If something seems wrong, it probably isn’t done yet — that doesn’t mean that you shouldn’t tell us about it, just that you can expect a lot of UI weirdness in the early betas.
If you have any confusion as to how your platform is intended to look or work, please consult the Windows, Mac OS X or Linux mock-ups that Stephen Horlander has lovingly provided to give you an idea of where we’re heading over the next few months.
If all that was too vague for you — the general rule is: Don’t Panic. Beta 1 will be a rough beta as far as the UI is concerned — but with much awesomeness on the infrastructure front — and later betas will be a much closer representation of how Firefox 4 will look and work.
Status reports on current UX priorities:
Notifications
Alex Faaborg:
- Need to work with Stephen for an update on icons and styling.
Firefox menu
Alex Faaborg:
- Need to file a few follow up bugs on things that are missing:
- Private browsing,
- Bookmarks submenu,
- Developer submenu,
- About and check for updates,
- Icons for significant item in each section.
Site identity
Alex Faaborg:
- No owner for beta 1, this is okay for now.
Firefox Sync
Alex Faaborg:
- Main priority this week.
Tab video
Alex Faaborg:
- Complete, will be published later this week. (…and there was much rejoicing!)
Beta Feedback button
Alex Faaborg:
- Inactive from my side, but need an update from Jingua and Aakash this week.
Home tab & App tabs
Alexander Limi:
- Stuck in the review queue at the moment, Dão & Blair have different approaches, Johnathan is on it.
- There’s no UI to play with for app tabs until it gets unstuck.
- Unlikely to make beta 1 release, this is okay.
- Marco is at a natural stopping point with the home tab content, waiting for unrelated non-code coordination.
- Limi & John Wayne should talk to Engagement team about requirements for snippets and messaging.
Download Manager
Alexander Limi:
- No change, still opportunistic.
HTML5 form controls
Alexander Limi:
- Setting up a meeting this Tuesday to discuss the HTML5 chrome buttons & app tab implications (Section 4.11).
- Wireframing of individual widgets.
“Paper Cuts”
Alexander Limi:
Paper cut overview bug is here.
- Posted Paper Cuts update post, called out some new targets and talked about current work being done by the team.
- Posted to Reddit asking for broken profiles, already have quite a lot of good feedback & volunteers with multi-minute startup profiles.
- Next steps: A round of janitorial work to make sure things are in good shape, as I haven’t had time to follow bugmail for the past week or so, as well as get the profile analysis going.
Main window refresh
Stephen Horlander:
- Filed Linux Bugs.
- Updated Linux Mockups (again)
- Ongoing email discussion with some Linux developers.
- New Mac patches undergoing review (may make beta 1).
- First stab at new Bookmarks Menu finished, awaiting review
- Working on some last minute polish.
- Jim Mathis posted several patches for drawing in the titlebar.
- Code freeze on Wednesday to make a release before the summit possible.
In-content page design
Stephen Horlander:
- Horlander & Limi to put together a list of what we want to change, and priorities, so we can get assistance from the community on implementation.
Add-ons Manager
Jennifer Boriss:
- Bit of a crazy last week getting together last bets for beta freeze.
- Icons found & created for freeze — props to Faaborg for being master of files in toolkit.
- Final graphics work still going on — want to get Vista done this week, the rest should model off that.
Jetpack & the Extension Bar
Jennifer Boriss:
- Blogged about add-on placement based on feedback from design session with Limi & John Wayne.
- A few problems became clear:
- Asymmetrical browsing area caused by small status bar not acceptable - bottom right area prime real estate in website design.
- Need either modification of UI or different UI for touch devices with no hover state.
- Need a way in UI to open/close bar that works for all operating systems and in fullscreen mode.
- Recommending a few tweaks:
- Status bar (still) off by default.
- All add-ons with UI that request the status bar turn the status bar on.
- Status bar has constantly-visible minimize button.
- A button still brings the status bar back out - what that looks like the remaining piece of the puzzle, but likely different depending on OS.
Privacy
Jennifer Boriss:
- Missed goal last week to blog about designs — will this week or owe a round of beer.
- Been talking with Mehdi about Summit workshop — will be about 15-20 minutes presentation, 20+ minutes discussion, Q&A, ideas.
TabCandy
Aza Raskin:
- TabCandy 0.4 released: jQuery-free and much faster.
- New Bugzilla Tracker!
- Cannot use HTML5 drag-and-drop (non-settable ghosting or snapping).
- Got a change to CSS transitions spec to allow bounce animation.
Post-Firefox 4 Home Tab
John Wayne Hill: (UX intern)
- More concept work this week. Plan is to present next week.
Startup performance & perception
Alexander Limi & John Wayne Hill
- Lots of articles and posts about John Wayne’s blog post
- (Re)starting and expanding the "Startup Experience" focus, want to get feedback on the list today, see below.
Mobile
Madhava Enros:
- Sean Martell is working on Android theme mockups this week.
- Will be publishing the 1.1 field guide with 1.1 release.
- Working with front-end developers to build out the project details pages (and do some subdividing into subprojects) this week - see Planning 2.0.
- Incidentally, looks like we’ll have to use our own mechanism for sharing on Maemo/Meego (example).
- In Mountain View this week, so would like to talk to UX team about the home tab, notifications & modal dialogs amongst other things.
Feedback session
Quick feedback and/or blockers; for in-depth discussions, we do design sessions on Wednesdays.
Startup Experience
Alexander Limi:
Here are some ideas of things we should/could look at:
- Track and refine the current work on recording perceived startup time.
- Enumerate which dialogs can get in the way of starting the browser, and make sure their respective projects are getting them removed (add-on updates, application updates, etc)
- “Get in the way” in terms of time vs. distraction — some notifications (dialogs should all be phased out in 4.0) may make sense to show on startup, simply because the alternative is a relatively random point in the browsing session. There may be ways to at least assure that these won’t affect startup time.
- Get some “broken profiles” from the community — ie. the ones that cause multi-minute startup times, etc — and get them analyzed and figure out what to do (reconstruct the profiles, fix the bugs causing them, examine if there’s any data loss, etc). I’m asking for these profiles on Reddit, since I had a good experience asking there last time.
- Add additional criteria for startup performance:
- Time to focus in the URL or search bar.
- Time to complete the first address entry (URL or Title match).
- Session restore performance, how quickly can you start using the browser:
- Cascading page loading, ie. restrict loading to 2-3 pages at once to keep the browser usable even when restoring 100s of tabs.
- Switch prioritized tab on-the-fly if user selects a different one while loading.
- Progress bar:
- Frontmost tab has very visible, fast progress bar.
- Separate progress from activity (ie. “when can I interact with the page”).
- I’m sure there’s lots more we can track and improve. Suggestions very welcome.
Our goal would be to keep track of these goals, post updates and encourage people to get involved in fixing them. Find people that might know how to fix this. Stuff we can’t figure out how/if we can do: bring up at Firefox Development meetings.
Other topics covered
- Jennifer Boriss is out of the office on Thursday and Friday.
Questions for the Firefox Development Meeting
- Open call for reviews on the theme work, get list from Stephen which ones are critical & which are nice-to-have.
- Shout out to Jim Mathis for getting drawing in titlebar done early in the week!
About the meetings
The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 14:30 PST. We post agendas to dev.planning & dev.usability before these meetings.
For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.
Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.
