Some responses

the blue "edit" button flashing at a user during scroll won't be
acceptable
Jared - I think the concept of having a two stage normal → hover → highlight region, where currently normal is hidden, I think we could transition to a "quieter" normal state that isn't hidden, more to test.

the section highlighting is neat, but may have difficulty integrating
with VisualEditor
Jared - Doubt it will be difficult since it has nothing to do with VE (its before VE is invoked) but VE section editing is in the works so we're aligned on that. 

moving the section links back over is probably more "cognitive load"
than users are willing to deal with

Jared - I don't know what this means, do you mean the edit links on the right vs to the right of the section headers? I do think having them in a fixed location is a good idea but right aligned vs left will be something to test and get feedback on

many editors will hate requiring two clicks to access tools in both
drop-down menus
Jared - for feedback on the personal bar dropdown put that here please https://www.mediawiki.org/wiki/Compact_Personal_Bar for the article actions, the menu could be either on hover or on click, some of the actions might be reasonably moved out of the drop down but likely there will always be a junk drawer. 

//// 

I played around with alignment, and styling, notes below. 

Inline image 1
  1. I don't know that we even need a drop shadow, just a simple line
  2. Once scrolled we could transition the search placeholder text to be the article title:section, and show "Search Wikipedia" or something like that on hover
  3. Once scrolled I'd like to see us try to get talk & history in the fixed header maybe slide in between the logo and the search icon on scroll. 
  4. Super excited about this.




Jared Zimmerman  \\  Director of User Experience \\ Wikimedia Foundation               
M : +1 415 609 4043 |   :  @JaredZimmerman



On Mon, Nov 25, 2013 at 9:35 PM, Steven Walling <swalling@wikimedia.org> wrote:

On Mon, Nov 25, 2013 at 11:09 PM, MZMcBride <z@mzmcbride.com> wrote:

Broadly, I'm not sure the whole BetaFeatures approach makes a lot of sense
in cases like this. It seems like it would be difficult to get any
meaningful data when so many variables change simultaneously.

In this case, I think Beta Features is a good choice because I don't think we would be looking to primarily gather usage statistics, such as to support one particular aspect or to argue for a switch over to this navigation soon. With Beta Features, we'd just be looking to get qualitative feedback from people, to see how it works or doesn't for everyday use. 


--
Steven Walling,
Product Manager

_______________________________________________
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design