Mobile/Archive/Virtual Keyboard

From MozillaWiki
Jump to: navigation, search


We're not implementing our own soft keyboard - Fennec will use the native soft keyboard on all platforms.

This project is to make sure that our UI is usable and effective even when a softkeyboard is deployed and so is taking much of the screen real estate.

In practice, this will be the result of three design areas:

  1. in general, only bringing up the keyboard when it's actually wanted (not prematurely, if the browser is making on-screen suggestions first)
  2. making sure that our UI is not obscured by the on-screen keyboard
  3. altering the mechanism by which people select a search engine, so that it's only on screen when it has to be -- this is so that we can use the sliver of the awesomescreen that is visible (esp. in landscape) when the user is typing for awesome-suggestions.

Current Status

Next Steps

Related Bugs


  • Project Lead:


Search Flow


Starting Point (common)

Before the user has started to type, the screen shows the pre-typing awesomelist and the category selectors. Important: we shouldn't bring up the VKB immediately on coming to the awesomescreen; an additional tap on the entry-field should be required.


Initiating Searching

Variant 1

Category bar gets replaced with horizontal-scrolling list of search engines. This shows up as soon as the user starts typing. Awesomebar results come in below.


Issue: this doesn't deal with the issue of taking up a whole row with a VKB present in landscape.

Variant 2


Variant 3

In most of these variants, we try to minimize the size of the search trigger UI (i.e. a button). We can get a bit more room by having the placement differ between the landscape and portrait orientations to take advantage of the width or height, respectively.


more detail:


Selecting Search Engine

Variant 1

Awesome list gets replaced with a list of search engines.


Variant 2


Goals/Use Cases

Non Goals