Mobile/UI/Designs/TouchScreen/Fennec 1.1+/Option B for Awesome screen layout revision

From MozillaWiki
< Mobile‎ | UI‎ | Designs/TouchScreen‎ | Fennec 1.1+
Revision as of 13:11, 20 January 2010 by Pflippp (talk | contribs)
Jump to navigation Jump to search

OBJECTIVES

<TBD>


FUNCTIONALITY

Awesome bar/view would consist of following elements:

A) Text entry field for web address or search phrase

B) Go button

C) Button for opening a dialog with a complete list of integrated Search engines

D) Search engine shortcut

E) List of web pages suggested by browser

F) Dialog with a complete list of integrated Search engines


Awesomebar layout option B 01 overview.png


In this solution, Basic functionality of awesome bar would be quite similar to the current Fennec (1.0 beta) although the layout and some functions/features had changed.

The user could enter a web address or free form text (e.g. search phrase) into the text field (A) and then tap the Go button (B) or a Search engine (D) to start opening a web page. If the desired Search engine was not promoted by the UI, the user could tap the Search engine selection button (C) that would open a dialog (F) with all installed integrated Search engines, and then the user start a search with the desired engine by tapping a list item. The UI should promote the last used Search engine or engines.

The UI would support showing a list (E) of matching web pages (available from bookmarks and browsing history) below the Awesome bar while the user is entering text inside the text field (A), but it could not support showing a list of last search strings entered by the user or search phrases suggested by a Search engine. However, this is exactly the same thing what happens with the current version (1.0 beta) of Fennec. Anyway, the user can start opening a desired web page by tapping the corresponding item in the suggestion list (E), so s/he is not required to type complete web address etc to open a web page (in precondition the page is available from browsing history or bookmarks).

What is different to current version (1.0 beta) of Fennec, is that the Awesome bar and view would show and hide options based on user interaction and thereby optimize the view and maximize the number of options relevant for the usage at a time. See the UI flow below:


Awesomebar layout option B 02 UI-flow.png


The Awesome bar would show

  • Go button (B) always, except when the user has opened the UI for selecting a search engine (F).
  • Search options (C and D) only when the focus is set to text field (A).

LAYOUTS

The main change compared to the current layout of Fennec (version 1.0 beta) is to move the integrated Search engines from the bottom part of the view to the top part of the view, so that search functionality would be instantly available also with on-screen keyboards (except full-screen on-screen keyboard). When the Search engines are in the top bar, they don´t take space from the suggestions and can be associated (more clearly) to be part of the awesome bar feature.

In wide screens (and landscape orientation), the Awesome bar would take one row. In narrow screens (and portait orientation), it would take two rows and provide as wide text input field as possible (so that the user has better overview what s/he is typing and thereby can detect errors such as misspelling easier).

See the figures in the table below for the layout when the user has accessed the Awesome view but has not edited the text inside the address field. In these preconditions and when the address editing field is empty, the browser would display options for going to Bookmark and History views and a list of web pages the user has visited most frequently below the Awesome bar.

Keyboard
No focus set to Address field
Focus set to Address field
Hardware
see image below
Awesomebar layout option B 04 initial state focus hwk.png
On-screen
Awesomebar layout option B 03 initial state no focus.png Awesomebar layout option B 05 initial state focus osk.png


See the figures in the table below for the layout when the user has started to edited the text inside the address field either with Hardware or On-screen keyboards. In these preconditions, the browser would hide the options for going to Bookmark and History views and show a list of web pages matching with the text entered by the user.

Keyboard
Focus removed from Address field
Focus set to Address field
Hardware
see image below
Awesomebar layout option B 07 edited state hwk.png
On-screen
Awesomebar layout option B 06 edited state no focus.png

Awesomebar layout option B 08 edited state osk.png