For section highlighting, I would say it is the section that is visible and
topmost on the screen. When a section header hits the fixed header it
becomes the current section as far as the TOC is concerned.
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris <bharris(a)wikimedia.org>wrote;wrote:
Replies to a couple folks, in-line.
On Jan 20, 2014, at 4:02 PM, Steven Walling <swalling(a)wikimedia.org>
wrote:
I think the main edit button at the top should
not be the quiet state
from mw-ui. There is very little use of color on the skin
now, so it's not
like we're overwhelming things. We need to stop being afraid to make a few
things LOUDER, particularly since in this prototype we're removing some
color (like the Vector borders).
So, I tried it with the main edit being blue and it was *crazy*
loud. The most-important thing in the page loud. So I made it quiet and
it looked better.
Now, this speaks to the larger problem we’re trying to solve:
user awareness of the edit button.
We know that Vector’s tab layout has trained people to pretty much
ignore the tabs, so they don’t see the edit tab (tab blindness, call it).
By pulling the tabs into the main content area, we are working to solve
that - to bind the actions directly to the content they affect.
Currently the tab blindness causes people to not know they can
edit, so we have fewer editors.
I think think that making the edit link loud will definitely
*increase* overall edits (in fact, I’ll stake my job on it), but I think it
will result in a radical increase of *bad* edits as well. Too many “kick
the tires” vandalisms, maybe.
It’s definitely something we can test, though.
On Jan 21, 2014, at 11:58 AM, Jared Zimmerman <
jared.zimmerman(a)wikimedia.org> wrote:
• I think we should explore putting Watch
and TOC together, or at
least associating them more closely.
In this case, I’d pull the Watch icon from the sub-bar and just
leave it in the header always.
However, I’m not sure this is the best plan (discussed below).
• tipsy being to the left of, covers the
other icons, I'm not sure
if we even need it, perhaps we could just rely on
regular browser tooltips.
Yeah, I put them to the left because they were obscuring the TOC
when done below. I think we can deal with this discoverability fairly
easily.
• I think that moving the TOC icon over
should be animated,
currently the snap makes me look up, and is a bit distracting,
the opposite
of what we want.
More difficult than you think. You’re asking for an ease-in on a
thing that already has a defined width. I’ll see what can happen, though.
• I think we can kill the in-line TOC
Disagree. I think people expect it, per-Quiddity.
• You can't currently scroll the TOC
flyout
Fixed.
• Idea : highlight the current section in
the TOC flyout
Problematic. What is the “current section”? What if there are,
like, 5 visible sections? Is the highlighted section the h3, the h4, or
the h2?
• when language list is not collapsable the
left sidebar take a
long time to go away
Languages are open by default so we should design with that in
mind. I’ve added toggles for the sections, though.
• Placeholder text and user input is not
aligned with each other
in search box
I’m not seeing that. The input sits in the exact space for me.
RE: Page actions moving into the header: (This is me collecting my
comments from a meeting to this list)
As I mentioned in yesterday’s design review, my gut instinct is
that moving article actions into the header is the wrong path:
* I don’t think they’re needed up there. People
already scroll to the top when they need these functions.
* I think it conflates those actions with the
“personal bar” actions and creates confusion. A primary motivation for
Winter is to segregate the following types of actions: Site actions
(sidebar chrome), Content actions (page stuff), and Personal actions (user
stuff). The search box is a site affordance. The personal actions are
obviously thus. Mixing article actions next to the personal actions seems
weird to me.
* The point of discussion being always available
is a valid one - the use case being, “I’m in this section, and I see an
error, and I want to talk about it”. However, I don’t necessarily think
that dumping the user into the “master” talk page at any point is going to
solve that. A long time ago I had the idea to add a “discuss” link next to
the section edit links. This would target the specific section and create
a new discussion with that title (or find an existing one) and work within
that. This is obviously something that can easily be done with Flow
(though my original thoughts were with LQT). I’m not sure it works well
with Talk. This is something I’ll want to experiment with.
Whuff.
---
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