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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.orgwrote:
Replies to a couple folks, in-line.On Jan 20, 2014, at 4:02 PM, Steven Walling swalling@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 muchignore 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 canedit, 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@wikimedia.org> wrote:
• I think we should explore putting Watch and TOC together, or atleast associating them more closely.
In this case, I’d pull the Watch icon from the sub-bar and justleave 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 sureif 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 TOCwhen 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 athing that already has a defined width. I’ll see what can happen, though.
• I think we can kill the in-line TOCDisagree. I think people expect it, per-Quiddity.• You can't currently scroll the TOC flyoutFixed.• Idea : highlight the current section in the TOC flyoutProblematic. 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 along time to go away
Languages are open by default so we should design with that inmind. I’ve added toggles for the sections, though.
• Placeholder text and user input is not aligned with each otherin 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 mycomments from a meeting to this list)
As I mentioned in yesterday’s design review, my gut instinct isthat moving article actions into the header is the wrong path:
* I don’t think they’re needed up there. Peoplealready 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design