Page MenuHomePhabricator

Improve usability of Search bar on Mobile Web
Closed, ResolvedPublic3 Story Points

Description

Hypothesis
Wikipedia top bar right now has no indication of it being a editable textfield. The possibility of it getting confused with just a side header is higher. It is not intuitive field or inviting field for user to type into. If we improve the visual design, more users will recall to search right within Wikipedia. It will also increase overall number of searches.

Metric to measure
Number of search across mobile web

Status quo


As you can see the search field (search wikipedia) is not intuitive and obvious

Proposed mock
We want to do a small change where we improve the usability of the field by changing the visual treatment as shown below


Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 15 2016, 12:18 AM
Nirzar claimed this task.Mar 22 2016, 4:33 PM
Nirzar updated the task description. (Show Details)Mar 28 2016, 6:14 PM

Change 282404 had a related patch set uploaded (by Bmansurov):
WIP: Beta: UI debt fixes

https://gerrit.wikimedia.org/r/282404

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 9:57 PM
debt added a subscriber: debt.May 5 2016, 3:30 PM
Jdlrobson set the point value for this task to 3.May 9 2016, 4:30 PM
bmansurov added a comment.EditedMay 9 2016, 6:46 PM

@Nirzar, do we also need to style the search box inside the search overlay?

Never mind, I see the mocks above.

@Nirzar Is one of the mocks showing the :focus state of the input?

Some problems that came out during review.

  1. I expect this to go through the beta channel first to allow us to assess the design before pushing it but we haven't written this in the description. Should we?
  1. @Nirzar how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

If these should be different they should be documented in the code with reasoning to avoid confusion later on about when to use the gray background and when not too.

  1. Also as @Volker_E points out we have no focus state for this search. Given we don't have one for the current design, this is not a regression, but for the purpose of accessibility, it would be good to tackle this in a later patchset/task if we can.
Nirzar added a comment.May 9 2016, 9:56 PM

I expect this to go through the beta channel first to allow us to assess the design before pushing it but we haven't written this in the description. Should we?

This is a very minor fix which improves the usability based on very very basic graphic design principals. if it was anything more than that i would avoid such rollout.

how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

Actually it doesn't it's not strange. In any chrome, designers have been using the titlebar to expose searchfields. it's a norm by now.
plethora of examples > http://pttrns.com/search?q=search
the titlebar space is reserved for titles or search bar if it suits the case

Also as @Volker_E points out we have no focus state for this search. Given we don't have one for the current design, this is not a regression, but for the purpose of accessibility, it would be good to tackle this in a later patchset/task if we can.

definitely, since we are also thinking about this bar on desktop. I can put up a mock right away which uses our style guide.

This is a very minor fix which improves the usability based on very very basic graphic design principals. if it was anything more than that i would avoid such rollout.

Be careful with your words. By telling me this "is a very minor fix" you've already set my alarm bells ringing :). When we tinker with such important things we risk regressions on the thousands of devices we work with. It has been an unwritten team norm that all changes (non bug fixes) go through beta. I think we should continue with this. If we don't like this we should talk about it as a team and revisit in retrospective.

how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

Actually it doesn't it's not strange. In any chrome, designers have been using the titlebar to expose searchfields. it's a norm by now.
plethora of examples > http://pttrns.com/search?q=search
the titlebar space is reserved for titles or search bar if it suits the case

I don't follow. My corner isn't with the titlebar space being reserved (we've always done this) but it is with the inconsistency that the title bar is still white for overlays and gray for search. In the link you post the colour/design looks consistent for all the examples.


chrome header is white (even worse the following header is the gray of the new header)


chrome header is white


the search in the language overlay is inconsistent from the global search. Is this intentional?


new chrome header is gray, the close icon is more bold to that of talk and languages

Thanks in advance for helping me come to a shared understanding with you.

Be careful with your words. By telling me this "is a very minor fix" you've already set my alarm bells ringing :). When we tinker with such important things we risk regressions on the thousands of devices we work with. It has been an unwritten team norm that all changes (non bug fixes) go through beta. I think we should continue with this. If we don't like this we should talk about it as a team and revisit in retrospective.

I will stand by my words, *It is* a minor change. it consists of background color and bounding box for search box. users do not care about what goes behind the code. if we can't change such simple things on our website without causing bugs, I do not know what we can do to improve our products.

as far as beta goes, this is not a feature but improved treatment of a UI element. I will let @dr0ptp4kt take that call, I'm fine with beta if that's the norm.

the search in the language overlay is inconsistent from the global search. Is this intentional?

Modal windows can have different titlebars than base chrome. modal windows come on top of the basic chrome and it helps to differentiate between the layers.

new chrome header is gray, the close icon is more bold to that of talk and languages

This keeps changing from talk to search and its a UI consistency caused by idk what.. its there on production. It would be amazing to see this get fixed. it changes if you load the notification panels once. its reproducible bug

Good conversation. I will stop development until we come to an agreement.

Please post to the beta channel on the production cluster first. I agree it's low risk, so a week in the beta channel seems like plenty of time.

I've created the follow on task for deployment to the stable channel on the prod cluster at T134894: Ship refreshed search bar to stable channel mobile web and guesstimated that would happen in sprint 73.

@Nirzar would you be okay making the close 'X' a back arrow instead?

If I understand correctly, the implicit :focus state is the same circle 'x' that's already there for clearing the search box as before.

Jdlrobson added a comment.EditedMay 10 2016, 4:05 PM

@Nirzar would you be okay making the close 'X' a back arrow instead?

We currently only use the back arrow for the editor. The editor is the inconsistent one here in my opinion (see T73203 - awaiting feedback from a designer).

This keeps changing from talk to search and its a UI consistency caused by idk what.. its there on production. It would be amazing to see this get fixed. it changes if you load the notification panels once. its reproducible bug

You're right. I've updated T131931

Just a note, currently the change is 58 lines added, 39 removed. Although cosmetically minor it is not minor from a code perspective. We don't have any rules written down for what goes into beta first we only have this. I'm fine revisiting this to avoid these discussions later. I'd be more confident with this change were we better at signing off/testing and have a dedicated QA but none of those are true and I'd rather not be the one SWATing follow ups when this hits production.

@bmansurov the width of the field changes after focus. the width should be till the edge of screen (with the same padding as left) and if the notification icon is there, it should push it on left.

Change 282404 merged by jenkins-bot:
Beta: Enhanced search bar

https://gerrit.wikimedia.org/r/282404

@bmansurov Just checked on reading web staging. we need to fix the padding to be 15px each like shown here.

@bmansurov

  1. the title bars for other modal windows should remain white.
  2. on focus the whole field moves up by 1 px.

@Nirzar I've created a task for #2 (T134987) which is the current behavior in production. A patch for the other fixes is coming.

Change 288193 had a related patch set uploaded (by Bmansurov):
Search boxes fixes

https://gerrit.wikimedia.org/r/288193

@bmansurov the background color is the one we used while on the friday work session. i was hoping to get that color into our color guide by now but it did not happen.

because i don't want to bring inconsistency lets use

.header-container {

background-color:#f2f2f2 or f5f5f5 > whichever is in existing variables;

}

sorry about missing it earlier.

Change 288193 merged by jenkins-bot:
Search boxes fixes

https://gerrit.wikimedia.org/r/288193

*SIGNED OFF* from design

Jdlrobson reopened this task as Open.May 12 2016, 5:50 PM

This has caused a regression in stable -> T135158

I've submitted a patch and pulled the above task to code review. Hope no one objects given it's a regression.

@Nirzar please can you sign off?

Jhernandez closed this task as Resolved.May 19 2016, 12:06 PM
Jhernandez added a subscriber: Jhernandez.

This seems done, feel free to re-open if there is any additional issues.