User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 Eom
Component: Gaia::Feedback → Gaia::E-Mail
Email has search; you need to pull down the top of the message list to reveal a search field. There used to be a separate button on the toolbar but that was intentionally removed by the UX team in favor of the single entry. Not that that is locally-synced-only-in-this-folder filtering search. Bug 807726 covers search-on-server.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
I'm morphing this bug. There is search and I'm OK without having a search button but I believe the UI should show the search field from the get-go. I'm a geek and I was not able to figure out how to do a search. I see that the UI is prettier by hiding the search field initially, however, this behaviour is non-standard for most mobile UIs. Even on the home screen, we show the search field at the top of the screen. We don't start from a hiden state. I'm OK with hidding the field once we start scrolling but it should show from the get-go.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: (foxfood) the email app does not allow you to search for emails → (foxfood) The email app should show the search field without having to find out that you need to pull down
(setting ni to email UX lead)
Note that I think we'll accidentally show the search field if there are very few messages in a folder, but that's technically a bug. The spec for a long time has been that the search field is always hiding by default.
I think it would be good as the foxfood bugs start coming in if we can get some higher level UX goals for the email app written down, to help triage the bugs better. It is very unlikely one email app will be able to satisfy all of the possible email workflows. For instance, on this bug, I can see one the high level goal stated along the lines of "the goal of the email app is to provide a quick triage of new inbox items, for checking email on the go." Given that and the limitations of how good search can be across email providers, search is seen as a secondary activity, and we want to de-emphasize search. Showing more of the inbox is seen as more valuable. But I am a developer on the email app, and just making a guess at the possible goal(s), UX needs to really needs to be the official word.
It's indeed a higher level UX behaviour. Need info Harly to check with framework team.
Flags: needinfo?(jhuang) → needinfo?(hhsu)
Right now we are designing the next generation UX behaviour, and search is an important part of it. As all of you may know, the search methods in different apps behave quite differently, and we are planning to have that fixed when we have a final search design. If we have time to change the search design on email, I would suggest to have email behave the same as music app, and to display the search bar when initiating the app as a hint to the user that there is a search bar there, and hide it after 1~2 seconds. That's my thoughts on this.
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.