Brandon this is good stuff! Maybe we need a group whiteboard session to
address
a few legitimate concerns and post an updated prototype to the media wiki
page?
On Sun, May 19, 2013 at 12:26 PM, Brandon Harris <bharris(a)wikimedia.org>wrote;wrote:
Replying to all comments, in line.
This is an interesting exercise because it brings (back) up some
flaws with our current information architecture. I'll get into that at the
bottom.
On May 18, 2013, at 7:21 PM, Steven Walling <swalling(a)wikimedia.org>
wrote:
Key consideration: how would this interact with
the fixed toolbar of
VisualEditor?
I should expect that the VE's toolbar would dock just below the
user toolbar.
On May 19, 2013, at 12:07 AM, Jared Zimmerman <
jared.zimmerman(a)wikimedia.org> wrote:
Great mockup Brandon,
few notes
• A.search box moving location feels weird, B.I can see this
change being
part of a a header reorg in general but having search changing
position on scroll feels a little funny
Yes, I agree. This came out of our conversation the other day
about reducing the number of possible search fields that may exist on a
page and having them perform multiple duties. I'm not happy with the
current behavior.
There are a couple other ways to solve for this that come to mind
immediately, but they all have flaws of some kind or another:
1) Leave the search at the same vertical point and hiding
the tabs on scroll, increasing the width of the search.
- This increases the vertical size of the docked
toolbar (creates problems with the existing event with the logo branding,
but nbd)
- There's interaction issues with "when should the
tabs disappear)
2) Collapse the user tools to an icon or two (so that the
Echo notifications are still visible) and make the transition of the search
box more elegant
3) Move the tabs (see below)
• just played around with the visual editor
fixed header. I think
that we might be able to handle the visual design of VE
slightly
differently (skin change?) to further differentiate it from the fixed
header or vice versa. In an edit mode having two fixed headers might not be
the end of the world…it might, who knows?
It is my fervent hope that "edit" mode manages to eliminate a lot
of controls on the page that I don't think need to be there. Search, for
example, doesn't make a lot of sense to me in edit mode.
• search FREAKS out on browser resize, and
scroll on mobile.
Prototype. If you go through the underlying html and css, it's
very hackey.
• Having search in-line with the rest of
the profile bar(?)
further highlights the issue that there is too much going on
there, see
point 1.B
• Some easing/animation might help, when
you scroll quickly some
weird flashing/bouncing happens that is disconcerting, and
makes me cringe
a bit.
I'm using a library called "waypoints". It's possible for us
to
hook animations into it (when element X arrives at scroll position Y,
activate animation Z) but I wasn't so much concerned with that.
On May 19, 2013, at 1:47 AM, Bartosz Dziewoński <matma.rex(a)gmail.com>
wrote:
On Sun, 19 May 2013 09:07:30 +0200, Jared
Zimmerman <
jared.zimmerman(a)wikimedia.org> wrote:
> A.search box moving location feels weird, B.I can see this change being
part
of a a header reorg in general but having search changing position on
scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll
means that at
least one of the designs - the "basic" one we have right now,
or the scrolling one - is horribly broken.
I think both, and I'll explain why below.
Also, why is the personal menu kept on scrolling
instead of the article
tabs? Is it considered more important now?
Yes, if only for access to the Echo badge. In the future, there
may also be other important things that show up there that may need
permanence but Echo is the primary use case right now.
On to what I think are the main navigation problems.
It is my humble opinion that the primary issue we have is the
tabs. I've got a couple reasons why I don't think they work the best, but
the primary one is this:
They are not directly tied to the content that they
control.
In the Vector design, the user is trained to understand that
"things inside the blue line" are content, while what is outside of that is
"chrome". Further problematic is mixing *content* actions within *site*
actions (via the sidebar).
Moving the various tab functions inside of div.#content, perhaps
directly under the article title, will tightly bind them to the content.
(I also don't think they should be tabs. We break our metaphor
when we have *two* active tabs at any one time.)
This then leaves us plenty of space in the top for all sorts of
fun stuff - like making the search box full width.
I can probably throw something together to illustrate this without
much effort.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge:
http://wikimediafoundation.org/wiki/Donate
_______________________________________________
Design mailing list
Design(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design