whoops. sending fail... ---------- Forwarded message ---------- From: design-owner@lists.wikimedia.org Date: 26 Apr 2013 08:46 Subject: Re: [Design] Left nav/right nav To: jdlrobson@gmail.com Cc:
You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at design-owner@lists.wikimedia.org.
---------- Forwarded message ---------- From: Jon Robson jdlrobson@gmail.com To: "A list for the design team." design@lists.wikimedia.org Cc: Date: Fri, 26 Apr 2013 08:46:08 +0100 Subject: Re: [Design] Left nav/right nav
Raging hatred is for having 2 places for menus. History has shown us (user testing) that secondary menus are not discoverable. People always look in the hamburger first (or don't even find that!!) That said a user button makes sense if it takes a user to a profile page.
I'm mostly worried about moving things from the left menu to another menu and having a second menu. Somehow even though login, watch list and uploads belong to a user they are a site activity in some ways and I'd still prefer to see them in the left menu. To me a profile would best serve access to user page, stats and user talk page but not incorporate the other things. Having 2 menus also makes the user have to think is that in x menu or y menu?
"I don't understand. When I press our current hamburger, the page moves to the right and my finger is over the Home button..." That's what 24 hrs without sleep does to you. :) I can't articulate what it is about the Facebook app and wiki right menu prototype I don't like but this is not in. Just something feels unnatural about it. In terms of fb it could be the inconsistency...on private messages hitting info hides the button and leaves hamburger in place but doesn't do this for news feed. It may however be the fact the right user menu is just not how I use Facebook and contains features I see as useless. The search on the left menu in Facebook serves the exact same purpose.
I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then a place to find features. Where watch star goes is another question.
In terms of fixed positioning the only way to do this reliably and nicely (and then only if JavaScript is enabled) is to use something like iscroll and reimplement native browser scrolling. On 25 Apr 2013 20:30, "Juliusz Gonera" jgonera@wikimedia.org wrote:
That's more like it ;) Also, I'd squeeze in a few most recent notifications in there when we have Echo.
On 04/25/2013 12:11 PM, Maryana Pinchuk wrote:
You're right, Vibha; a picture is worth a thousand words :)
Jon, ignoring the specific elements of what's in the "me" menu (all just placeholders at this point), does my scribbling below make more sense conceptually? Despite the "nav" in the title, the story card actually leaves implementation pretty open: https://mingle.corp.wikimedia.org/projects/mobile/cards/579. I can clarify in the title of the card and the A.C. that this should be an overlay, not a nav. Does that address some of your concerns?
[image: Inline image 1]
On Thu, Apr 25, 2013 at 11:32 AM, Vibha Bamba vbamba@wikimedia.orgwrote:
At this point we should be doing this at a whiteboard. There are some legitimate concerns but text is hardly a medium to improve ideas =]
On Thu, Apr 25, 2013 at 11:21 AM, Maryana Pinchuk < mpinchuk@wikimedia.org> wrote:
On Thu, Apr 25, 2013 at 10:39 AM, Jon Robson jrobson@wikimedia.orgwrote:
I'm beginning to exhibit raging hatred of the right nav concept...
Firstly.. Ergg. two settings is confusing (site and user) - they should be the same page and there is no reason why they can't be. It would be great if when logged in the settings page morphed from device specific to user specific. Would be great to be able to activate alpha on all my devices.
In terms of a right nav, the more I think about it and having played with a prototype I knocked up, the more I think a right nav is bad. Although it seems to be becoming an established pattern it seems like an easy option that in my opinion is badly implemented. We can do better and should lead by example. For one I never touch the Facebook one... it just doesn't come natural. I also don't like the idea of 2 menus. I wonder if we could envision 2 stacked menus that can be toggled between and persist when selected.
To quote http://www.upassoc.org/upa_publications/jus/2011august/faulkner2.html "... Kingsburg and Andre carried out two studies with 16 users and found in both of their studies that selection from a left-hand menu was faster than from a right-hand menu (2004). However, their research also showed that selections were best done from the same panel, whether that was on the right or left. Thus it is better to have a single design, either on the left or the right, rather than a mixed navigational method that requires the user to select from both left and right panels (Kingsburg & Andre, 2004). This is hardly surprising and is both predicted and supported by Fitts’ Law. (1954)."
The thing that bugs me most is that when you move your finger over the left hamburger button and press it the page moves to the left. Your finger is still above the button. This doesn't apply to the right menu. Your finger is now above something else. This to me is very jarry and always feels icky.
It still leaves the question of where things such as watch star, talk page link, edit, move and delete buttons go. The bottom would make sense for an app, but position fixed is buggy in the majority of current mobile browsers and we will need a fallback of some sort.
Is it just the "nav" part that bothers you, and not so much the "right" and "my stuff" part? What if we had a little person icon to the right of the search bar, and tapping that opened an overlay with pretty visualizations of your recent editing and uploading activity, as well as links to your watchlist and talk page? *That's* what I ultimately want to work toward; in my mind, the nav part was always just a stepping stone, but maybe we don't actually need that stepping stone and can just go directly to (sneakily) beginning work on a totally new, totally rad mobile userspace :)
-- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org
Design mailing listDesign@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Sun, Apr 28, 2013 at 3:03 AM, Jon Robson jrobson@wikimedia.org wrote:
I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then a place to find features. Where watch star goes is another question.
I tend to agree with Jon on this; two menus _is_ harder to discover, but it's a good place to put an individual button or two that don't need to be followed through a submenu.
Another thing to consider is changing how we deal with the search bar to give us more space. Bringing, again ;) Facebook as an example -- search is prominent *in the left nav menu* but only has a full field when you're actively there. Their regular header bar instead has three buttons (one of which I actually use, for notifications).
If we collapsed the initial search field into a search button that opened the search overlay (or, a link to a dedicated search page on no-JS), we'd have more room for things like the watchlist star. A "user profile/notifications" combined button could serve as the login CTA as well.
In terms of fixed positioning the only way to do this reliably and nicely (and then only if JavaScript is enabled) is to use something like iscroll and reimplement native browser scrolling.
We had bad performance with iscroll in iOS 4 on the PhoneGap app; I'm not sure I'd recommend using it. Its performance gets worse and worse as your page size increases. :(
I think I'd rather have non-floating toolbars where position:fixed is not known to work as expected, or just live without them entirely. :P
-- brion
So to replay some of the talking points, it sounds like:
- some people like the idea of two separate menus, and some don't – the main argument for the latter being a possible lack of discoverability/understanding of what features live where - everyone agrees that a dedicated user profile and notifications are a good thing, though there are different ideas for where those things should live - people mostly agree that we need to associate article-related actions (e.g., edit, watch, upload) closely with articles somehow
I do worry about the discoverability factor of an additional chrome item, as well... but not very much, given how many logged out users tap the watchlist star (about 100,000 every day!), and given that the "right-hand my stuff" concept is quite close to what's currently on desktop wikis. I also think we won't know for sure if this is an issue until we experiment with it, and it's not the kind of thing that will be hard to deduce from the data right away – if we see the number of watch and upload actions decrease, we'll know that it isn't working. The payoff, to me, is piloting a scalable personal space that can grow to fit the mobile site of 2015, with notifications, user-to-user messaging, global profiles, and who knows what else :)
Anyway, given that we have a bunch of other work in the next sprint, I'm pushing back the nav-related cards to the iteration after next, so we can have more time to crystallize our thinking on this. And though the implementation details are still TBD, I do think we have three main story cards emerging:
1. an article action bar that can scale from just one action on every article (watch) to a multitude of actions (edit, upload, talk, etc.), depending on whether the user is logged in, on beta/alpha/stable, is on a device that supports certain features, etc. 2. a user page with a synthesis of key information about a user (which may or may not contain links to features like watchlist and uploads, and may or may not be triggered from the left nav) 3. either a redesign of the left nav, or a right-hand user icon that triggers the user page, which also includes links to watchlist and uploads
Before digging into these stories further, it would be good for me and Vibha to sit down with any devs who care to join and figure out the implementation costs for the various options that are on the table – perhaps sometime next week, when Jon is fully back in action?
On Apr 28, 2013, at 8:56 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Sun, Apr 28, 2013 at 3:03 AM, Jon Robson jrobson@wikimedia.org wrote:
I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then a place to find features. Where watch star goes is another question.
I tend to agree with Jon on this; two menus _is_ harder to discover, but it's a good place to put an individual button or two that don't need to be followed through a submenu.
Another thing to consider is changing how we deal with the search bar to give us more space. Bringing, again ;) Facebook as an example -- search is prominent *in the left nav menu* but only has a full field when you're actively there. Their regular header bar instead has three buttons (one of which I actually use, for notifications).
If we collapsed the initial search field into a search button that opened the search overlay (or, a link to a dedicated search page on no-JS), we'd have more room for things like the watchlist star. A "user profile/notifications" combined button could serve as the login CTA as well.
In terms of fixed positioning the only way to do this reliably and nicely (and then only if JavaScript is enabled) is to use something like iscroll and reimplement native browser scrolling.
We had bad performance with iscroll in iOS 4 on the PhoneGap app; I'm not sure I'd recommend using it. Its performance gets worse and worse as your page size increases. :(
I think I'd rather have non-floating toolbars where position:fixed is not known to work as expected, or just live without them entirely. :P
-- brion
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Next week sounds good. As you can see I'm very opinionated as always ;-)
On Mon, Apr 29, 2013 at 10:03 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
So to replay some of the talking points, it sounds like:
some people like the idea of two separate menus, and some don't – the main argument for the latter being a possible lack of discoverability/understanding of what features live where everyone agrees that a dedicated user profile and notifications are a good thing, though there are different ideas for where those things should live people mostly agree that we need to associate article-related actions (e.g., edit, watch, upload) closely with articles somehow
I do worry about the discoverability factor of an additional chrome item, as well... but not very much, given how many logged out users tap the watchlist star (about 100,000 every day!), and given that the "right-hand my stuff" concept is quite close to what's currently on desktop wikis. I also think we won't know for sure if this is an issue until we experiment with it, and it's not the kind of thing that will be hard to deduce from the data right away – if we see the number of watch and upload actions decrease, we'll know that it isn't working. The payoff, to me, is piloting a scalable personal space that can grow to fit the mobile site of 2015, with notifications, user-to-user messaging, global profiles, and who knows what else :)
Anyway, given that we have a bunch of other work in the next sprint, I'm pushing back the nav-related cards to the iteration after next, so we can have more time to crystallize our thinking on this. And though the implementation details are still TBD, I do think we have three main story cards emerging:
an article action bar that can scale from just one action on every article (watch) to a multitude of actions (edit, upload, talk, etc.), depending on whether the user is logged in, on beta/alpha/stable, is on a device that supports certain features, etc. a user page with a synthesis of key information about a user (which may or may not contain links to features like watchlist and uploads, and may or may not be triggered from the left nav) either a redesign of the left nav, or a right-hand user icon that triggers the user page, which also includes links to watchlist and uploads
Before digging into these stories further, it would be good for me and Vibha to sit down with any devs who care to join and figure out the implementation costs for the various options that are on the table – perhaps sometime next week, when Jon is fully back in action?
On Apr 28, 2013, at 8:56 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Sun, Apr 28, 2013 at 3:03 AM, Jon Robson jrobson@wikimedia.org wrote:
I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then a place to find features. Where watch star goes is another question.
I tend to agree with Jon on this; two menus _is_ harder to discover, but it's a good place to put an individual button or two that don't need to be followed through a submenu.
Another thing to consider is changing how we deal with the search bar to give us more space. Bringing, again ;) Facebook as an example -- search is prominent *in the left nav menu* but only has a full field when you're actively there. Their regular header bar instead has three buttons (one of which I actually use, for notifications).
If we collapsed the initial search field into a search button that opened the search overlay (or, a link to a dedicated search page on no-JS), we'd have more room for things like the watchlist star. A "user profile/notifications" combined button could serve as the login CTA as well.
In terms of fixed positioning the only way to do this reliably and nicely (and then only if JavaScript is enabled) is to use something like iscroll and reimplement native browser scrolling.
We had bad performance with iscroll in iOS 4 on the PhoneGap app; I'm not sure I'd recommend using it. Its performance gets worse and worse as your page size increases. :(
I think I'd rather have non-floating toolbars where position:fixed is not known to work as expected, or just live without them entirely. :P
-- brion
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
people mostly agree that we need to associate article-related actions (e.g., edit, watch, upload) closely with articles somehow
I made some mockups http://i.imgur.com/M34i160.jpg to try some ideas about reducing chrome, location for article-related actions, and different navigation schemas. I share just in case they bring any useful idea.
Pau
On Tue, Apr 30, 2013 at 4:17 PM, Jon Robson jrobson@wikimedia.org wrote:
Next week sounds good. As you can see I'm very opinionated as always ;-)
On Mon, Apr 29, 2013 at 10:03 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
So to replay some of the talking points, it sounds like:
some people like the idea of two separate menus, and some don't – the
main
argument for the latter being a possible lack of discoverability/understanding of what features live where everyone agrees that a dedicated user profile and notifications are a
good
thing, though there are different ideas for where those things should
live
people mostly agree that we need to associate article-related actions
(e.g.,
edit, watch, upload) closely with articles somehow
I do worry about the discoverability factor of an additional chrome
item, as
well... but not very much, given how many logged out users tap the
watchlist
star (about 100,000 every day!), and given that the "right-hand my stuff" concept is quite close to what's currently on desktop wikis. I also
think we
won't know for sure if this is an issue until we experiment with it, and it's not the kind of thing that will be hard to deduce from the data
right
away – if we see the number of watch and upload actions decrease, we'll
know
that it isn't working. The payoff, to me, is piloting a scalable personal space that can grow to fit the mobile site of 2015, with notifications, user-to-user messaging, global profiles, and who knows what else :)
Anyway, given that we have a bunch of other work in the next sprint, I'm pushing back the nav-related cards to the iteration after next, so we can have more time to crystallize our thinking on this. And though the implementation details are still TBD, I do think we have three main story cards emerging:
an article action bar that can scale from just one action on every
article
(watch) to a multitude of actions (edit, upload, talk, etc.), depending
on
whether the user is logged in, on beta/alpha/stable, is on a device that supports certain features, etc. a user page with a synthesis of key information about a user (which may
or
may not contain links to features like watchlist and uploads, and may or
may
not be triggered from the left nav) either a redesign of the left nav, or a right-hand user icon that
triggers
the user page, which also includes links to watchlist and uploads
Before digging into these stories further, it would be good for me and
Vibha
to sit down with any devs who care to join and figure out the
implementation
costs for the various options that are on the table – perhaps sometime
next
week, when Jon is fully back in action?
On Apr 28, 2013, at 8:56 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Sun, Apr 28, 2013 at 3:03 AM, Jon Robson jrobson@wikimedia.org
wrote:
I'd really push us to leave the left menu as it is (with some visual separation) and think of the user button as more of a profile page then
a
place to find features. Where watch star goes is another question.
I tend to agree with Jon on this; two menus _is_ harder to discover, but it's a good place to put an individual button or two that don't need to
be
followed through a submenu.
Another thing to consider is changing how we deal with the search bar to give us more space. Bringing, again ;) Facebook as an example -- search
is
prominent *in the left nav menu* but only has a full field when you're actively there. Their regular header bar instead has three buttons (one
of
which I actually use, for notifications).
If we collapsed the initial search field into a search button that opened the search overlay (or, a link to a dedicated search page on no-JS), we'd have more room for things like the watchlist star. A "user profile/notifications" combined button could serve as the login CTA as
well.
In terms of fixed positioning the only way to do this reliably and
nicely
(and then only if JavaScript is enabled) is to use something like
iscroll
and reimplement native browser scrolling.
We had bad performance with iscroll in iOS 4 on the PhoneGap app; I'm not sure I'd recommend using it. Its performance gets worse and worse as your page size increases. :(
I think I'd rather have non-floating toolbars where position:fixed is not known to work as expected, or just live without them entirely. :P
-- brion
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Just another -1 for iScroll or similar solutions. I swear, almost half the commits to the Wikipedia app are fixes for random stuff that iScroll throws at you
On May 1, 2013, at 8:57 AM, Pau Giner pginer@wikimedia.org wrote:
people mostly agree that we need to associate article-related actions (e.g., edit, watch, upload) closely with articles somehow
I made some mockups to try some ideas about reducing chrome, location for article-related actions, and different navigation schemas. I share just in case they bring any useful idea.
Thanks so much, Pau! Really useful to be able to reference mockups :)
I like the right-most design in the bottom row. The problem with including the article title in the chrome is that many titles are incredibly long (lists, for example), and it looks pretty bad when they take up multiple lines and push the chrome down too much. Same thing comes into play with respect to article actions to the right of the title. We can't predict how long the title will be, so there will be times when it overlaps with whatever we put in that space.