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 <[email protected]>wrote: > > Replies to a couple folks, in-line. > > On Jan 20, 2014, at 4:02 PM, Steven Walling <[email protected]> > 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 < > [email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/design >
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
