Hello!
I’ve been making a thing. It’s actually got a code-name now! No more saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably:
* Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’s not just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/
And read more about it here: https://www.mediawiki.org/wiki/Winter
Here’s your changelog:
== Changes, January 20 == * New code name: Winter * System now prompts for a user name upon load and will optionally save the value. ** This sets up the personal bar to be, well, personal. ** This action ''DOES NOT'' log the user into Wikipedia. ** Saved data can be cleared from the sidebar.
* Searchbox now drops text on focus and replaces it on blur * Searchbox now has a hover state with invitation text. * Searchbox icon now turns blue on focus * Logo now snaps to white background when in locked position. * Sidebar is now white by default, with a grey border that fades out when all items in the sidebar are out of view. * The Table of Contents now appears in the header of the page from the beginning ** (Previous versions of Winter had the ToC only appear there after the in-page Table of Contents rolled off-screen) * Article actions now dock in the header when they scroll out of view (iconfied). * Added tipsy behaviors. * Fixed issue with search box positioning. * Added pencil icons to section edit buttons * Section edit buttons now are visible at all times but do not have borders. ** On hover, they turn blue. * Changed section edit hover transition from 'linear' to 'ease' * Added footer section * Added "categories" box in example article * Added "Typography" toggle in sidebar. Activating it turns on: ** An approximation of restricted measure * References have returned * Built a JSON parser into the demo so that different pages can be loaded via the API. * Language links are now slotted into the sidebar. * System correctly recognizes when it's looking at ''User'' content (User: and User_talk:) and adds icons and functionality as required * Handles contributions (sort of - buggy)
=== Known Issues === * Contributions views: ** Timestamps don't sort right ** Comment fields are not correctly parsed from wikitext to html ** Size changes are not correctly reflected * Redlinks do not work * System does not handle 404 loads correctly (fails silently, requires reload) * Internal hash URLs don't scroll correctly * Some buttons don't go away when they should * Loading from JSON breaks the nice little "section hover" stuff.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now! Nomore saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’s notjust the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here: https://www.mediawiki.org/wiki/Winter
\o/
The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature.
Some very small things:
- I realize the icons are mostly placeholders, but the user contribs one is seriously confusing. It looks like there are two edit buttons when you scroll down. - I think the main edit button at the top should not be the quiet state from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders). - The line underneath the page title h1 is a different thickness (and color?) than the other borders. It's mildly annoying.
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
Winter is coming, (I couldn't resist the Game of Thrones reference.)
Added my comments on mediawiki.
@Steven:
No matter how much anyone doesn't like the globe including myself, it's a huge part of Wikipedia's brand like you mentioned and shouldn't be wiped out just for the sake of our personal preference. We should improve and not trash it. Even if we trashed it and replaced with something else, we still need SOMETHING people can relate to in regards to the project. Why do this when people already relate the globe as Wikipedia. Wabi sabi wasabi man.
mm
On Mon, Jan 20, 2014 at 4:02 PM, Steven Walling swalling@wikimedia.orgwrote:
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now! Nomore saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’snot just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here:\o/
The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature.
Some very small things:
- I realize the icons are mostly placeholders, but the user contribs one
is seriously confusing. It looks like there are two edit buttons when you scroll down.
- I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
- The line underneath the page title h1 is a different thickness (and
color?) than the other borders. It's mildly annoying.
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
Winter is coming, (I couldn't resist the Game of Thrones reference.)
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Looking good, some feedback…
- I think we should explore putting Watch and TOC together, or at least associating them more closely. - tipsy being to the left of, covers the other icons, I'm not sure if we even need it, perhaps we could just rely on regular browser tooltips. - I think that moving the TOC icon over should be animated, currently the snap makes me look up, and is a bit distracting, the opposite of what we want. - I think we can kill the in-line TOC - You can't currently scroll the TOC flyout - Idea : highlight the current section in the TOC flyout - when language list is not collapsable the left sidebar take a long time to go away - Placeholder text and user input is not aligned with each other in search box
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jan 20, 2014 at 4:11 PM, May Tee-Galloway mgalloway@wikimedia.orgwrote:
Added my comments on mediawiki.
@Steven:
No matter how much anyone doesn't like the globe including myself, it's a huge part of Wikipedia's brand like you mentioned and shouldn't be wiped out just for the sake of our personal preference. We should improve and not trash it. Even if we trashed it and replaced with something else, we still need SOMETHING people can relate to in regards to the project. Why do this when people already relate the globe as Wikipedia. Wabi sabi wasabi man.
mm
On Mon, Jan 20, 2014 at 4:02 PM, Steven Walling swalling@wikimedia.orgwrote:
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now!No more saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’snot just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here:\o/
The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature.
Some very small things:
- I realize the icons are mostly placeholders, but the user contribs one
is seriously confusing. It looks like there are two edit buttons when you scroll down.
- I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
- The line underneath the page title h1 is a different thickness (and
color?) than the other borders. It's mildly annoying.
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
Winter is coming, (I couldn't resist the Game of Thrones reference.)
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Tue, Jan 21, 2014 at 11:58 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Looking good, some feedback…
- I think we should explore putting Watch and TOC together, or at
least associating them more closely.
- tipsy being to the left of, covers the other icons, I'm not sure if
we even need it, perhaps we could just rely on regular browser tooltips.
- I think that moving the TOC icon over should be animated, currently
the snap makes me look up, and is a bit distracting, the opposite of what we want.
- I think we can kill the in-line TOC
That would be problematic. It would:
- Make it impossible to get a sense of the article structure, at a glance. (eg. Enwiki's WP:Features article criteria 2bhttps://en.wikipedia.org/wiki/Wikipedia:FA%3Fand any good FA example.) - Change the process for getting to a subheading, from 1-move-and-click to 2-moves-and-2-clicks
- You can't currently scroll the TOC flyout
- Idea : highlight the current section in the TOC flyout
- when language list is not collapsable the left sidebar take a long
time to go away
Pau's proposal should solve that. https://www.mediawiki.org/wiki/Beta_Features/New_Features#Better_Interlangua...
- Placeholder text and user input is not aligned with each other in
search box
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jan 20, 2014 at 4:11 PM, May Tee-Galloway <mgalloway@wikimedia.org
wrote:
Added my comments on mediawiki.
@Steven:
No matter how much anyone doesn't like the globe including myself, it's a huge part of Wikipedia's brand like you mentioned and shouldn't be wiped out just for the sake of our personal preference. We should improve and not trash it. Even if we trashed it and replaced with something else, we still need SOMETHING people can relate to in regards to the project. Why do this when people already relate the globe as Wikipedia. Wabi sabi wasabi man.
mm
On Mon, Jan 20, 2014 at 4:02 PM, Steven Walling swalling@wikimedia.orgwrote:
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now!No more saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set thingsup * All pages are loaded from the API via JSON. So it’s not just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here:\o/
The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature.
Some very small things:
- I realize the icons are mostly placeholders, but the user contribs one
is seriously confusing. It looks like there are two edit buttons when you scroll down.
- I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
- The line underneath the page title h1 is a different thickness (and
color?) than the other borders. It's mildly annoying.
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
Winter is coming, (I couldn't resist the Game of Thrones reference.)
-- 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
Nick, not sure I follow…
Moving the TOC doesn't affect its structure…
Change the process for getting to a subheading, from 1-move-and-click to 2-moves-and-2-clicks I assume by 1-move you mean, scroll past the lead paragraph, then click on a section of the toc?
in the prototype, you click (or we could make it hover) which would mean no moves, 1 click, so faster than the current state of things, also we get the bonus of it being available anywhere, not just at the top of an article.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Jan 21, 2014 at 3:45 PM, quiddity pandiculation@gmail.com wrote:
On Tue, Jan 21, 2014 at 11:58 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Looking good, some feedback…
- I think we should explore putting Watch and TOC together, or at
least associating them more closely.
- tipsy being to the left of, covers the other icons, I'm not sure if
we even need it, perhaps we could just rely on regular browser tooltips.
- I think that moving the TOC icon over should be animated, currently
the snap makes me look up, and is a bit distracting, the opposite of what we want.
- I think we can kill the in-line TOC
That would be problematic. It would:
- Make it impossible to get a sense of the article structure, at a
glance. (eg. Enwiki's WP:Features article criteria 2bhttps://en.wikipedia.org/wiki/Wikipedia:FA%3Fand any good FA example.)
- Change the process for getting to a subheading, from
1-move-and-click to 2-moves-and-2-clicks
- You can't currently scroll the TOC flyout
- Idea : highlight the current section in the TOC flyout
- when language list is not collapsable the left sidebar take a long
time to go away
Pau's proposal should solve that. https://www.mediawiki.org/wiki/Beta_Features/New_Features#Better_Interlangua...
- Placeholder text and user input is not aligned with each other in
search box
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Mon, Jan 20, 2014 at 4:11 PM, May Tee-Galloway < mgalloway@wikimedia.org> wrote:
Added my comments on mediawiki.
@Steven:
No matter how much anyone doesn't like the globe including myself, it's a huge part of Wikipedia's brand like you mentioned and shouldn't be wiped out just for the sake of our personal preference. We should improve and not trash it. Even if we trashed it and replaced with something else, we still need SOMETHING people can relate to in regards to the project. Why do this when people already relate the globe as Wikipedia. Wabi sabi wasabi man.
mm
On Mon, Jan 20, 2014 at 4:02 PM, Steven Walling swalling@wikimedia.orgwrote:
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now!No more saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set thingsup * All pages are loaded from the API via JSON. So it’s not just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here:\o/
The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature.
Some very small things:
- I realize the icons are mostly placeholders, but the user contribs
one is seriously confusing. It looks like there are two edit buttons when you scroll down.
- I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
- The line underneath the page title h1 is a different thickness (and
color?) than the other borders. It's mildly annoying.
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
Winter is coming, (I couldn't resist the Game of Thrones reference.)
-- 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
Possibly I misunderstood? You wrote, "I think we can kill the in-line TOC" which I interpreted to mean: you suggest removing the ToC that currently appears in all articles (with more than 3 sections), in favour of *just* a drop-down menu ToC.
This would be a problem because articles are intended to have clear and insightful ToCs, that appear near the top, and provide mental structure (for the reader) for what follows, as well as instant navigation to lower sections. Eg. https://en.wikipedia.org/wiki/No._2_Operational_Conversion_Unit_RAAF or https://en.wikipedia.org/wiki/Phoenix_%28constellation%29 (two recent FAs) Eg2. I'll often go to a musician's article, read the intro/infobox, and then click the "Discography" link in the ToC.
Additionally, people tend to not find hidden things. If the ToCs are only available in hidden form (an icon), most readers will never *ever* see them.
I like the current Winter setup, which has the ToC-icon in the fixed-header, and the ToC-icon within the in-line ToC.
I'm curious about the potential for placing the ToC into the lefthand sidebar, once the user scrolls down. (Like a PDF ToC)
Quiddity.
On 14-01-21 04:03 PM, Jared Zimmerman wrote:
not sure I follow…
Moving the TOC doesn't affect its structure…
Change the process for getting to a subheading, from 1-move-and-click to 2-moves-and-2-clicks I assume by 1-move you mean, scroll past the lead paragraph, then click on a section of the toc?
in the prototype, you click (or we could make it hover) which would mean no moves, 1 click, so faster than the current state of things, also we get the bonus of it being available anywhere, not just at the top of an article.
*Jared Zimmerman *\Director of User Experience \Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman https://twitter.com/JaredZimmerman
On Tue, Jan 21, 2014 at 3:45 PM, quiddity <pandiculation@gmail.com mailto:pandiculation@gmail.com> wrote:
On Tue, Jan 21, 2014 at 11:58 AM, Jared Zimmerman <jared.zimmerman@wikimedia.org <mailto:jared.zimmerman@wikimedia.org>> wrote: Looking good, some feedback… * I think we should explore putting Watch and TOC together, or at least associating them more closely. * tipsy being to the left of, covers the other icons, I'm not sure if we even need it, perhaps we could just rely on regular browser tooltips. * I think that moving the TOC icon over should be animated, currently the snap makes me look up, and is a bit distracting, the opposite of what we want. * I think we can kill the in-line TOC That would be problematic. It would: * Make it impossible to get a sense of the article structure, at a glance. (eg. Enwiki's WP:Features article criteria 2b <https://en.wikipedia.org/wiki/Wikipedia:FA%3F> and any good FA example.) * Change the process for getting to a subheading, from 1-move-and-click to 2-moves-and-2-clicks * You can't currently scroll the TOC flyout * Idea : highlight the current section in the TOC flyout * when language list is not collapsable the left sidebar take a long time to go away Pau's proposal should solve that. https://www.mediawiki.org/wiki/Beta_Features/New_Features#Better_Interlanguage_Links * Placeholder text and user input is not aligned with each other in search box * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Mon, Jan 20, 2014 at 4:11 PM, May Tee-Galloway <mgalloway@wikimedia.org <mailto:mgalloway@wikimedia.org>> wrote: Added my comments on mediawiki. @Steven: No matter how much anyone doesn't like the globe including myself, it's a huge part of Wikipedia's brand like you mentioned and shouldn't be wiped out just for the sake of our personal preference. We should improve and not trash it. Even if we trashed it and replaced with something else, we still need SOMETHING people can relate to in regards to the project. Why do this when people already relate the globe as Wikipedia. Wabi sabi wasabi man. mm On Mon, Jan 20, 2014 at 4:02 PM, Steven Walling <swalling@wikimedia.org <mailto:swalling@wikimedia.org>> wrote: On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris <bharris@wikimedia.org <mailto:bharris@wikimedia.org>> wrote: Hello! I’ve been making a thing. It’s actually got a code-name now! No more saying “Vector static header and navigation modification”. LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’s not just the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not. You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here: https://www.mediawiki.org/wiki/Winter \o/ The search prototype is great, and so are the improvements to the toolbar, particularly the relation between the TOC and the way the page actions slide out on scrolldown. I can't wait to see this as a beta feature. Some very small things: - I realize the icons are mostly placeholders, but the user contribs one is seriously confusing. It looks like there are two edit buttons when you scroll down. - I think the main edit button at the top should not be the quiet state from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders). - The line underneath the page title h1 is a different thickness (and color?) than the other borders. It's mildly annoying. And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think. Winter is coming, (I couldn't resist the Game of Thrones reference.) -- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto: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
On Jan 21, 2014, at 5:17 PM, Quiddity pandiculation@gmail.com wrote:
I'm curious about the potential for placing the ToC into the lefthand sidebar, once the user scrolls down. (Like a PDF ToC)
I don’t think this is really worth experimenting with. The length of the sidebar is variable and, in fact, can be longer than the article. Slotting it after the toolbox ends doesn’t make a lot of sense then because it will never be in a static location. Moving stuff around on the user isn’t that great of an experience.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
(Pulled this out into its own thread)
On Jan 20, 2014, at 4:02 PM, Steven Walling swalling@wikimedia.org wrote:
And one bigger thing... The lack of the puzzle globe when scrolling. I know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
So, a couple of things:
1) The puzzle globe - and ALL of our brand identity - *currently* goes away when you scroll past it on the page. Retaining *any* branding is therefore good, in my opinion. We’re actually ahead of the game here.
2) We know that users recognize Wikipedia branding in the following order (Jay has the information about this):
* The Wordmark (WikipediA) * The “W” mark * Single puzzle piece * The puzzle globe.
The globe is the *least* recognized of our marks, which is interesting. So by just showing the wordmark, we’re actually in-line with what is expected.
3) Regardless of my personal opinions about the globe as a logo (I love its symbology, for instance), it’s *incredibly* difficult to work with because:
* It doesn’t reduce well *at all* * Good logos do not have gradients (part of that reduction bit) * It’s a 2 dimensional render of a 3-D model. This rendering was done on a *white* background, which means that the interior shadows are all reflecting white. Which means putting it on any other color background doesn’t work: the shadows don’t look correct to the eye (particularly the shading inside the globe), which puts it into this sort of ‘uncanny valley’ of visual effects. The viewer *knows* it doesn’t look correct, but isn’t sure why.
Clearly, the Winter prototype has some work to do for non-standard logos (e.g., some wiktionaries, for instance). What we’ll likely want to do in those cases is an image swap when the thing is supposed to come to rest.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
In general the biggest part of this to me is that…
- we don't currently have any branding after initial scroll. - logo ≠ brand - we don't exactly know what our "brand" is at this point, but we're working on it.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 12:20 PM, Brandon Harris bharris@wikimedia.orgwrote:
(Pulled this out into its own thread)On Jan 20, 2014, at 4:02 PM, Steven Walling swalling@wikimedia.org wrote:
And one bigger thing... The lack of the puzzle globe when scrolling. I
know you hate the puzzle globe and so do many of our designers. But it's a key part of our identity, and it's also a really nice large target for "home" on desktop. Thinking of this as a potential future default look, splitting the logo and wordmark on every page like that is a serious change. We should have a larger conversation about it I think internally. Either we do think the globe is an important part of our brand or we don't. If we think it's so unimportant as to remove it on scroll, then that has pretty wide implications for our branding I think.
So, a couple of things: 1) The puzzle globe - and ALL of our brand identity -*currently* goes away when you scroll past it on the page. Retaining *any* branding is therefore good, in my opinion. We’re actually ahead of the game here.
2) We know that users recognize Wikipedia branding in thefollowing order (Jay has the information about this):
* The Wordmark (WikipediA) * The “W” mark * Single puzzle piece * The puzzle globe. The globe is the *least* recognized of our marks, which isinteresting. So by just showing the wordmark, we’re actually in-line with what is expected.
3) Regardless of my personal opinions about the globe as alogo (I love its symbology, for instance), it’s *incredibly* difficult to work with because:
* It doesn’t reduce well *at all* * Good logos do not have gradients (partof that reduction bit) * It’s a 2 dimensional render of a 3-D model. This rendering was done on a *white* background, which means that the interior shadows are all reflecting white. Which means putting it on any other color background doesn’t work: the shadows don’t look correct to the eye (particularly the shading inside the globe), which puts it into this sort of ‘uncanny valley’ of visual effects. The viewer *knows* it doesn’t look correct, but isn’t sure why.
Clearly, the Winter prototype has some work to do fornon-standard logos (e.g., some wiktionaries, for instance). What we’ll likely want to do in those cases is an image swap when the thing is supposed to come to rest.
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
Replies to a couple folks, in-line.
On Jan 20, 2014, at 4:02 PM, Steven Walling swalling@wikimedia.org wrote:
I think the main edit button at the top should not be the quiet state from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
So, I tried it with the main edit being blue and it was *crazy* loud. The most-important thing in the page loud. So I made it quiet and it looked better.
Now, this speaks to the larger problem we’re trying to solve: user awareness of the edit button.
We know that Vector’s tab layout has trained people to pretty much ignore the tabs, so they don’t see the edit tab (tab blindness, call it). By pulling the tabs into the main content area, we are working to solve that - to bind the actions directly to the content they affect.
Currently the tab blindness causes people to not know they can edit, so we have fewer editors.
I think think that making the edit link loud will definitely *increase* overall edits (in fact, I’ll stake my job on it), but I think it will result in a radical increase of *bad* edits as well. Too many “kick the tires” vandalisms, maybe.
It’s definitely something we can test, though.
On Jan 21, 2014, at 11:58 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
• I think we should explore putting Watch and TOC together, or at least associating them more closely.
In this case, I’d pull the Watch icon from the sub-bar and just leave it in the header always.
However, I’m not sure this is the best plan (discussed below).
• tipsy being to the left of, covers the other icons, I'm not sure if we even need it, perhaps we could just rely on regular browser tooltips.
Yeah, I put them to the left because they were obscuring the TOC when done below. I think we can deal with this discoverability fairly easily.
• I think that moving the TOC icon over should be animated, currently the snap makes me look up, and is a bit distracting, the opposite of what we want.
More difficult than you think. You’re asking for an ease-in on a thing that already has a defined width. I’ll see what can happen, though.
• I think we can kill the in-line TOC
Disagree. I think people expect it, per-Quiddity.
• You can't currently scroll the TOC flyout
Fixed.
• Idea : highlight the current section in the TOC flyout
Problematic. What is the “current section”? What if there are, like, 5 visible sections? Is the highlighted section the h3, the h4, or the h2?
• when language list is not collapsable the left sidebar take a long time to go away
Languages are open by default so we should design with that in mind. I’ve added toggles for the sections, though.
• Placeholder text and user input is not aligned with each other in search box
I’m not seeing that. The input sits in the exact space for me.
RE: Page actions moving into the header: (This is me collecting my comments from a meeting to this list)
As I mentioned in yesterday’s design review, my gut instinct is that moving article actions into the header is the wrong path:
* I don’t think they’re needed up there. People already scroll to the top when they need these functions. * I think it conflates those actions with the “personal bar” actions and creates confusion. A primary motivation for Winter is to segregate the following types of actions: Site actions (sidebar chrome), Content actions (page stuff), and Personal actions (user stuff). The search box is a site affordance. The personal actions are obviously thus. Mixing article actions next to the personal actions seems weird to me. * The point of discussion being always available is a valid one - the use case being, “I’m in this section, and I see an error, and I want to talk about it”. However, I don’t necessarily think that dumping the user into the “master” talk page at any point is going to solve that. A long time ago I had the idea to add a “discuss” link next to the section edit links. This would target the specific section and create a new discussion with that title (or find an existing one) and work within that. This is obviously something that can easily be done with Flow (though my original thoughts were with LQT). I’m not sure it works well with Talk. This is something I’ll want to experiment with.
Whuff.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
For section highlighting, I would say it is the section that is visible and topmost on the screen. When a section header hits the fixed header it becomes the current section as far as the TOC is concerned.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.orgwrote:
Replies to a couple folks, in-line.On Jan 20, 2014, at 4:02 PM, Steven Walling swalling@wikimedia.org wrote:
I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
So, I tried it with the main edit being blue and it was *crazy*loud. The most-important thing in the page loud. So I made it quiet and it looked better.
Now, this speaks to the larger problem we’re trying to solve:user awareness of the edit button.
We know that Vector’s tab layout has trained people to pretty muchignore the tabs, so they don’t see the edit tab (tab blindness, call it). By pulling the tabs into the main content area, we are working to solve that - to bind the actions directly to the content they affect.
Currently the tab blindness causes people to not know they canedit, so we have fewer editors.
I think think that making the edit link loud will definitely*increase* overall edits (in fact, I’ll stake my job on it), but I think it will result in a radical increase of *bad* edits as well. Too many “kick the tires” vandalisms, maybe.
It’s definitely something we can test, though.On Jan 21, 2014, at 11:58 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
• I think we should explore putting Watch and TOC together, or atleast associating them more closely.
In this case, I’d pull the Watch icon from the sub-bar and justleave it in the header always.
However, I’m not sure this is the best plan (discussed below).• tipsy being to the left of, covers the other icons, I'm not sureif we even need it, perhaps we could just rely on regular browser tooltips.
Yeah, I put them to the left because they were obscuring the TOCwhen done below. I think we can deal with this discoverability fairly easily.
• I think that moving the TOC icon over should be animated,currently the snap makes me look up, and is a bit distracting, the opposite of what we want.
More difficult than you think. You’re asking for an ease-in on athing that already has a defined width. I’ll see what can happen, though.
• I think we can kill the in-line TOCDisagree. I think people expect it, per-Quiddity.• You can't currently scroll the TOC flyoutFixed.• Idea : highlight the current section in the TOC flyoutProblematic. What is the “current section”? What if there are,like, 5 visible sections? Is the highlighted section the h3, the h4, or the h2?
• when language list is not collapsable the left sidebar take along time to go away
Languages are open by default so we should design with that inmind. I’ve added toggles for the sections, though.
• Placeholder text and user input is not aligned with each otherin search box
I’m not seeing that. The input sits in the exact space for me. RE: Page actions moving into the header: (This is me collecting mycomments from a meeting to this list)
As I mentioned in yesterday’s design review, my gut instinct isthat moving article actions into the header is the wrong path:
* I don’t think they’re needed up there. Peoplealready scroll to the top when they need these functions. * I think it conflates those actions with the “personal bar” actions and creates confusion. A primary motivation for Winter is to segregate the following types of actions: Site actions (sidebar chrome), Content actions (page stuff), and Personal actions (user stuff). The search box is a site affordance. The personal actions are obviously thus. Mixing article actions next to the personal actions seems weird to me. * The point of discussion being always available is a valid one - the use case being, “I’m in this section, and I see an error, and I want to talk about it”. However, I don’t necessarily think that dumping the user into the “master” talk page at any point is going to solve that. A long time ago I had the idea to add a “discuss” link next to the section edit links. This would target the specific section and create a new discussion with that title (or find an existing one) and work within that. This is obviously something that can easily be done with Flow (though my original thoughts were with LQT). I’m not sure it works well with Talk. This is something I’ll want to experiment with.
Whuff.
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 Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.orgwrote:
I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
So, I tried it with the main edit being blue and it was *crazy*loud. The most-important thing in the page loud. So I made it quiet and it looked better.
It is not that loud, as you can see at http://i.imgur.com/X4uhU2T.png and it _is_ the most important call to action on the page.
Now, this speaks to the larger problem we’re trying to solve:user awareness of the edit button.
We know that Vector’s tab layout has trained people to pretty muchignore the tabs, so they don’t see the edit tab (tab blindness, call it). By pulling the tabs into the main content area, we are working to solve that - to bind the actions directly to the content they affect.
Currently the tab blindness causes people to not know they canedit, so we have fewer editors.
I think think that making the edit link loud will definitely*increase* overall edits (in fact, I’ll stake my job on it), but I think it will result in a radical increase of *bad* edits as well. Too many “kick the tires” vandalisms, maybe.
It’s definitely something we can test, though.
In the last GettingStarted A/B test, we delivered an "Edit this page" CTA that was twice as large and delivered in a modal,[1] and it did not result in a radical increase in bad edits. There's no need to A/B test this or be scared about bad edits.
1. https://commons.wikimedia.org/wiki/File:Screenshot_2013-11-01_of_gettingStar...
I would question that page level editing is actually "most important call to action on the page"
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 1:23 PM, Steven Walling swalling@wikimedia.orgwrote:
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.orgwrote:
I think the main edit button at the top should not be the quiet state
from mw-ui. There is very little use of color on the skin now, so it's not like we're overwhelming things. We need to stop being afraid to make a few things LOUDER, particularly since in this prototype we're removing some color (like the Vector borders).
So, I tried it with the main edit being blue and it was *crazy*loud. The most-important thing in the page loud. So I made it quiet and it looked better.
It is not that loud, as you can see at http://i.imgur.com/X4uhU2T.png and it _is_ the most important call to action on the page.
Now, this speaks to the larger problem we’re trying to solve:user awareness of the edit button.
We know that Vector’s tab layout has trained people to prettymuch ignore the tabs, so they don’t see the edit tab (tab blindness, call it). By pulling the tabs into the main content area, we are working to solve that - to bind the actions directly to the content they affect.
Currently the tab blindness causes people to not know they canedit, so we have fewer editors.
I think think that making the edit link loud will definitely*increase* overall edits (in fact, I’ll stake my job on it), but I think it will result in a radical increase of *bad* edits as well. Too many “kick the tires” vandalisms, maybe.
It’s definitely something we can test, though.In the last GettingStarted A/B test, we delivered an "Edit this page" CTA that was twice as large and delivered in a modal,[1] and it did not result in a radical increase in bad edits. There's no need to A/B test this or be scared about bad edits.
https://commons.wikimedia.org/wiki/File:Screenshot_2013-11-01_of_gettingStar...
-- Steven Walling, Product Manager https://wikimediafoundation.org/
On Wed, Jan 22, 2014 at 1:34 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I would question that page level editing is actually "most important call to action on the page"
What would you put above it?
Reading? Clicking links? Viewing images? Those are not "calls to action". They are functions people are motivated to do naturally, and which will not be detracted from if you make Edit more prominent.
In VisualEditor there effectively is no section edit, we're retaining it for consistency with wikitext and to provide extra CTAs. Other CTAs are viewing history, viewing the discussion page, or using editor-related items like notifications or watchlist. These are less important or ancillary to editing.
Our single biggest challenge right now is getting people to edit Wikipedia. We haven't made significant progress on turning that trend around, so if we're going to do a redesign of the skin as significant as this we need to emphasize this. As Brandon right points out, just turning the current Vector edit button in to a mw-ui-constructive style button would not solve the deeper problems in Vector, and would no doubt be odd-looking. I'm really glad this prototype starts to tackle those issues. But if you *seriously* think that Editing articles is not our most important call to action then we need to have a sit down and talk about this in person.
I would argue that we should prioritize section editing over full page editing, and eventually VE will have section editing, even prior to that it at least has awareness of what section you triggered the edit action from.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 1:47 PM, Steven Walling swalling@wikimedia.orgwrote:
On Wed, Jan 22, 2014 at 1:34 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I would question that page level editing is actually "most important call to action on the page"
What would you put above it?
Reading? Clicking links? Viewing images? Those are not "calls to action". They are functions people are motivated to do naturally, and which will not be detracted from if you make Edit more prominent.
In VisualEditor there effectively is no section edit, we're retaining it for consistency with wikitext and to provide extra CTAs. Other CTAs are viewing history, viewing the discussion page, or using editor-related items like notifications or watchlist. These are less important or ancillary to editing.
Our single biggest challenge right now is getting people to edit Wikipedia. We haven't made significant progress on turning that trend around, so if we're going to do a redesign of the skin as significant as this we need to emphasize this. As Brandon right points out, just turning the current Vector edit button in to a mw-ui-constructive style button would not solve the deeper problems in Vector, and would no doubt be odd-looking. I'm really glad this prototype starts to tackle those issues. But if you *seriously* think that Editing articles is not our most important call to action then we need to have a sit down and talk about this in person.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
On Wed, Jan 22, 2014 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I would argue that we should prioritize section editing over full page editing, and eventually VE will have section editing, even prior to that it at least has awareness of what section you triggered the edit action from.
This is an interesting hypothesis, and is largely dependent on what type of page is most likely to be edited. I would agree with you on large pages. But large, very popular pages are often likely to be difficult to edit for other reasons, or even semi-protected. The long tail of Wikipedia articles in all languages have maybe one or two sections at best, including References. Most articles are stubs.
In any case, I don't see that prioritization in the design of winter right now. Section edit links are very subtle visually. Also, they are moved back to the right, though A/B tests ran by Trevor suggest that putting them near the title with an icon was superior in conversion to editing.
On Wed, Jan 22, 2014 at 2:04 PM, Steven Walling swalling@wikimedia.orgwrote:
On Wed, Jan 22, 2014 at 1:50 PM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
I would argue that we should prioritize section editing over full page editing, and eventually VE will have section editing, even prior to that it at least has awareness of what section you triggered the edit action from.
This is an interesting hypothesis, and is largely dependent on what type of page is most likely to be edited. I would agree with you on large pages. But large, very popular pages are often likely to be difficult to edit for other reasons, or even semi-protected. The long tail of Wikipedia articles in all languages have maybe one or two sections at best, including References. Most articles are stubs.
In any case, I don't see that prioritization in the design of winter right now. Section edit links are very subtle visually. Also, they are moved back to the right, though A/B tests ran by Trevor suggest that putting them near the title with an icon was superior in conversion to editing.
Moving them next to the section-title would obviously have an effect, as they're more in-our-face! Annoyingly so. I'm using the gadgethttps://en.wikipedia.org/wiki/MediaWiki:Gadget-righteditlinks.csson Enwiki to move them back to the right. I like the Winter section-edit-links, in both placement and styling.
On Wed, Jan 22, 2014 at 2:18 PM, quiddity pandiculation@gmail.com wrote:
Moving them next to the section-title would obviously have an effect, as they're more in-our-face!
The best data we have on the section edit link is, IIRC, the original A/B test from a few years ago, summarized at: https://meta.wikimedia.org/wiki/Research:Section_edit_modification#Technical...
I don't think we tested for revert rate at the time, but we should certainly not make permanent further modifications to the location without good data-informed reasoning. "Annoying" isn't sufficient.
Erik
On Jan 22, 2014, at 2:25 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jan 22, 2014 at 2:18 PM, quiddity pandiculation@gmail.com wrote:
Moving them next to the section-title would obviously have an effect, as they're more in-our-face!
The best data we have on the section edit link is, IIRC, the original A/B test from a few years ago, summarized at: https://meta.wikimedia.org/wiki/Research:Section_edit_modification#Technical...
Personally, I think this was a flawed test and the results are skewed. Adding an icon *absolutely* skews the results. I’d be more apt to pay attention to this if it had been tested without the pencil icon.
I also think that having the location of the affordance be variable based upon the length of the section title is a bad experience.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Wed, Jan 22, 2014 at 3:38 PM, Brandon Harris bharris@wikimedia.org wrote:
https://meta.wikimedia.org/wiki/Research:Section_edit_modification#Technical...
Personally, I think this was a flawed test and the results are skewed.
It was a very limited test, yes. I'm fine with moving things around in a beta feature - but if we move them again permanently, let's construct a test we can stand behind to determine the final location.
Erik
On 01/22/2014 02:04 PM, Steven Walling wrote:
In any case, I don't see that prioritization in the design of winter right now. Section edit links are very subtle visually. Also, they are moved back to the right, though A/B tests ran by Trevor suggest that putting them near the title with an icon was superior in conversion to editing.
Yes to the pencil icon used by Mobile and Flow next to the title! I would even say yes to testing whether a blue pencil helps bringing more edits.
A word like "Edit" might be less inviting or even meaningful to newcomers. It's a fairly technical term, and even in e.g. social media it is more related to fixing typos and othr mistakes than to expand, be creative, enjoy. Add translations to the mix.
Any word in a page already full of words will have a harder time to shine than a simple pencil icon next to the title that captures everybody's attention.
Quim this sound similar to a mockup a make a while back with left hand, title associated icon only actions.
https://www.dropbox.com/s/f19q5rjkerjh84h/fixedheader.png
something to test…
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Wed, Jan 22, 2014 at 2:22 PM, Quim Gil qgil@wikimedia.org wrote:
On 01/22/2014 02:04 PM, Steven Walling wrote:
In any case, I don't see that prioritization in the design of winter right now. Section edit links are very subtle visually. Also, they are moved back to the right, though A/B tests ran by Trevor suggest that putting them near the title with an icon was superior in conversion to editing.
Yes to the pencil icon used by Mobile and Flow next to the title! I would even say yes to testing whether a blue pencil helps bringing more edits.
A word like "Edit" might be less inviting or even meaningful to newcomers. It's a fairly technical term, and even in e.g. social media it is more related to fixing typos and othr mistakes than to expand, be creative, enjoy. Add translations to the mix.
Any word in a page already full of words will have a harder time to shine than a simple pencil icon next to the title that captures everybody's attention.
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.orgwrote:
RE: Page actions moving into the header: (This is me collecting mycomments from a meeting to this list)
As I mentioned in yesterday’s design review, my gut instinct isthat moving article actions into the header is the wrong path:
* I don’t think they’re needed up there. Peoplealready scroll to the top when they need these functions. * I think it conflates those actions with the “personal bar” actions and creates confusion. A primary motivation for Winter is to segregate the following types of actions: Site actions (sidebar chrome), Content actions (page stuff), and Personal actions (user stuff). The search box is a site affordance. The personal actions are obviously thus. Mixing article actions next to the personal actions seems weird to me. * The point of discussion being always available is a valid one - the use case being, “I’m in this section, and I see an error, and I want to talk about it”. However, I don’t necessarily think that dumping the user into the “master” talk page at any point is going to solve that. A long time ago I had the idea to add a “discuss” link next to the section edit links. This would target the specific section and create a new discussion with that title (or find an existing one) and work within that. This is obviously something that can easily be done with Flow (though my original thoughts were with LQT). I’m not sure it works well with Talk. This is something I’ll want to experiment with.
I agree with those conclusions, and was getting worried about the number of icons in the current Winter headerbar, once scrolled. 7 ± 2https://en.wikipedia.org/wiki/Seven_plus_or_minus_twoworks.
One possibility would be replacing the current "article actions" icons in the headerbar, with a "scroll to top" button. It's a commonly requested feature, and (iirc) is generally turned down because of the sheer quantity of links that would be added, if they were attached to every section.
This is actually making me think more seriously about a system where site actions are shown at zero scroll (personal bar) and after article actions pass by the header they replace site actions which roll up into a single Dropbox (they are duplicated there anyway). So after the user scrolls all the actions are article actions except a single drop down with all site and personal actions in it.
This solves both for the too many icons issue as well as icons with duplicate appearance but different function appearing next to each other.
Also it sets us up nicely for a mode based nav bar where it is 99% relevant to the current task at hand (reading, editing, etc)
Sent while mobile
On Jan 22, 2014, at 5:09 PM, quiddity pandiculation@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:37 PM, Brandon Harris bharris@wikimedia.org wrote:
RE: Page actions moving into the header: (This is me collecting my comments from a meeting to this list) As I mentioned in yesterday’s design review, my gut instinct is that moving article actions into the header is the wrong path: * I don’t think they’re needed up there. People already scroll to the top when they need these functions. * I think it conflates those actions with the “personal bar” actions and creates confusion. A primary motivation for Winter is to segregate the following types of actions: Site actions (sidebar chrome), Content actions (page stuff), and Personal actions (user stuff). The search box is a site affordance. The personal actions are obviously thus. Mixing article actions next to the personal actions seems weird to me. * The point of discussion being always available is a valid one - the use case being, “I’m in this section, and I see an error, and I want to talk about it”. However, I don’t necessarily think that dumping the user into the “master” talk page at any point is going to solve that. A long time ago I had the idea to add a “discuss” link next to the section edit links. This would target the specific section and create a new discussion with that title (or find an existing one) and work within that. This is obviously something that can easily be done with Flow (though my original thoughts were with LQT). I’m not sure it works well with Talk. This is something I’ll want to experiment with.
I agree with those conclusions, and was getting worried about the number of icons in the current Winter headerbar, once scrolled. 7 ± 2 works.
One possibility would be replacing the current "article actions" icons in the headerbar, with a "scroll to top" button. It's a commonly requested feature, and (iirc) is generally turned down because of the sheer quantity of links that would be added, if they were attached to every section. _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
This is awesome. I love the user drop-down menu especially. My only criticism is that there is no visual distinction between the content and the interface. I would prefer for the content to stand out in some way. Otherwise the page looks somewhat busy and disorganized.
Ryan Kaldari
On Mon, Jan 20, 2014 at 3:31 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I’ve been making a thing. It’s actually got a code-name now! Nomore saying “Vector static header and navigation modification”.
LOTS of stuff going on with this update. Notably: * Now asks for a username on load, so as to set things up * All pages are loaded from the API via JSON. So it’s notjust the single static page. * Got rid of pretty much every color. * Article actions now dock in the header as you scroll. * Table of Contents is now in the header from the beginning * The sidebar’s border goes away as you scroll past it * Lots of links/actions do what you think they should. Most do not.
You can play with it here: http://unicorn.wmflabs.org/winter/ And read more about it here: https://www.mediawiki.org/wiki/Winter Here’s your changelog:== Changes, January 20 ==
- New code name: Winter
- System now prompts for a user name upon load and will optionally save
the value. ** This sets up the personal bar to be, well, personal. ** This action ''DOES NOT'' log the user into Wikipedia. ** Saved data can be cleared from the sidebar.
- Searchbox now drops text on focus and replaces it on blur
- Searchbox now has a hover state with invitation text.
- Searchbox icon now turns blue on focus
- Logo now snaps to white background when in locked position.
- Sidebar is now white by default, with a grey border that fades out when
all items in the sidebar are out of view.
- The Table of Contents now appears in the header of the page from the
beginning ** (Previous versions of Winter had the ToC only appear there after the in-page Table of Contents rolled off-screen)
- Article actions now dock in the header when they scroll out of view
(iconfied).
- Added tipsy behaviors.
- Fixed issue with search box positioning.
- Added pencil icons to section edit buttons
- Section edit buttons now are visible at all times but do not have
borders. ** On hover, they turn blue.
- Changed section edit hover transition from 'linear' to 'ease'
- Added footer section
- Added "categories" box in example article
- Added "Typography" toggle in sidebar. Activating it turns on:
** An approximation of restricted measure
- References have returned
- Built a JSON parser into the demo so that different pages can be loaded
via the API.
- Language links are now slotted into the sidebar.
- System correctly recognizes when it's looking at ''User'' content (User:
and User_talk:) and adds icons and functionality as required
- Handles contributions (sort of - buggy)
=== Known Issues ===
- Contributions views:
** Timestamps don't sort right ** Comment fields are not correctly parsed from wikitext to html ** Size changes are not correctly reflected
- Redlinks do not work
- System does not handle 404 loads correctly (fails silently, requires
reload)
- Internal hash URLs don't scroll correctly
- Some buttons don't go away when they should
- Loading from JSON breaks the nice little "section hover" stuff.
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