I’ve made some fairly significant changes to the Static Header/Nav Mod prototype. You can play with it here:
http://unicorn.wmflabs.org/navmod/
Changes below. Note that most icons are placeholders.
=== New Changes ===
* Added "watch" button to button ribbon * Shadow only appears on scrolling; disappears and turns to solid border when not moving. * Added icons to article action elements * Turned "more" action into a single pulldown * Edit buttons now have secondary pull down for additional actions (edit source, insert image, etc.) * Section edit link buttons are now standard "white" color until hover, where they turn blue. * Targeted sections now have a slight border in addition to light color fill * Removed border from Table of Contents * Left aligned TOC header * Search placeholder text is now replaced with article title on scroll * All menu items now have icons (placeholders, mostly)
=== Bugfixes ===
* Fixed issue with hoverstate on H2 sections and striping (set background color to transparent rather than white) * Fixed border radius issues with internal button ribbon
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Mon, Jan 13, 2014 at 8:46 PM, Brandon Harris bharris@wikimedia.orgwrote:
I’ve made some fairly significant changes to the Static Header/NavMod prototype. You can play with it here:
http://unicorn.wmflabs.org/navmod/ Changes below. Note that most icons are placeholders. === New Changes === * Added "watch" button to button ribbon * Shadow only appears on scrolling; disappears and turns to solidborder when not moving. * Added icons to article action elements * Turned "more" action into a single pulldown * Edit buttons now have secondary pull down for additional actions (edit source, insert image, etc.) * Section edit link buttons are now standard "white" color until hover, where they turn blue. * Targeted sections now have a slight border in addition to light color fill * Removed border from Table of Contents * Left aligned TOC header * Search placeholder text is now replaced with article title on scroll * All menu items now have icons (placeholders, mostly)
=== Bugfixes === * Fixed issue with hoverstate on H2 sections and striping (setbackground color to transparent rather than white) * Fixed border radius issues with internal button ribbon
Brandon,
This is awesome! The latest version is extremely clean.
Some ideas...
- Needs moar serif h elements, ala the typography refresh. :) - It would be useful to add some thumbnail images to see how they are included. - It would cool to have you user test this, either with some directed usability tests in person or via usertesting.com. I can help write a script if you want. - In particular, I would like to test findability of many elements and interaction with areas such as search. A *huge* advantage might be putting search in a dropdown on-page from any point in the article, as opposed to making users scroll to the top and then go to new page for results. It would be cool to see this included in the prototype, even if only one fake search could be returned. - I'm a little concerned that transforming the page title in to an element of the search box could be confusing. That looks like a search suggestion a little bit. I could be totally wrong though. - My biggest suggestion: we should definitely prioritize having on-page Edit, History, and Discussion in the fixed toolbar too, if we can. As I am scrolling through an article, these are probably more important to have in-context access to than the user-related items (with the exception of notifications). This would also have the advantage of potentially letting us remove the section edit links, and just carry one prominent edit link in the toolbar, where ever you are on a page.
On Mon, Jan 13, 2014 at 10:31 PM, Steven Walling swalling@wikimedia.org wrote:
Yeah, nice to see this update :-). Lots of good ideas here.
My biggest suggestion: we should definitely prioritize having on-page Edit, History, and Discussion in the fixed toolbar too, if we can. As I am scrolling through an article, these are probably more important to have in-context access to than the user-related items (with the exception of notifications). This would also have the advantage of potentially letting us remove the section edit links, and just carry one prominent edit link in the toolbar, where ever you are on a page.
Agree that a fixed Edit link might be nice, History/Discussion seems a bit overkill to me. If we have a fixed header, IMO we can use that exact same header area for the edit tools, and have a nice transition between the two. Brandon, I _think_ that's what you have in mind already, but I could be wrong. In a perfect VisualEditor tomorrow, we should be able to swipe in and out of edit mode without reloading. ;-)
I keep forgetting what the purpose of the gray square and the speech bubbles next to the username is -- would be nice to have some examples, or mouseover hints.
Erik
On Jan 13, 2014, at 10:48 PM, Erik Moeller erik@wikimedia.org wrote:
Agree that a fixed Edit link might be nice,
This gets weird. With a fixed, single edit link, the question becomes: am I editing the whole page, or just the section I’m with?
History/Discussion seems a bit overkill to me. If we have a fixed header, IMO we can use that exact same header area for the edit tools, and have a nice transition between the two. Brandon, I _think_ that's what you have in mind already, but I could be wrong.
You are correct, sir, but we’re talking about baby-steps here.
I keep forgetting what the purpose of the gray square and the speech bubbles next to the username is -- would be nice to have some examples, or mouseover hints.
The square is a placeholder for an avatar; the speech bubbles are echo and a talk link. I think the echo icon isn’t that great, TBH - notifications aren’t necessarily messages. And I’d like to use the single speech bubble for the talk, rather than the double (mostly because the double one is larger than all the other icons).
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Mon, Jan 13, 2014 at 11:09 PM, Brandon Harris bharris@wikimedia.org wrote:
This gets weird. With a fixed, single edit link, the question becomes:am I editing the whole page, or just the section I’m with?
Yeah, I agree - for a prototype that could be built into a Beta Feature in the near future, this could potentially be confusing.
In the longer term (2015ish) my hope is that we can achieve near-instantaneous switching between view and edit mode by delivering VE-ready HTML5 by default. With near-instantaneous switching, it may not be as important to have the context of a specific section, and more important to try to position the cursor where the user is most likely to want it when switching into edit mode.
But we can play with that idea at a future time, for sure.
Erik
Erik & Steven,
you've brought up many of the issues that I was going to, so less for me to type, thanks!
Don't focus too much on the personal barhttps://www.mediawiki.org/wiki/Compact_Personal_Bar as that will be part of a different but related Beta Feature (in-progress, being built by Juliusz) I too feel that a way of getting Talk/History/Actions into the fixed header could be a big win for the dynamic function driven header we want to eventually get to.
[image: Inline image 1] A quick mockup of one of MANY possible options for having these controls in the "reading" site header.
For the beta feature we'll isolate as much as possible the fixed header experiment (e.g. not compact header, not new section editing) but since many site actions are in the current header, they'll most likely need to come along for the ride in this beta feature.
Steven to your point, not only would I love to test this, I'd also like to instrument event logging on this for its release as a beta feature so we can compare the usage of search and other article actions compared to their current placement.
Great work, can't wait to get this up in Beta Features.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jan 13, 2014 at 11:28 PM, Erik Moeller erik@wikimedia.org wrote:
On Mon, Jan 13, 2014 at 11:09 PM, Brandon Harris bharris@wikimedia.org wrote:
This gets weird. With a fixed, single edit link, the questionbecomes:
am I editing the whole page, or just the section I’m with?
Yeah, I agree - for a prototype that could be built into a Beta Feature in the near future, this could potentially be confusing.
In the longer term (2015ish) my hope is that we can achieve near-instantaneous switching between view and edit mode by delivering VE-ready HTML5 by default. With near-instantaneous switching, it may not be as important to have the context of a specific section, and more important to try to position the cursor where the user is most likely to want it when switching into edit mode.
But we can play with that idea at a future time, for sure.
Erik
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
On Jan 14, 2014, at 12:05 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Don't focus too much on the personal bar as that will be part of a different but related Beta Feature (in-progress, being built by Juliusz)
I do not, at this point, think that the fixed header will work without the personal bar modifications. I played around with that earlier and it was just awful.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Jan 13, 2014, at 10:31 PM, Steven Walling swalling@wikimedia.org wrote:
This is awesome! The latest version is extremely clean.
Thanks! I’m mostly just implementing other people’s ideas, though.
Some ideas... • Needs moar serif h elements, ala the typography refresh. :)
To be honest, I’m waiting to see if that experiment actually takes before I include it.
• It would be useful to add some thumbnail images to see how they are included.
MOAR CATS?
• It would cool to have you user test this, either with some directed usability tests in person or via usertesting.com. I can help write a script if you want.
I’m up for this, but we should fully expand it to have secondary/dummy/working links and the like. That’s a lot of work.
• In particular, I would like to test findability of many elements and interaction with areas such as search. A huge advantage might be putting search in a dropdown on-page from any point in the article, as opposed to making users scroll to the top and then go to new page for results. It would be cool to see this included in the prototype, even if only one fake search could be returned.
There’s a whole other thing planned for search around this (and I’m working on search stuff in a different project) so it might be interesting to include the same code.
• I'm a little concerned that transforming the page title in to an element of the search box could be confusing. That looks like a search suggestion a little bit. I could be totally wrong though.
I, too, share these concerns. This is kind of what Facebook does, but not quite? My own concerns are that changing the text in the search box reduces the discoverability of search - but I figure hey, what the hell, let’s see what happens.
• My biggest suggestion: we should definitely prioritize having on-page Edit, History, and Discussion in the fixed toolbar too, if we can. As I am scrolling through an article, these are probably more important to have in-context access to than the user-related items (with the exception of notifications). This would also have the advantage of potentially letting us remove the section edit links, and just carry one prominent edit link in the toolbar, where ever you are on a page.
(Responded to this earlier in an reply to Erik.)
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On 01/14/2014 01:31 AM, Steven Walling wrote:
This is awesome! The latest version is extremely clean.
Yeah, this is cool, and I look forward to seeing it develop. I agree it will be important to see how it impacts people finding things (particularly important things like the section edit buttons that display on mouseover here).
A related issue is touch. A touch device using this interface may not have a clear way to access the section edit links. This could be mitigated by also displaying the section edit link upon focus/touch on a section.
Matt Flaschen
On Tue, 14 Jan 2014 18:52:04 +0100, Matthew Flaschen mflaschen@wikimedia.org wrote:
A related issue is touch. A touch device using this interface may not have a clear way to access the section edit links. This could be mitigated by also displaying the section edit link upon focus/touch on a section.
As I mentioned before, we just should not toggle them on hover, but show them all the time. (WMF designers seems to love hovers in a bad way, Flow's design is an example of this too :/ )
Quick comment on maintaining clarity for search - I like how the article title snaps into the search, but when I click on it, it should go back to Search. Right now it still says 'List of animals with fraudulent diplomas' which makes me think that I'm searching within the article.
On Tue, Jan 14, 2014 at 10:40 AM, Bartosz Dziewoński matma.rex@gmail.comwrote:
On Tue, 14 Jan 2014 18:52:04 +0100, Matthew Flaschen < mflaschen@wikimedia.org> wrote:
A related issue is touch. A touch device using this interface may not
have a clear way to access the section edit links. This could be mitigated by also displaying the section edit link upon focus/touch on a section.
As I mentioned before, we just should not toggle them on hover, but show them all the time. (WMF designers seems to love hovers in a bad way, Flow's design is an example of this too :/ )
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Jan 14, 2014, at 1:09 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Quick comment on maintaining clarity for search - I like how the article title snaps into the search, but when I click on it, it should go back to Search. Right now it still says 'List of animals with fraudulent diplomas' which makes me think that I'm searching within the article.
Already fixed in my version; I’ll upload it later.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
FWIW I began a patch that adds this as a BetaFeature https://gerrit.wikimedia.org/r/107523
I'm hoping to work with Brandon to get this in front of people's eyes!
On Tue, Jan 14, 2014 at 2:44 PM, Brandon Harris bharris@wikimedia.org wrote:
On Jan 14, 2014, at 1:09 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Quick comment on maintaining clarity for search - I like how the article title snaps into the search, but when I click on it, it should go back to Search. Right now it still says 'List of animals with fraudulent diplomas' which makes me think that I'm searching within the article.
Already fixed in my version; I’ll upload it later.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I actually think we should snap back to search on mouse over, rather than click, perhaps that's what you meant though.
Sent while mobile
On Jan 14, 2014, at 1:09 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Quick comment on maintaining clarity for search - I like how the article title snaps into the search, but when I click on it, it should go back to Search. Right now it still says 'List of animals with fraudulent diplomas' which makes me think that I'm searching within the article.
On Tue, Jan 14, 2014 at 10:40 AM, Bartosz Dziewoński matma.rex@gmail.com wrote: On Tue, 14 Jan 2014 18:52:04 +0100, Matthew Flaschen mflaschen@wikimedia.org wrote:
A related issue is touch. A touch device using this interface may not have a clear way to access the section edit links. This could be mitigated by also displaying the section edit link upon focus/touch on a section.
As I mentioned before, we just should not toggle them on hover, but show them all the time. (WMF designers seems to love hovers in a bad way, Flow's design is an example of this too :/ )
-- Matma Rex
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
Nah, I understood what she meant and fixed it in my version.
Search box focus on hover seems like a bad idea. Someone once submitted a patch to MediaWiki core that did that and it got deployed to Translatewiki and there was much, much wailing and gnashing of teeth.
On Jan 14, 2014, at 6:47 PM, Jared Zimmerman jzimmerman@wikimedia.org wrote:
I actually think we should snap back to search on mouse over, rather than click, perhaps that's what you meant though.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
I just mean that the text changes back to "search" on hover, that you don't have to click for the text to change.
Sent while mobile
On Jan 14, 2014, at 7:14 PM, Brandon Harris bharris@wikimedia.org wrote:
Nah, I understood what she meant and fixed it in my version.
Search box focus on hover seems like a bad idea. Someone once submitted a patch to MediaWiki core that did that and it got deployed to Translatewiki and there was much, much wailing and gnashing of teeth.
On Jan 14, 2014, at 6:47 PM, Jared Zimmerman jzimmerman@wikimedia.org wrote:
I actually think we should snap back to search on mouse over, rather than click, perhaps that's what you meant though.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 14-01-13 08:46 PM, Brandon Harris wrote:
I’ve made some fairly significant changes to the Static Header/Nav Mod prototype. You can play with it here:
http://unicorn.wmflabs.org/navmod/Changes below. Note that most icons are placeholders.
=== New Changes ===
- Added "watch" button to button ribbon
- Shadow only appears on scrolling; disappears and turns to solid border when not moving.
- Added icons to article action elements
- Turned "more" action into a single pulldown
- Edit buttons now have secondary pull down for additional actions (edit source, insert image, etc.)
- Section edit link buttons are now standard "white" color until hover, where they turn blue.
- Targeted sections now have a slight border in addition to light color fill
I really like the slow & subtle fade in/out of the section background, when hovering over the section-edit buttons. Could that fade-out be applied to the Shadow on the navigation-bar-border, too?
- Removed border from Table of Contents
- Left aligned TOC header
Ha! That looks so much better. Removing the "[Hide]" link also helps. Would that work equally well with a long & skinny ToC? eg. https://en.wikipedia.org/wiki/Template:Compact_ToC et al. https://en.wikipedia.org/wiki/Category:Wikipedia_table_of_contents_templates
If so, the copious centering is at lines 22-27 in... https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/commonC...
- Search placeholder text is now replaced with article title on scroll
- All menu items now have icons (placeholders, mostly)
=== Bugfixes ===
- Fixed issue with hoverstate on H2 sections and striping (set background color to transparent rather than white)
- Fixed border radius issues with internal button ribbon
I have no time to comment in detail right now, but let me just say that I'm surprised myself (as I usually don't expect much from such redesigns), but I actually really really like this one.
The only thing that's jarring to me is that the section "Edit" links are both on the right and hidden until hovered; I think we should have no more than one of these two (and possibly neither).
This looks great. Just a couple of comments:
- I found a bit strange that article-related actions such as watch and discussion are initially present at the toolbar and the button ribbon. I would expect them to be added to the toolbar once the ribbon is no longer visible but not initially (when the toolbar looks not article-specific). - As Steven mentioned, it would be great to think on ideas for using the more prominent search. That goes beyond the current project, but a more prominent search enables new exploration possibilities we may want to consider: It would be great to show richer suggestions, and start showing related information just when you click on the search bar (even before typing). Initial search suggestions can be contextual to the section where you are.
Pau
On Tue, Jan 14, 2014 at 11:22 AM, Bartosz Dziewoński matma.rex@gmail.comwrote:
I have no time to comment in detail right now, but let me just say that I'm surprised myself (as I usually don't expect much from such redesigns), but I actually really really like this one.
The only thing that's jarring to me is that the section "Edit" links are both on the right and hidden until hovered; I think we should have no more than one of these two (and possibly neither).
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Looks pretty cool! A couple quick notes:
The section edit + dropdown menu only appear on hover; this feels very odd on a tablet as you have to actively tap to make it appear (on iPad) or it may not work at all (on Windows 8.1). I like the idea of 'edit' being in the fixed header that's consistently visible instead...
On small screens like phones I've been seriously considering suggesting we show a fixed section header -- this sample article has relatively short sections but many are ....lllloooonnnngggg.... especially in really big articles. In a small window or on a smaller-screen tablet, those are going to easily spill larger than a screen height and it may feel odd to scroll up to find the current section-edit button.
Once you scroll past the menu items, the sidebar seems to be wasted space especially on a small window. Any plans to have it collapse if the window/screen size is smaller? Snapping a browser window to half the screen is *really easy* to do on current Windows and Linux versions, and seems like something I'd expect people doing research to do.
-- brion
On Mon, Jan 13, 2014 at 8:46 PM, Brandon Harris bharris@wikimedia.orgwrote:
I’ve made some fairly significant changes to the Static Header/NavMod prototype. You can play with it here:
http://unicorn.wmflabs.org/navmod/ Changes below. Note that most icons are placeholders. === New Changes === * Added "watch" button to button ribbon * Shadow only appears on scrolling; disappears and turns to solidborder when not moving. * Added icons to article action elements * Turned "more" action into a single pulldown * Edit buttons now have secondary pull down for additional actions (edit source, insert image, etc.) * Section edit link buttons are now standard "white" color until hover, where they turn blue. * Targeted sections now have a slight border in addition to light color fill * Removed border from Table of Contents * Left aligned TOC header * Search placeholder text is now replaced with article title on scroll * All menu items now have icons (placeholders, mostly)
=== Bugfixes === * Fixed issue with hoverstate on H2 sections and striping (setbackground color to transparent rather than white) * Fixed border radius issues with internal button ribbon
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
+1 to everybody's feedback on the article-specific actions (and user testing – yay to data!)
This is feeling a bit too top-heavy to me. When you first load the page, you're presented with three different drop-down action menus, sidebar navigation, and the article ToC – but when you scroll down, you've only got user stuff + edit on hover. Have you explored breaking these elements apart and utilizing the space lower down in the page for progressive disclosure of less important navigation elements (maybe a quick ToC-like "navigate-to-section-Foo" affordance?), or repeating important actions from the top menus (history, watch) again? Also, to echo Brion, the sidebar feels very empty and gray when you're down in the depths of the article; it would be nice if it didn't get in the way of reading *and* preserved all the useful links and tools no matter where you were on the page...
Finally, call me someone who's drunk the Koolaid ;) but the article text feels really, really wide. Upon inspection, it looks like you've made the sidebar a bit narrower, which in turns makes the article text flow even wider than it currently is on talk pages. This makes it hard to read/scan the short 2-line long subsections and causes the open personal bar & edit menus to obscure article content. I know it's not really part of what you're try demonstrate with this prototype, but enforcing tighter margins would give the righthand stuff a bit more room to breathe and shine :)
On Tue, Jan 14, 2014 at 10:25 AM, Brion Vibber bvibber@wikimedia.orgwrote:
Looks pretty cool! A couple quick notes:
The section edit + dropdown menu only appear on hover; this feels very odd on a tablet as you have to actively tap to make it appear (on iPad) or it may not work at all (on Windows 8.1). I like the idea of 'edit' being in the fixed header that's consistently visible instead...
On small screens like phones I've been seriously considering suggesting we show a fixed section header -- this sample article has relatively short sections but many are ....lllloooonnnngggg.... especially in really big articles. In a small window or on a smaller-screen tablet, those are going to easily spill larger than a screen height and it may feel odd to scroll up to find the current section-edit button.
Once you scroll past the menu items, the sidebar seems to be wasted space especially on a small window. Any plans to have it collapse if the window/screen size is smaller? Snapping a browser window to half the screen is *really easy* to do on current Windows and Linux versions, and seems like something I'd expect people doing research to do.
-- brion
On Mon, Jan 13, 2014 at 8:46 PM, Brandon Harris bharris@wikimedia.orgwrote:
I’ve made some fairly significant changes to the StaticHeader/Nav Mod prototype. You can play with it here:
http://unicorn.wmflabs.org/navmod/ Changes below. Note that most icons are placeholders. === New Changes === * Added "watch" button to button ribbon * Shadow only appears on scrolling; disappears and turns to solidborder when not moving. * Added icons to article action elements * Turned "more" action into a single pulldown * Edit buttons now have secondary pull down for additional actions (edit source, insert image, etc.) * Section edit link buttons are now standard "white" color until hover, where they turn blue. * Targeted sections now have a slight border in addition to light color fill * Removed border from Table of Contents * Left aligned TOC header * Search placeholder text is now replaced with article title on scroll * All menu items now have icons (placeholders, mostly)
=== Bugfixes === * Fixed issue with hoverstate on H2 sections and striping (setbackground color to transparent rather than white) * Fixed border radius issues with internal button ribbon
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
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
