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