Changes

Jump to: navigation, search
no edit summary
= Problem description =
<TBD>
= 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
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>
[[Image:Fennec_Form_assistant_Option_B_basic_layoutFennec Form assistant Option B basic layout.png]]
<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>
[[Image:Fennec_Form_assistant_Option_B_displaying_components_based_on_needFennec Form assistant Option B displaying components based on need.png]]<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 of Form assistant for editing Single line Text input element below.<br>
[[Image:Fennec_Form_assistant_Option_B_Layout_Text_input_fieldFennec Form assistant Option B Layout Text input field.png]]
<br>
Layout of Form assistant for editing Multi-line Text area element below.<br><br>[[Image:Fennec_Form_assistant_Option_B_Layout_Text_input_areaFennec Form assistant Option B Layout Text input area.png]]<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== 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> [[Image:Fennec_Form_assistant_Option_B_functionality_Text_input_field_1.png]]
<br>See the image below for focus behavior if there was several text input element on a web page. <br>
'''NOTE[[Image:''' 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)Fennec_Form_assistant_Option_B_functionality_Text_input_field_2.<br>png]]
== Context-specific options'''<br>NOTE: Suggestions''' 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> ==
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.== Context-specific options: Suggestions<br> ==
In this proposalthe current version (1.1), the Fennec provide suggestions would be displayed in a bar (similarly to current Fennec) but its content could not taking full width of the view and the list can be scrolled horizontally. Instead, it would display Scrolling the most relevant options as buttons and, if there were more suggestions than it is possible to show in one row, horizontally can be troublesome because the list/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 can be inserted to in the text input field, and if you tapped outside middle of the menu, the list would content/controls that can be closed but the focus would still remain in moved or trigger other functions with the text input fielddrag/flick interactions.<br>
The In this proposal, the suggestions row could have either free width or it could would be stretched displayed in a bar (similarly to fit to width of the screen. I am current Fennec) but its content could not sure which one would be betterscrolled horizontally. Free width Instead, it would follow display the overall logic to cover as less content 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 it might look a bit busy the focus would still remain in some casethe 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>
Streched Free width:<br>
Figure illustrating the suggestions list is to come later on...Streched width:<br>
= Pop-up menu (iFigure illustrating the suggestions list is to come later on..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 menu (1i.1e. Single-selection Choice list) 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 In this proposal, the changes are about the functionality layout of the Choice list. The aim is to align the functionality of Form assistant concerning Pop-up menus to work consistently with is pretty much the Fennec´s context-sensitive menu and desktop Firefox, so that they would work same as expected&nbsp; by in the current version (most 1.1) of Fennec, but there is a new feature for searching the?) usersdesired menu item which is a useful feature in case of long lists. <br>
Basically, Most of the changes are about the functionality of the Choice list should support Closed and Opened states when it is in focus. The user should be able aim is to open a popalign 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 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 most of the list should close the list/menu (similarly to Context-sensitive menus and how it works on the desktop?)users. <br>
Currently (Basically, the Choice list should support Closed and Opened states when it is in version 1focus.1The user should be able to open a pop-up menu by tapping it (as it works currently), tapping an item in . The next steps are new: Tapping a Choice list selects item, should select the tapped item but does not Close and close the list/menu... This leaves space for doubts "Why does it not work?", "Did I do something wrong?", "Is this broken?"... And you are expected to and tapping outside of the list should close the list manually as an extra step or select the "Next" or "Previous" buttons /menu (similarly to get Context-sensitive menus and how it closedworks on the desktop).<br>
== LayoutCurrently (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> ==
== FunctionalityLayout<br> ==
Inserting focus to a Pop<br>[[Image:Fennec_Form_assistant_Option_B_Layout_Pop-up menu on a web pageup_menu.png]]<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>  [[Image:Fennec_Form_assistant_Option_B_functionality_Pop-up_menu_1.png]] <br>See the image below for focus behavior and menu functionality when there are several form elements on a web page<br> [[Image:Fennec_Form_assistant_Option_B_functionality_Pop-up_menu_2.png]]   == 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.
See the image below for focus behavior and menu functionality when there are several form elements on a web page<br>Searching/Filtering with Hardware keyboard:
== Context[[Image:Fennec_Form_assistant_Option_B_functionality_Pop-specific options:&nbsp;Searching/Filtering list items ==up_menu_Search_1.png]]
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 <br>See the content. Basically, filtering list content would be most efficient feature to get the desired items to the view because it would work also image below for Searching/Filtering 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.Virtual keyboard:
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[[Image:Fennec_Form_assistant_Option_B_functionality_Pop-up_menu_Search_2.png]]
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>
323
edits

Navigation menu