Wordpress-ios: Search Button for Themes Should Be on Top Right Portion of Navigation Bar

[sendhil]

Right now on Themes the search button is embedded in the web content. We should probably change this to a button on the right side of the navigation bar to more closely match native patterns(we see an example of this on the My Sites page). The motivation behind this is that when we tap on search on the web portion of themes and it jumps to the native search box at the top it feels like there's a little bit of a disconnect as compared to other parts of the app.

Here's some videos of what I'm talking about. This is what the theme search looks like now:
https://cloudup.com/cm4XfaZKAuH

Here's what it looks like on my sites:
https://cloudup.com/cgvoW-s6GjY

Here's what I think would be ideal on Themes Search:

[sendhil]

Since this is quasi design related, @mattmiklic thoughts on this change?

[mattmiklic]

Since this is quasi design related, @mattmiklic thoughts on this change?

Agreed 💯 -- in iOS, I'd look for the search either at the top of the content view (like in Mail) or an icon in the toolbar. A toolbar icon seems like the best solution here.

[kurzee]

Oops, looks like I created a duplicate in https://github.com/wordpress-mobile/WordPress-iOS/issues/5583

[kurzee]

I just pushed a branch with the fix for this as the search icon in the navigation bar, top-right.

https://github.com/wordpress-mobile/WordPress-iOS/tree/issue/5583-replace-themes-searchbar

@mattmiklic can you take that branch for a spin to make sure the icon/design is as expected?

[kwonye]

This initial design was due to there being a dropdown next to it that searched free/premium/all themes. I do want to make sure @folletto knows about this as this was his design.

Also, if this is what we want to do, we should do the same for Android.

[kurzee]

The fix I pushed above removes the bottom bar completely to look as so:

If we re-enable the ability to make purchases (which is currently hardcoded to disabled) the drop-down is shown as:

If we do end up enabling this drop down, it would probably better be served a native segmented control.

[folletto]

Thanks for the ping. I'm not against these design changes, but please be aware that the choices that were done here were to be consistent across Web / iOS / Android, finding a balance between the different patterns and cases.

So, if we want to change it, my quick answer is that we should do first some design work across all the three to make sure we're not causing any dissociation or regression. My guess is that it's probably doable without too much trouble, but I feel uncomfortable in pushing asymmetrically such a change without checking. Check specifically the design done for M4-M7 milestones on Hyperion's P2.

[kurzee]

@kwonye can you shed insight on the availability of showing free/premium/all themes? Currently this is hardcoded to disabled on iOS, so the dropdown is never shown, in which case there is no need for a space for the dropdown as currently seen.

[apeatling]

@folletto I think in terms of how this works, it's going to be exactly the same, just having the initial search icon in a more native position. Using in the apps right now feels very strange and disconnected from tapping the search box to seeing a native one appear in the header.

[folletto]

@apeatling I agree. As said above, I'm not denying that in any way. iOS has both the "top search in the corner" pattern, as well as the "search at the top of the list" (usually hidden below an initial scroll), and when we did this design we decided to opt for the decision above, which also includes filters and matches perfectly Calypso patterns.

Using in the apps right now feels very strange and disconnected from tapping the search box to seeing a native one appear in the header.

This was an efficient choice to make it work and release it. Ideally should have been a standard search within the page, leveraging the in-page compoent.

I repeat to be super clear: I'm not against it, I'm saying that it needs to be cross checked (it's 23:43 here now, otherwise I would have done it myself to help).

It's likely to be ok, but we really must avoid to do these changes unilaterally.

[folletto]

For reference, the pattern that component followed when it was designed is this native iOS one:

Which matches Calypso design patterns more closely than the lens in the top-right corner, thus that's why it was preferred.

Note furthermore that the "lens in the corner" instead of a search on the page causes issues in other pages like "Posts" and the site picker, where there are two icons showing up. The issue would be solved with the in-page search:

If there's a design disconnection between different screens on iOS specifically, I'd probably err to remove the icon in the top-right corner elsewhere too, not the other way around — even if, the problem here is really consistency, so either way, the important bit is that it's consistent both inside the iOS standards as well as in the Calypso ones. I'd be ok with either.

[kurzee]

@folletto that's probably the best direction in general. I found the same thing on a separate issue today in https://github.com/wordpress-mobile/WordPress-iOS/issues/4343#issuecomment-227255572.

Ultimately, the app should probably move towards search bars within the header of table views, rather than within the navigation bar itself. This would be a much larger change across the Post/Pages list, Blog list ,Themes and maybe the Reader if we're keeping absolute consistency.

[folletto]

if we're keeping absolute consistency.

I agree, and we should aim for consistency. I think that this thread is more us reaching an agreed way forward holistically across the various platforms and screens, more than a yes/no on this specific instance.

If we're all aligned that the end goal is to have search in-page – in the header of the table view – then it can happen staggered section by section, as it's seen fit. :)

Either way we choose, the search on this page needs some fixing due to the odd "it's on page but then triggers search in the navigation" behaviour which you and Andy pointed out. :)

[mattmiklic]

Ultimately, the app should probably move towards search bars within the header of table views, rather than within the navigation bar itself. This would be a much larger change across the Post/Pages list, Blog list ,Themes and maybe the Reader if we're keeping absolute consistency.

Agreed on both points; this is the more native iOS UI to search and it would be a much bigger change. I was OK with switching to a search icon in the navigation bar as a more-native-than-the-status-quo change, but don't have any beef with doing this instead. It'll just require taking a look at each section to make sure it looks and works as intended, and makes sense with anything else that might appear at the top of the view like a segmented control.

[kurzee]

Awesome, I think a larger to-do can be opened for the header search bars. However, in the mean time, we still have a blank space for the currently unused/unseen dropdown.

The above fix could be a nice holdover for the blank space and inconsistent search icon placement, until the larger change (which would still have the blank dropdown space) is ready and shipped.

[kurzee]

CC @aerych for the Reader search https://github.com/wordpress-mobile/WordPress-iOS/issues/5539#issuecomment-227295235

[aerych]

Thanks for the ping @kurzee. I we might be dodging the issue for the reader. Once the new menu is in the lens icon in the upper right of the reader list will go away and the search controller will be presented from the menu instead.

[kurzee]

Merged in the fix for moving the search icon to the top-right and removing the empty space: https://github.com/wordpress-mobile/WordPress-iOS/pull/5587, this will land in 6.4.

Moving forward, we'll be working on those search bars to be inline header views as part of the iPad refresh: https://github.com/wordpress-mobile/WordPress-iOS/issues/5576