I think I like where you're going here, though my initial response was strongly negative. Here are my thoughts in the order they came to me:

* The search bar, when at the top of the page doesn't look like a text box; so I was confused. However, once the page scrolled down it was much clearer; possibly because it was separated from the rest of the page elements. Could that separation happen at the top of the page initially somehow?

* I don't think it's wholly appropriate to have the size of the search box be the same size or bigger than the page title.

* On the same line of thought; fundraising gets in trouble when we take up 'useless' space at the top of the page; could the top bar be made smaller?

* What happens with non content pages? In the interest of design unity, I'm unsure how you would apply the same design principle to say, Special:Preferences or Special pages which define their own tab groups like meta:CentralNotice.

* I really don't like the blue flashing edit button. Could that somehow be integrated into the floating header?

** Similarly, I don't think we should promote editing whilst hiding discussion. (In that the edit button follows you; but to discuss you have to move back up to the top of the page.)

* I feel that exploration, rather than search, is the primary method of navigation on the site, given that some large number of users come to the site via google. I may be atypical though in that I almost never use our search. That being said; my thought is that exploration tools like 'what links here', or the 'See also' section should be somehow inline to the search bar.

* I was pondering the idea of how one would use a floating footer to expose the 'Edit', 'Discuss', etc tools.

** Whilst I was doing that I realized I wasn't such a fan of the 'floating' effect of the search bar. Once again it seemed to be more about the search than the content -- I wondered what a 'sunken' search bar would do. If it would appear that the content was in front of search.

~Matt Walker

Wikimedia Foundation

Fundraising Technology Team

On Tue, Nov 26, 2013 at 7:47 PM, Jared Zimmerman <jared.zimmerman@wikimedia.org> wrote:

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.

I don't know that we even need a drop shadow, just a simple line
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

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.
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
https://wikimediafoundation.org/

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

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