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 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@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design