Erik, I don't think anyone is proposing *watchlist* be only in a drop down, *contribution*, is on the fence, and will require some analysis. currently you can see the proposal of what's where on https://www.mediawiki.org/wiki/Compact_Personal_Bar so feedback on that would be appreciated.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Nov 26, 2013 at 8:28 PM, Matthew Walker mwalker@wikimedia.orgwrote:
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.
[image: Inline image 1]
- 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 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
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
