The behavior of the search box is quite odd and somewhat irritating. The "Search over four million articles" text is just silly and enWP-specific, and "Enter search terms" seems overly wordy-- why not just "Search"? Also, the change to showing the page name on scroll-down is disconcerting and confusing-- I sure wouldn't think to type in that box to search the whole site (while the search icon is there to tell you its a search box, it somewhat seems to be a search box for the article). I don't really think the page name is necessary, as it will be displayed in the title bar of the browser, but if it is desired, clicking the search icon could open a search box, or some of the title bar could be page name-only. Also, the blank doesn't really look like an input box-- why is this not using Agora forms? The hover and active-state behavior is also confusing: The text changes to "Enter search terms" and gets lighter, while the search icon gets darker (and blue on active). It seems like darker on hover would be logical (and then probably lighter when active) (or both could stay constant, like with Agora forms, with other indicators (border tone and colored bar)), and no change to the icon would also make sense, and the changing text is distracting (simply using "Search" would help with this).
|This page uses the Flow extension, a new piece of discussion and collaboration software. We need your feedback at Talk:Flow or en:WT:Flow (not on this page, please!) over the coming months, to help make it the system we all want to use. Please do random testing at Talk:Sandbox. See the Main FAQ and the Design FAQ for some basic details and answers, and a list of future feature ideas that have been suggested so far.|
Previous discussion is archived at Talk:Winter/Archive 1.
- Small view
- Collapsed view
- Full view
Why is the sidebar not fixed as well? It seems like a logical extension of the fixed header idea. If the sidebar is too long for the window, a separate scrollbar could be added for it. This would provide constant access to the many sidebar functions (tools especially would be useful).
2 days ago 03:35, 23 April 2014
- does this work with infoboxes (frameless or framed images)?
- is there a way to flow text around TOC? (get rid of donut hole, sorry perennial faq)
- nice top menu, do you want to integrate edit drop down with read article tab?
- the edit by section button appeared pushed down by images
- i see you have toc duplicated, in view contents drop down and in article space (choose 1?) i think i like view contents better
- would you consider making new look a skin, so oldsters can cling to their monobook?
4 days ago 22:29, 20 April 2014
- Infoboxes are outside of scope at this point. Redesigning them is a task of epic proportions, I'm afraid.
- No, I don't know of any way to do that, though we are looking at ideas about how to minimize its impact.
- The position of the "page edit" control is something we're not finalized on. Currently we have it set up as a more normal "button" and floated to the right on the same level.
- This is a known issue and one we'd fix in production.
- The duplication is intentional. If we were to remove the "in page" ToC, we'd have a great deal of resistance, I think, and I'm not sure we gain or lose much by having it in two locations.
- Monobook users should not be affected by this at all.
4 days ago 23:49, 20 April 2014
- thanks, i thought there were issues behind the choices.
- the monobook joke was a suggestion that winter new look be incorporated in a skin, so that there is an opt out by keeping the vector skin. (i don't know if this is possible compatibility), but it might aid adoption.
3 days ago 13:42, 21 April 2014
Is it possible to have a direct link to other projects on the same design as the language toolbar?
Many users like to see images, or search a related text on WikiSource. Can we imagine a visible link instead of a small box at the bottom of the article?
4 days ago 19:33, 20 April 2014
Cool stuff! Some small quibbles:
- Loading of the hoverstate version of the personal toolbar icons is deferred until the first hover, which causes the icons to disappear when you first hover over them until the image is loaded.
- Consider defining a CSS3 easing for the various controls that change opacity on hover, so they don't flicker if your cursor happens to glide over them while scrolling or moving to another part of the display.
4 days ago 19:24, 20 April 2014
Ori.livneh: Hrn. Doesn't happen for me but then I tend to have everything cached. They should pull in via css, and it's weird that they don't.
I had easing on pretty much everything for a while but it actually looked weird. In production, there won't be a lot of flicker/movement; it's an artifact of how the prototype has been built over time. For example, the TOC icon flickers into place - that's an artifact of it not having existed until you scrolled to a certain point. I just modified the code to fire the action off immediately rather than wait for a waypoint.
I should probably just refactor the hell out of this thing but I don't want to take the two days to do a rewrite.
4 days ago 19:27, 20 April 2014
Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like?
20 days ago 20:42, 4 April 2014
30 days ago 20:36, 25 March 2014
The clock is on the bottom half of http://bulbapedia.bulbagarden.net/wiki/MediaWiki:Monobook.js
30 days ago 23:09, 25 March 2014
I have published the results of two additional tests on Winter. These were competing tests and I expected one to fail fairly strongly (and was not disappointed).
The first test was identical to the "Electric Boogaloo" test. However, the Winter interface had been modified thus:
- No page-context actions are loaded into the fixed header.
- The user tools section does not shrink/collapse (thus always showing the username).
This test was a fairly significant success. All testers completed all tasks. Most users quickly pointed out that they knew they were "logged in" because of their username appearing in the corner and noted that they have a set of personal or profile tools there. More than one tester referred to this area as "their profile". No users had difficulty finding their contributions because of this. With one exception, all users found the context action ribbon quickly. The one who did not later was observed using it with proficiency. Many users unconsciously navigated with the context action ribbon afterwards. The search box remains mostly discoverable. Several testers unconsciously used it in the sticky format without scrolling to the top. No one used the table of contents in the header.
The second test was the polar opposite. For this test, the in page context actions (the ones below the article title) were removed. The page actions in the header were visible at all times, and the user tools menu did not collapse.
Most users encountered signficant icon confusion. In some cases, the confusion was enough to prevent them from accomplishing a task. In other cases, the confusion will obviously be problematic as cental editing themes are confused. The discoverability of the user tools section, when the username is present, is very high and remains so. The discoverability of the page action icons is almost non-existent. Several users expressed a desire for action labels. Many users failed to accomplish tasks that required these icons, or assumed they had achieved success when they did not. It is my belief that at least two testers assumed that the page action icons were just parts of their personal tools, and never looked there for page actions.
Over all tests, no one has ever used the in-header Table of Contents.
Test videos and more highlights available here:
Barring additional test desires, I'm going to collate all findings across all tests.
My current recommendations are:
- The in-header actions are confusing and should be removed.
- The user tools menu should not collapse as its discoverability significantly degrades when the user name is not present.
- The in-header table of contents has very low discoverability. No one has ever used it, and more than one tester has expressed confusion about it when it was found. We should remove it or explore alternatives.
- The search box remains highly discoverable, but it is my belief (backed by some tester statements) that the icon is a large part of this. Changing the text in the box reduces discoverability some but not enough that I would eliminate the behavior.
- A link to an article's talk page should be included in the in-page table of contents. Several users seem to want to go there.
1 month ago 19:37, 19 March 2014
I see in the videos that users are confused by the heaps of WikiProjects tags ("This article has been rated as C-Class on the project's quality scale" and such). So, some very obvious comments about this; nothing groundbreaking, but should be written, I guess.
Not all Wikipedias have WikiProject and tags. English and French have them, and maybe some other languages, but a lot of languages don't. So while they should be taken into consideration for testing and designing, it shouldn't apply to all languages.
It doesn't mean, however, that WikiProjects are not useful. This is yet another idea that grew organically in the community, and it can be "productized", as we say in WMF. They can become something like user groups if supported by the right software rather than hard-to-understand templates.
All of this has little to do with Winter, but can be considered as a different feature. For testing Winter itself maybe you can just assume that some day it will be done differently and simply remove these templates from the talk pages on the testing site.
1 month ago 20:19, 19 March 2014
Amire80: I commented on that confusion in the annotations of each test as it came up. It's not a new finding, and is orthogonal to the testing of the Winter prototype, which is why I didn't include it in the takeaways section.
As far as these being part of a distinct Wikiproject feature, that's actually on my roadmap for the feature set in what I'm currently calling the "affiliations" project.
I can't remove the templates from the test, unfortunately, as it's using live data from enwiki (loaded via the API).
1 month ago 20:31, 19 March 2014
Jorm (WMF): Part of the confusion might be with the lack of formatting. In the live, non-Winter view, WikiProject banners have an orange background, and are grouped together with other templates (also with orange backgrounds) that together form a visually cohesive "top matter" section. When the Template:Tmbox-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away.Show changes
30 days ago 05:47, 26 March 2014
Sven Manguard: While I agree that could be part of the issue, we hear the same kinds of comments from people viewing "normal" talk pages. The templates are simply opaque. I have a feeling that the combination of the templates with the fact that wikitext is horrid and doesn't look like a conversation space is the real problem.
29 days ago 17:44, 26 March 2014