In the UX test proto the layout broke down on Android 5 test device. The error occurred at least when there was more than one instance of a combo box with the same items inside a form ("Languages" combo box in the proto).

• Options list was cut half from the middle even if there was so many items that they didn't fit in the viewport.
• Some options appeared as empty rows.

Background: UX Test Notes

Currently, the page can be scrolled using TAB to focus elements outside the overlay which causes the overlay to be displayed in a wrong place.

Simultaneously, the value of the input should revert to the actual selected value.

An input and a button for opening and closing a display of a list of static items:

• Dropdown menu (for large viewport sizes)
  • Positioning and sizing when close to viewport edges
• Fullscreen popup (for small viewport sizes)
  • Ignore iOS fixed positioning quirks and the remaining vertical viewport size when the software keyboard is visible.

Use the existing prototype (alpha1) as a reference for the overall experience (look and feel, functionality, etc.), regarding the list display (not other features).

Note

Do not put iron-list or vaadin-grid inside combo-box before there is an actual need for it! And those definitely are not needed at this point (they are most likely needed only after we start including a feature that requires hundreds of items or lazy loading).

DoD:

• Tests
• Documentation
  • API docs
  • Demo/examples

Specify and implement opening/closing the combo box behaviour regarding up/down and esc keypresses. Things to keep in mind:

• prefilling the input while moving up/down in the dropdown
• cycling options list with arrows after the dropdown is opened (jumping from top to bottom or bottom to top)
• selecting vs. clearing the selection with which keypresses at which stages?

Background: UX Test Notes

Polylint error – vaadin-combo-box.html:145:31
Property 'items' bound to attribute 'items' not found in 'properties' for element 'vaadin-combo-box'

Tried on Safari 8 and 9, after doing some pinch zooming, overlay is misplaced and the page can be scrolled.

Related with PolymerElements/iron-dropdown#39

Research ways to mitigate iOS viewport scrolling in combination with fixed positioning.

• Decided to use iron-selector temporarily for now.
• Return value is a string from the items array
• Selecting item will close popup
• Value can be selected like: combobox.value = 'foobar'
• Behavior for selecting an undefined value is undefined at this time.

Tap on the input underline border focuses the input instead of opening the fullscreen dropdown.

• Support primitive types only at this point
• Put a iron-list inside iron-selector
• vaadin-combo-box should expose items
• Push, Pop, Empty, Update and other array related mutations need to be tested

Two possible approaches:

Use <vaadin-grid>

• Prototyping already done
• Supports multiple columns out of the box
• Supports multi select, but probably needs some rework to be usable in a combobox?
• Smaller cache footprint (grid discards items out of the viewport)
• Supports lazy-loading out of the box
• Anything else?

Use <iron-list>

• Has a templating model for custom rows (and multiple columns)
• Supports multi select
• Smaller in size and simpler
• Performs faster
• Implementing lazy loading should be straight forward (there are examples)
• Anything else?

Add label behaving similarily to one in paper-input element (a "label" property/attribute).

Consider also how bottom-aligned dropdown should be positioned if there is no label present. It might require some negative margin etc.

Add the label attribute to the existing examples, and mention the use of it in the first example.

1.0.0-alpha1 ok-go!

Fullscreen combo-box should close when tapping on the grey area under the list.

• Dropdown open and close
• Loading indicator (when lazy loading data source has been implemented)
• Item selection

• Enable scrolling (duh)
• Hide soft keyboard on touch devices when scrolling (also on iPad which doesn't use fullscreen) (by blurring the input field)
• We assume that the soft keyboard is always hidden if the are no input fields (nor text areas) focused
• See #2

The dropdown item list might, in some cases, be better aligned above the input field, or next to it on the left or right side.

Currently, the focus remains in the underlying <input> outside the overlay. Focus should be moved to the fullScreenInput field.

Given combo-box has a value of bar, and the overlay is closed,

When the user selects bar and hits backspace to clear the input,

Then the overlay should open and all items should be displayed.

• Currently the overlay doesn't open.

• See how the Framework combobox works
• See also Polymer <paper-dropdown-menu>
• http://www.w3.org/TR/wai-aria/roles#combobox
• http://www.w3.org/TR/wai-aria/roles#listitem
• Tests should assert that correct attributes are in correctomundo places
• Ask help from the Framework team & UX team
• Figure out how to verify we have all the needed attributes?
• Chrome has an Accessibility Developer Tools extension

• Use the approach as Polymer elements (iron-form)
• Implement Polymer.IronFormElementBehavior
• iron-form could be used in testing (serialize() maybe?)

• Preselect the input value when opened/focused
• When you filter the items, and navigate using arrow keys, the ending of the value could be entered into the field and preselected, if we have an option for "begins with" type of filtering

Background: End User UX Test Notes

The fullscreen mode should not depend on any user agent detection. The viewport size is the only thing that should trigger it (but it does not need to adapt when the item display is open).

The threshold should detect both viewport width and viewport height, and take the smallest of those. If either is under 600px, then use fullscreen.

Currently on iPad you get this:

Currently, we add global document event listeners to prevent <iron-dropdown> scroll manager from eating the events when overlay is opened.

The listeners aren't cleaned up at all, which might cause issues if there are other elements trying to listen the events.

When a combo-box is opened for the first time, it fires at least 3 opened-changed events and 2 iron-overlay-opened events.

This is most probably because the <vaadin-adaptive-overlay> doesn't have a default value for _verticalAlign and it closes and reopens the overlay while trying to figure the alignment out.

We need to decide if we want to and can support this (allow the user to type any value to the input which is not in the actual options list).

See <iron-dropdown> demo:
https://elements.polymer-project.org/elements/iron-dropdown?view=demo:demo/index.html&active=iron-dropdown
https://github.com/PolymerElements/iron-dropdown/tree/master/demo

• <vaadin-adaptive-overlay> needs to figure out whether to align the overlay below or above the input depending on the viewport position.
• should automatically resize like in the iron-dropdown demo

If vaadin-combo-box gets focus, it hides page scroll bar reducing page width on browsers that have non-overlaid scroll bar (e.g. Chrome on Windows and Chromium on Ubuntu, not OS X). Change to page width will align centered content again making the layout jump on each focus and blur.

To test, open https://cdn.vaadin.com/vaadin-elements/master/vaadin-combo-box/demo/ in non-OS X browser and focus any combo box.

When list opens underneath the combobox down arrow navigates to that list naturally. One would assume to be able to navigate to list with up arrow when list is above the combobox.

After selecting an item, it is impossible to get back to initial state where nothing was selected. We should not force people to reload the page as an only way of getting back to unselected state. (tested on iPad only).

Natural way of implementing this would be to unselect when one deletes the selection with keyboard.

Clean up the prototype code in the fullscreen-ios branch.

Remove code related to viewport resizing (when the keyboard is open)

See if there are ways to enhance the end user experience, compared to the feature/fullscreen-ios branch prototype, including:

• Double tapping on elements outside the dropdown list
• Touch dragging other elements than the dropdown list
• Refocusing the input field

Different cases to solve:

• Key down ↓
  • Dropdown opens below
    • Key down ↓
      • Highlight first item in the list
    • Key up ↑
      • ?
  • Dropdown opens above
    • Key down ↓
      • Highlight first item in the list
    • Key up ↑
      • ?
• Key up ↑
  • Dropdown opens below
    • Key down ↓
      • ?
    • Key up ↑
      • ?
  • Dropdown opens above
    • Key down ↓
      • ?
    • Key up ↑
      • ?

Conduct API user testing for the first draft of the API.

• Define test tasks
• Define the number of test users
• Define test platforms

It would be great to promote the responsive behavior of the element in the screenshot.

The screenshot should probably include the element running inside an actual device.

• Replace the element in vaadin-combo-box
• Make all the existing APIs work with vaadin-grid
• Make sure resizing / keyboard navigation works ok
  • Try to make the vaadin-grid built-in focus work first, if it seems not doable, use a similar approach as with iron-list currently (change selection on key press and perhaps use a rowclassgeenrator for highlighting the vaadin-combo-box selection)

Currently, iron-list deselects items when you click on a selected item.

• Instead, we should just close the popup when user clicks on a selected item. selected-items-changed should NOT fire.

Opening the dropdown can be done with up or down arrow keys. However only down arrow can be used to bring focus to the first (or selected) item of the dropdown.

This feels a bit weird when the dropdown is positioned above the input field. It would probably make more sense to focus the dropdown item also on a second up key press.

The two blue arrow keys above the software keyboard on iOS work unexpectedly.

When you have the fullscreen mode open for a combo box, and press either of the “tab” buttons to move the prev/next field, the combo box overlay stays open.

Similary, when “tabbing” into a combo box on a “fullscreen device”, should the overlay open automatically. Most likely not, as it might cause a too big interruption if the user is just “tabbing through”, but this needs some discussion.

Currently, in our “Using as a form field” demo, if you select an item using the keyboard, the form is submitted immediately at the same time when the item is selected.

The form should only be submitted if the items list is not open and the user pressed the enter key – in other words, the default browser action should be prevented when the user selects an item from the list using the keyboard.

The form SHOULD be submitted when you press the enter key if the list is closed and the focus is in the input.

• API design, first draft
• "Desktop" implementation design
• "Fullscreen" implementation design

Issues to resolve:

• iOS fixed positioning and viewport scrolling
• Zooming on touch devices
• Research Polymer.Templatizer

• Pay attention to keyboard navigation / row focus
• Update findings to #32
• Timeboxed to 8h

Features / Behavior:

• Let's focus on desktop behavior, if it works on fullscreen, great - if not then not.
• Input can be focused using TAB
• Popup opens when you start typing on it (or click the icon)
• Popup opens when focused and you push DOWN/UP
• If a value is selected when popup opens, it's highlighted, otherwise nothing is highlighted. Selected item is not highlighted after filtering anymore.
• After typing in a filter, the topmost item is highlighted
• Focus/highlight is moved up and down by pushing DOWN/UP
• When you navigate to the topmost item, and push one more time UP, the topmost item stays focused??
• You need to be able to navigate the value inside the input field using LEFT/RIGHT
• Pushing ENTER will select the focused/highlighted item
• When the input box is cleared and ENTER is pushed, combobox value is cleared.
  • Q: How is the input box cleared ? A: With BACKSPACE
  • Q: When input box is empty is it cleared ? A: combobox.value is cleared if ENTER is
    hit when input box is empty/cleared
  • Additional info: when input value is changed, the items are reset and item highlight is removed.
• When the input box is cleared we don't want to highlight the topmost item
• Pushing SPACEBAR is for now reserved for multi selection
• Pushing ESCAPE will cancel and close the popup

Design questions:

• When you navigate to the topmost item, and push one more time UP, the topmost item stays focused? or should it remove focus

Concepts:

• Filter value (F)
• Selected value (S)
• Displayed value (D)

Features / Behaviour:

• Typing inside the input field filters items with "contains" type of filtering
• combobox._filter is bound to the value that is used for filtering
• combobox._filter accepts any string
• combobox.value is bound to the selected value
• After the popup is closed, D is always S
• When the popup is opened, D is always S
• When you start typing into the input box, D is changed to F
• If popup is closed when you start typing, it should open (desktop only ofc)
• F is cleared when the popup is closed (either by selecting value or canceling)
• Blurring the input does not clear F nor change D to S

Design questions:

• Tabbing out from focus input - should it cancel selection and close popup?

Possible issues:

• We probably need a second input for the fullscreen approach

The "GLOBAL" text can be seen partially above the blue underline.

Acceptance criteria

• The list items can no longer be seen outside the dropdown element in any situation

After closing the fullscreen mode, iOS sometimes zooms in the page instead of returning to the original view. In some tests it was even more frequently reproduced if the HTML document already has a viewport meta tag.

<meta name="viewport" content="width=device-width">

From http://wc.demo.vaadin.com/combo-box-usertest/index.html:

When iPad is attrached to an extgernal keyboard, it is impossible to navigate between items on up and down keys.

Currently, scroll position does not follow focused item when using keyboard navigation.

• Focused item should be aligned with "scroll-to-any" (escalator term)

Implement the Material Design styling designed in ticket vaadin/components-team-tasks#22