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