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(a)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(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
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design