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.
[image: 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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Nov 25, 2013 at 9:35 PM, Steven Walling swalling@wikimedia.orgwrote:
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 https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
