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