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(a)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(a)wikimedia.org> wrote:
On Sun, Apr 28, 2013 at 3:03 AM, Jon Robson <jrobson(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design