View source for Mobile/UI/Designs/TouchScreen/Fennec 1.1+/Option B for Form assistant Layout and Functionality revision

= Problem description =

&lt;TBD&gt;

= Summary =

In this proposal, the design is based on the current Form assistant of Fennec (version 1.1).<br>

The main goals are to:<br> 

*Make it applicable with Virtual text input methods (both in Landscape and Portrait orientation): i.e. very limited space
*Align functionality of same type of components (e.g. Pop-up menus to work similarly with Context sensitive menus)
*Remove odd/inconsistent behavior

The main difference to the other proposal for revising Form assistant is the layout. 

= Basic components<br>  =

In this proposal, Form assistant uses basically the same components as the current version (1.1) of Fennec. However, there are some changes.<br> 

*Next and Previous buttons 
*Suggstions bar (for single line text input element) 
*Pop-up menu (in opened state)<br>

= Basic layout<br> =

In this proposal, the Next and Previous buttons of Form assistant would locate always in the top right corner of the view so that they could never be covered by any kind of Virtual keyboard, and Suggestions and Choice lists (in opened state) would locate on the bottom of the view, however always above the Virtual keyboard.<br>

Form assistant should be useful with both Hardware and Software keyboards. Because Software keyboards generally take half of the screen (typically a bit more in Landscape and a bit less in Portrait orientation), the Form assistant should take as less screen estate as possible to leave room also for the actual form element and/or web content in the view. Also, the Form assistant should be displayed only when it is reasonable and really needed, and it should display only relevant options (which can be used for something real – i.e. did not waste space for dimmed options). For example, if a web page contained only one form element (e.g. text input field), there is no mean to provide dimmed Previous and Next options, because they just take space from content. Form assistant could waste space for something useful.<br>

= Text input elements<br> =

The aim of redesign is to <br>

*link existence of Form assistant to Focus state of text input element. The Form assistant is displayed when a text input element is in focus and hidden when focus is dismissed. Because page is zoomed in as the result of activating a form element, it should be easy to reset focus back to the form element (or to another element) just by tapping it directly.<br>
*minimize the size of Form assistant and make it more applicable for using with Virtual text input methods (both in Landscape and Portrait orientation).<br>
*avoid horizontal scrolling of suggestions in a small row potentially in the middle of content sensitive to drag/flick interaction.<br>

== Layout<br> ==

Layout of Form assistant for editing Single line Text input element.<br>

<br>Layout of Form assistant for editing Multi-line Text area element.<br><br>

== Functionality<br> ==

With the implementation detailed below, the Text input elements would work consistently with desktop Firefox.<br>

Inserting focus to a Text input element on a web page<br>

*Single tap on it<br>
*Tap Next/Previous button of Form assistant (if they are available)<br>

Removing focus from a Text input element on a web page<br>

*Single tap outside of it<br>
*Close Software keyboard (with the function/button/etc provided by keyboard) <br>
*Tap Next/Previous button of Form assistant (if they are available)<br>

Form assistant should be <br>

*opened or stay open, if the user inserts focus to a text input element.<br>
*closed, if the user removes focus from a text input element and it does not result inserting focus to another form element you could use with Form assistant.<br>

See the image below for basic focus behaviour:<br>

See the image below for focus behavior if there was several text input element on a web page. <br>

'''NOTE:''' Tapping a text input element while editing another field should of course move the focus the the tapped field (the image above would have become just too busy if I had added the arrows for them).<br>

== Context-specific options: Suggestions<br> ==

In the current version (1.1), Fennec provide suggestions in a bar taking full width of the view and the list can be scrolled horizontally. Scrolling the suggestions horizontally can be troublesome because the list/bar can be in the middle of content/controls that can be moved or trigger other functions with the drag/flick interactions.<br>

In this proposal, the suggestions would be displayed in a bar (similarly to current Fennec) but its content could not be scrolled horizontally. Instead, it would display the most relevant options as buttons and, if there were more suggestions than it is possible to show in one row, the bar would contain a button for invoking a vertically scrollable menu with all suggestions available for the focused field. If you selected an item from the menu, the string would be inserted to the text input field, and if you tapped outside of the menu, the list would be closed but the focus would still remain in the text input field.<br>

The suggestions row could have either free width or it could be stretched to fit to width of the screen. I am not sure which one would be better. Free width would follow the overall logic to cover as less content as possible but it might look a bit busy in some case.<br>

Free width:<br>

Streched width:<br>

Figure illustrating the suggestions list is to come later on...<br>

= Pop-up menu (i.e. Single-selection Choice list)<br> =

In this proposal, the layout of the Form assistant concerning Pop-up menus is pretty much the same as in the current version (1.1) of Fennec, but there is a new feature for searching the desired menu item which is a useful feature in case of long lists.<br>

Most of the changes are about the functionality of the Choice list. The aim is to align the functionality of Pop-up menus to work consistently with the Fennec´s context-sensitive menu and desktop Firefox, so that they would work as expected&nbsp; by (most of the?) users. <br>

Basically, the Choice list should support Closed and Opened states when it is in focus. The user should be able to open a pop-up menu by tapping it (as it works currently). The next steps are new: Tapping a list item, should select the tapped item and close the list/menu and tapping outside of the list should close the list/menu (similarly to Context-sensitive menus and how it works on the desktop). <br>

Currently (in version 1.1), tapping an item in a Choice list selects the item but does not Close the menu... This leaves space for doubts "Why does it not work?", "Did I do something wrong?", "Is this broken?"... And you are expected to close the list manually as an extra step or select the "Next" or "Previous" buttons to get it closed.<br>

== Layout<br> ==

== Functionality<br> ==

Inserting focus to a Pop-up menu on a web page<br>

*Single tap on it<br>
*Tap Next/Previous button of Form assistant (if they are available)<br>

Removing focus from a Pop-up menu on a web page<br>

*Single tap outside of it when in closed state<br>
*Tap Next/Previous button of Form assistant (if they are available)<br>

Opening a pop-up menu/list<br>

*Insert focus to it (see above)<br>
*Tap pop-up menu when it is in closed state

Closing a pop-up menu/list<br>

*Tap list item: selects the ietm<br>
*Tap outside of list or Form assistant (cf. Context-sensitive menu)<br>
*Start panning outside of list or Form assistant (cf. Context-sensitive menu)<br>
*Tap Next/Previous button of Form assistant (if they are available)

Form assistant should be<br>

*opened or stay open, if the user inserts focus to a pop-up menu.<br>
*closed, if the user removes focus from a pop-up menu and it does not result inserting focus to another form element you could use with Form assistant.<br>

See the image below for basic focus behaviour and menu functionality:<br>

See the image below for focus behavior and menu functionality when there are several form elements on a web page<br>

== Context-specific options:&nbsp;Searching/Filtering list items ==

The Form assistant should should support searching or filtering out a desired item from a long list. This is a useful feature with devices which can provide only limited size viewport to the content. Basically, filtering list content would be most efficient feature to get the desired items to the view because it would work also with lists where the list items are not in alphabetical order and/or the list content is structured (i.e. not flat)... But this is not something even desktop firefox would support at the moment.

The Search/Filtering feature would be the first item of the list but by default it should not not be displayed when the menu is opened. The Search/Filtering feature could be revealed by panning the list downwards or by starting to type with Hardware keyboard. In general, the search field would move along the list, so it could be hidden by panning if needed.

Searching/Filtering with Hardware keyboard

Searching/Filtering with Virtual keyboard

= Multi-selection Choice list =

Multi-selection Choice list should work similarly to Pop-up menu except that selecting a list item would not close the menu. To exit the menu (with the currently selected items), the user could tap outside of the menu (or start panning outside of it) or tap the Previous or Next button if they were available.<br>&lt;figure to come&gt;<br>