Mobile/UI/Designs/TouchScreen/Proposal6

Scope

The following is a draft proposal for a Fennec m1 user-interface. The diagrams are wireframes, and, as such, are meant to describe the interaction model and page layout rather than pixel-specific sizes or final look (icons or colours).

This is all designed with the n810 in mind -- the device has a touchscreen but also a hardware keyboard.

Overview

The toolbar at the top of the screen stays in place (doesn't scroll out of view).

a. Back and Forward buttons

b. Location bar with favicon. In the future this can accomodate Awesomebar functionality. Search can also be blended in here -- more on this below.

c. Bookmarking button, as in Firefox 3

d. Button to bring up the list of bookmarks

e. Scroll bars -- they're translucent, and show up only when the page is actually being scrolled

Non-visual Interactions

• Scrolling: tap and drag
• Zooming: double tap (cycles at end, so final double-tab brings the user back out to full screen)

Toolbar States

With only one toolbar area on the screen, making the most of that screen real estate is key. One way to compress controls while still avoiding confusing system modes is to overlay items that are mutually exclusive and that change depending on what the user is actually doing (more on this below). Another is to blend certain related activities -- such as URL entry and search term entry -- into a single UI element.

In these states, we're overlaying go, stop, and reload. "Go" is shown when a user is typing (this is what we do in Firefox 3), "Stop" is shown when a page is loading, and "Reload" is shown when a page is loaded.

Additionally, we put in the throbber in place of a favicon when a page is loading -- this is what we do on tabs in the desktop browser. In addition to saving space, it actually makes sense in that the favicon is shown only when you're actually on it's related page.

Finally, we can also blend URL-entry and search. These are already starting to overlap on the desktop through things like the awesomebar, browse-by-name, and top-search-result-returning when browse-by-name doesn't work.

As in (f) and (g), both "Go" and "Search" are available for clicking/tapping when the user begins to enter text. As in (h), if the entered text is recognizable as a URL (e.g. contains www, a dot, a TLD) then the default (enter) action can be marked visually. Actually - we should probably make searching the default until the entered text actually looks like a URL.

Bookmarks

Bookmarking

A single tap on the bookmark star bookmarks the page. Tapping the star again brings up an area for editing/adding details.

For the moment, this area only allows for editing the bookmark name and checking the URL. Once we have more support for filing bookmarks in folders and/or tagging, this dialog can support these -- more like the Firefox 3 dialog.

The address field in the 'Edit Bookmark' box seems redundant since the URL is already visible in the location bar above.

Bookmark list

Flat list for M1. Still without Edit/Remove controls.

Version 1:

Awesomebar options

If the Awesomebar is going to be used, I'd suggest that we show it in a compacted form (making the display less full of small text and allowing us to devote more vertical tappable space for each item). We can do this be only showing the title or URL that contains matching text (if they both do, give priority to the title).

Compact:

For comparison, a more traditional awesomebar treatment:

Thoughts on toolbar sizing

The n810's high screen resolution means that icons and layouts that work fine on a desktop screen are too small for easy finger-tapping (or even stylus tapping) when moved over.

Working with the current set of icons (currently mostly 24px - should probably be larger in the future), I think the following layout would make it easier to manipulate the controls with fingers. Finger-tapping requires not only targets of sufficient size, but also enough spacing between targets. The more precise a user has to be, the slower will be the interaction with the device. The 55px height, at the n810's resolution, works about to about 5mm.

Other devices further address the target size problem by having the tappable area extend beyond the bounds of the visible icon -- we should do the same. Maybe we can try extending the target area vertically to just shy of the top and bottom toolbar bounds for each?

Downloads UI

Currently, the Download Manager is implemented as a separate window that users can switch to by using the OS window manager.

Thoughts on downloading UI:

• downloading on a mobile device, at least where the downloaded file is simply to be saved to a file system, is seen as being relatively unusual (currently)
• Can we think of the act of downloading as being unusual and therefore of primary interest? Versus something that should happen in the background with little indication to a user?

In the following mockup, the current status of a download is shown as a popup indicator in the lower right corner. Overall status is shown as a filling pie graph.

This will inevitably cover some content, though, if downloading is of prime interest, that might be OK or even desirable. Clicking on the indicator could open the download manager that is a separate window or dismiss the indicator, or both. Alternatively, we could separate those functions out:

When a download completes we could put an indicator of the same style in the same place, so, if the user had left the progress indicator up, it would just complete visibly there, and if it had been dismissed the user would still get indication that download had completed and a means to getting to the download manager.

Alternatively, if we move to a model where a user can tap and hold to bring up a radial menu, we could have a dismissed download indicator also be visible, in its corner, when the radial menu is on the screen.

Compacted