(foxfood) The email app should show the search field without having to find out that you need to pull down



3 years ago
9 months ago


(Reporter: armenzg, Unassigned)


({feature, foxfood})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [bzlite])



3 years ago
User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Component: Gaia::Feedback → Gaia::E-Mail
Keywords: feature
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.
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Comment 2

3 years ago
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.
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)
Flags: needinfo?(jhuang)
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.
Keywords: foxfood
Keywords: dogfood
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.

Comment 6

3 years ago
It's indeed a higher level UX behaviour.
Need info Harly to check with framework team.
Flags: needinfo?(jhuang) → needinfo?(hhsu)

Comment 7

3 years ago
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.
Flags: needinfo?(hhsu)

Comment 8

9 months ago
Firefox OS is not being worked on
Last Resolved: 3 years ago9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.