Brion,
Here is an important question:
Will it be easier to enable instant access to search through the current method - tap on the search field - than through the approach shown in the design comps of a search button exposing the search field and activating search?
It strikes me there might be some delay in the second approach, simply because more JavaScript is involved.
I hope this question makes sense.
Phil
On Thu, Apr 19, 2012 at 10:29 AM, Brion Vibber
<bvibber@wikimedia.org> wrote:
>> The initial view will allow the user to go to the home page or select a
>> random article. We have gotten numerous comments about not requiring the
>> initial content to download before a search is initiated. Of course, we
>> could show the initial content while also showing search activated.
>
> Since content is downloaded asynchronously, and there's no modal spinner, I
> don't understand this objection. You can start a search as soon as you
> like... right?
Exactly.
I think this is one of the aspects, where the "one unified mobile UI"
thing jsut doesn't work. For a website it's kind of hard to download
stuff asynchronously if it should stay simple. Also people don't
expect it from a website. But for an app, it's totally different. The
users knows that the app can download the content while you already
can type a search. Also the app should be usable instantly - waiting
for some content to download is not as acceptable as in a website.
I suggest there should be a discussion on the launch experience: What
does the user get after starting? We all agree there should be a
search box, I think, but everything else is still undecided. "Article
of the day"? A home page? Something else? Same experience on mobile
web as in an app? Different? Same on all platforms of apps?
On most launches, I'd expect the app to show me whatever I left off on -- and it should be easy to start a new search by tapping into the search field.
On first launch, I'll probably do one of two things:
* search for something in particular
or
* look around for something to browse
If there's a search field I can tap into, then I can search easily. If there's nothing else also loaded though, and I just wanted to browse, then I might be a bit at a loss -- so I'd rather see some content loaded, probably today's featured article etc.
I don't think there's any need to start with the search box actively *open*; for one thing that'll either open the keyboard without invitation (surprise!) or it won't actually open the keyboard and I'll still have to do a tap to actually get the focus on the field.
-- brion
_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Phil Inje Chang
Product Manager, Mobile
Wikimedia Foundation
415-812-0854 m
415-882-7982 x 6810