We should quickly refine the visual design and get this into labs! This is so cool Brandon! Get it in tomorrow!!! On Mon, Nov 25, 2013 at 3:48 PM, Kaity Hammerstein < khammerstein(a)wikimedia.org&gt; wrote:

I also think we need to think about the rest state. The drop shadow works on scroll, but its heavy if you pause. Brandon, is someone helping you visual design wise? On Mon, Nov 25, 2013 at 3:51 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org&gt; wrote:

Maybe the article actions menu could include icons, and then remove the word "more" and just have a dropdown arrow, like this: [image: Inline image 1] On Mon, Nov 25, 2013 at 4:04 PM, Vibha Bamba &lt;vbamba(a)wikimedia.org&gt; 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] 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<https://twitter.com/JaredZimmerman> On Mon, Nov 25, 2013 at 9:35 PM, Steven Walling &lt;swalling(a)wikimedia.org&gt;wrote;wrote:

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 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> On Tue, Nov 26, 2013 at 8:28 PM, Matthew Walker &lt;mwalker(a)wikimedia.org&gt;wrote;wrote:

Matt responses in-line *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> On Tue, Nov 26, 2013 at 8:28 PM, Matthew Walker &lt;mwalker(a)wikimedia.org&gt;wrote;wrote: ​Jared — Yep, Brandon and I talked about this, it *could* have the same issue as facebook, which Brandon and I talked about, where there are states where the search box doesn't look like a search field. We'll certainly do lots of testing. But i feel confident that there are things we can do, such as placeholder text, animation and other secondary cues to make sure user understand it is a search interface.[image: Inline image 1] Jared — ​ok ​, this is just the first step, however I think once you see how we plan to reuse the fixed header as a primary element for accessing contextual actions on the site i think the rather limited amount of space it takes up (less than the current site header) will make a lot of sense. Jared — ​I don't think that would be a good idea, like I mentioned before it is already smaller than the existing site header, and will have some rich controls that we want to make sure have big enough hit targets. * What happens with non content pages? In the interest of design unity, I'm Jared — ​In general I ​don't think it would be significantly different on special pages, the contextual actions might be different and we'd have to look at them on a case by case basis. Jared — ​We'll look into that, see my previous note​ Jared — ​We'll look into that, see my previous note​ Jared — ​In general I feel like the content of a page handles discovery quite well. ​ ​However we're investigating other browse and discovery features such as a "smarter random" and geographic discovery<https://www.mediawiki.org/wiki/Beta_Features/Nearby_Pages> as well. One of the next projects the platform team is undertaking is redesign for search. Which will provide better targeted results that better integrate other projects, having a wide search bar opens the door for really interesting possibilities in rich media search results that feel more like a browse experience. Jared — there are lots of UX issues (I'm sure solvable) with fixed footer elements ​​not the least are just that users tend to have a kind of "bottom of the page blindness<http://www.nngroup.com/articles/f-shaped-pattern-reading-web-c… that might be hard to battle. ​Jared — I think killing the shadow will help this, as I don't personally think its needed. Truth is once you scroll down a wikipedia page we have no branding whatsoever, and I don't mean Make the logo bigger<http://www.makemylogobiggercream.com/> I mean comfort and ​constancy for users knowing where they are<https://en.wikipedia.org/wiki/Heuristic_evaluation#Nielsen.27s_heuri… . Thanks for these thoughtful points Matt, we'll have to sync up with fundraising to make sure that fundraising banner play well with the new system in a logical, expected, and still very visible way.

On Tue, Nov 26, 2013 at 3:54 AM, Nick White &lt;nick.white(a)durham.ac.uk&gt; wrote: I think when framed as "reader vs. editor" that's certainly a reasonable argument, but I think it's more about progressive disclosure of editing tools and links rather than treating readers as consumers. We do ourselves no favors by cluttering the initial user experience with every possible link we think could be helpful, without prioritization and gradual discovery. One hypothesis (which I think is shared by a few people on this list, myself included) is that a default experience which includes powerful calls-to-action (to edit, upload, discuss, ..) while otherwise focusing on the most important tools and progressive discoverability will be more effective in motivating readers to become contributors than our current user experience. The tricky part is still enabling the user, as she or he discovers the tasks they enjoy doing, to efficiently access the tools relevant to those tasks. When developing for the web, we often dismiss desktop UI patterns, but IMO there's a lot to be learned from decades of desktop UI development about how to manage complex functionality, and how not to do it. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

Erik Moeller, 27/11/2013 03:50: Collapsing is not progressive disclosure. Stop. The. Collapsing. Now. Nemo