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
It strikes me there might be some delay in the second approach, simply
I hope this question makes sense.
On Thu, Apr 19, 2012 at 10:29 AM, Brion Vibber <bvibber(a)wikimedia.org>wrote;wrote:
On Wed, Apr 18, 2012 at 2:43 PM, Jan Piotrowski
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
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
don't understand this objection. You can
start a search as soon as you
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
On first launch, I'll probably do one of two things:
* search for something in particular
* 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.
Mobile-l mailing list
Phil Inje Chang
Product Manager, Mobile
415-882-7982 x 6810