Folks,
Lindsey has posted more detailed wireframes here:
https://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation#More_Detai...
This provides details at the submenu level.
There is one more workflow coming soon which shows the path of going to a submenu, canceling, and going back to the last article, which is the reason for the "Read" command at the top of the main menu.
Hopefully this is sufficient to begin some prototyping.
All of the prior discussion around icons and hiding the search bar have not been forgotten. Those explorations will be next.
We are also doing some planning around testing the effect of showing the search field open or closed. The site and apps have so far shown the search field open, so we want to know if having it closed by default will affect search behavior. Any thoughts out there about this?
Comments welcome.
Phil
Lindsey has posted more detailed wireframes here:
https://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation#More_Detai...
This provides details at the submenu level.
Some questions:
1-initial-entry-and-search.png
After the app is launched you have to click twice to get to the menu? The app is launched with the keyboard open? The launch experience consists largely of an empty page?
(You probably already got I would say all these things are not good)
all wireframes
What does the "| --- static ---|" indicate?
J
Brion, great points about the tablet design issue. Keep 'em coming! We need to show some variation around iPhone browser vs. Android browser and the two apps, and it makes sense to branch out from there into tablet versions.
Jan, some quick replies to your comments:
If a user launches the app or goes to the mobile site directly, the first action is a search. Otherwise, the user gets there from a search or link elsewhere.
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.
If there is a likely first action in the menu, what do you think it would be?
"Static" simply means that the menu view does not further change within itself. Instead, a new screen slides in.
Phil
On Wed, Apr 18, 2012 at 1:43 PM, Jan Piotrowski piotrowski@gmail.comwrote:
Lindsey has posted more detailed wireframes here:
https://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation#More_Detai...
This provides details at the submenu level.
Some questions:
1-initial-entry-and-search.png
After the app is launched you have to click twice to get to the menu? The app is launched with the keyboard open? The launch experience consists largely of an empty page?
(You probably already got I would say all these things are not good)
all wireframes
What does the "| --- static ---|" indicate?
J
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Wed, Apr 18, 2012 at 2:20 PM, Philip Chang pchang@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?
-- brion
Brion,
Apparently the issue is more psychological. It looks like the main activity is the article. But the change is recent and possibly not as big an issue. Worth testing.
Phil
On Wed, Apr 18, 2012 at 2:23 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Wed, Apr 18, 2012 at 2:20 PM, Philip Chang pchang@wikimedia.orgwrote:
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?
-- brion
Copying Trevor.
On Wed, Apr 18, 2012 at 2:39 PM, Philip Chang pchang@wikimedia.org wrote:
Brion,
Apparently the issue is more psychological. It looks like the main activity is the article. But the change is recent and possibly not as big an issue. Worth testing.
Phil
On Wed, Apr 18, 2012 at 2:23 PM, Brion Vibber bvibber@wikimedia.orgwrote:
On Wed, Apr 18, 2012 at 2:20 PM, Philip Chang pchang@wikimedia.orgwrote:
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?
-- brion
-- Phil Inje Chang Product Manager, Mobile Wikimedia Foundation 415-812-0854 m 415-882-7982 x 6810
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?
If this is decided and defined, you can start to build the flow.
-J
On Wed, Apr 18, 2012 at 2:43 PM, Jan Piotrowski piotrowski@gmail.comwrote:
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
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.orgwrote:
On Wed, Apr 18, 2012 at 2:43 PM, Jan Piotrowski piotrowski@gmail.comwrote:
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
On Thu, Apr 19, 2012 at 3:51 PM, Philip Chang pchang@wikimedia.org wrote:
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.
The animation shouldn't take any longer than it typically takes to move your thumb around the screen to start typing, ideally.
-- brion
On Wed, Apr 18, 2012 at 11:51 AM, Philip Chang pchang@wikimedia.org wrote:
Folks,
Lindsey has posted more detailed wireframes here:
https://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation#More_Detai...
This provides details at the submenu level.
Awesome!
We should think about how those submenus are going to look on tablet devices; if it takes the full device width, then we should probably arrange the icons in it over to the right to be near the activation point for the submenu, rather than having them left-aligned.
Alternatively, the submenus can be smaller, and not full screen width.
-- brion