Talk:Mobile Full Screen Search Results

• Is the design shown on the screenshots here intended to be used specifically with the current mobile site design? I'm wondering how this would fit with the Athena design, which has curved edges around the search bar as well as a mostly sharp black/white/blue color scheme.
• The page says that "Touching the search icon in each row takes the user to that article page", but it does not elaborate as to what happens when the user clicks on the text part of the row.
  • I see that the page has been changed to explain what happens, but it doesn't explain what is the point of "selecting" a row...
• "Touching '+' adds that term to the search box." seems to mean that it actually adds the full suggestion text onto the end of the previously typed text, so that if someone is, for example, looking for "American Football League", types "Amer" and then clicks on the + icon next to "American Football", the content of the search box would then be "AmerAmerican Football", rather than "American Football ", as would be expected. The image File:Mobile search E.png seems to mirror this. I really don't see how this makes any sense.
  • I believe it would complete the first term, this is about adding additional terms. And it is true that in many cases this may not make such sense, we are investigating to what extent it would be a useful feature. heather walls 15:00, 9 February 2012 (UTC)
• The images show the search suggestions in all unbolded text, as opposed to showing the typed characters in bold (ie user types "Fra" and the search suggestion looks like France) as we have had previously. Is this deliberate?
  • This is not deliberate, thank you for pointing it out. heather walls 15:00, 9 February 2012 (UTC)
• Is the text bar generally visible after scrolling? Would it be perhaps fix to the top of the screen even after scrolling, or maybe clicking + would scroll the screen up to the top?
  • The text bar should always be visible (fixed). heather walls 15:00, 9 February 2012 (UTC)
• In the "Transformation to full screen search" section, there are references to "fading in/out". Does this refer to actually visibly being more/less opaque over a certain amount of time?

--Yair rand 12:01, 9 February 2012 (UTC)

• The idea of having the icons to the left of each search suggestion represent the page's namespace is interesting, but don't understand why the space for search suggestions would display blank entry spaces as though they were mainspace pages, as indicated by File:Mobile search B.png.
  • At the moment, the Wikipedia search only surfaces mainspace pages, so this is the only possibility. In the future this might change. Right now we can just call them placeholders and this gives us room for growth. heather walls 23:00, 12 February 2012 (UTC)

--Yair rand 21:05, 12 February 2012 (UTC)

Three mock requests

Could you do ..

• a mock of just the search results without the puzzle piece? (I know part of the reason to have it is alignment; it'd be nice to see what it looks like without it.)
• a mock of a simplified search extract (just text shortened with ellipsis, larger font size, no image or other links)?
• a version of the search results with no gradient, just gray/white alternation

That would help me to understand some of the potential paths here. Thanks,--Eloquence (talk) 03:38, 16 February 2012 (UTC)

Yes. heather walls (talk) 07:38, 16 February 2012 (UTC)

Many thanks. I personally prefer all these simplifications, and would like to see strong justifications for any additional design complexity (as a general principle, I think we should bias towards minimalism on mobile).

If you have time, I'd love to see us play more with the text extract idea. Specifically:

1) Does it even make sense to include links in the preview? I kind of like the idea of navigating from the links, but it could potentially be very frustrating if you're accidentally tapping a link when your intent is simply to tap the search result. That perhaps can be answered only with at least hallway-testing.

2) Right now the UI suggests that the preview appears for all results. Can we figure out an interaction workflow along the lines of:

USER ENTERS SEARCH TERM → (Results appear) → USER SELECTS SEARCH RESULT → (Preview loads) → USER TAPS DIFFERENT RESULT → (Old preview disappears, new preview loads) → USER TAPS PREVIEW → (Full article loads)

Perhaps that would only be an optional flow, with the primary interaction being directly loading the article from the collapsed result list -- in which case we'd want a simple "preview" action (a collapse/expand symbol would make the most sense to me, perhaps occupying the space of the puzzle piece).--Eloquence (talk) 06:48, 17 February 2012 (UTC)

I've updated the search mocks in a more simplified form, links removed. Some with a collapse/expand symbol. I'm not entirely sure the symbol is necessary though, the user can just select the search term to reveal the preview. heather walls (talk) 22:10, 21 February 2012 (UTC)

Here is a minimal interface to go along with this simplified search. heather walls (talk) 22:25, 21 February 2012 (UTC)

Beautiful, thanks. The "X" icon may need a circle around it to reduce ambiguity with "close/back" actions and clarify that it's a "clear" action. As for the preview, I think we'll want to play with that a bit, but I like this to start prototyping.--Eloquence (talk) 19:37, 22 February 2012 (UTC)