Talk:Winter

Jump to: navigation, search

Previous discussion is archived at Talk:Winter/Archive 1.

Edit header
  • Small view
  • Collapsed view
  • Full view

Typography refresh

12 days ago 23:33, 5 April 2014

2

Julia W (talk | contribs)

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like?

13 days ago 20:42, 4 April 2014

Reply
Jorm (WMF) (talk | contribs)

Julia W: In the left sidebar, there's a link "new typography", which will turn it on. It's a flag you can enable or disable.

13 days ago 01:01, 5 April 2014

Reply
Julia W (talk | contribs)

Jorm (WMF): Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :)

12 days ago 23:33, 5 April 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
50.17.174.94 (talk)

Clock

23 days ago 23:09, 25 March 2014

1

Sven Manguard (talk | contribs)

We are, between the different beta features being deployed, rapidly moving towards the point where viewing and using Wikipedia as it is intended (under default settings) requires javascript.

My understanding was that one of the major reasons why we've never had a real time clock up top is that it would have required javascript, and a few years ago people wanted to have the project function without javascript, for people that didn't have it. This could be totally wrong, but it's what I was told a while back.

Now that we are deploying more and more javascript-dependent components, I would be interested in hearing what people have to think about adding in a real time UTC clock, somewhere up top. I am a big fan of what Bulbapedia did with their clock, in that it is both a real time UTC clock and a link to purge the page. I am not sure that having it count the seconds is useful, but being able to look up and see the current time in UTC is certainly useful, especially on discussion pages, editing windows, page history, and contributions pages.

23 days ago 20:36, 25 March 2014

Reply
Sven Manguard (talk | contribs)

The clock is on the bottom half of http://bulbapedia.bulbagarden.net/wiki/MediaWiki:Monobook.js

23 days ago 23:09, 25 March 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
50.17.174.94 (talk)

Third and Fourth Test Battery Results

22 days ago 17:44, 26 March 2014

3

Jorm (WMF) (talk | contribs)

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.

29 days ago 19:37, 19 March 2014

Reply
50.17.174.94 (talk)
Amire80 (talk | contribs)

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.

29 days ago 20:19, 19 March 2014

Reply
Jorm (WMF) (talk | contribs)

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).

29 days ago 20:31, 19 March 2014

Reply
Sven Manguard (talk | contribs)

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
Last modified by Sven Manguard

22 days ago 05:47, 26 March 2014

Reply
Jorm (WMF) (talk | contribs)

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.

22 days ago 17:44, 26 March 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
50.17.174.94 (talk)

Second User Test Battery Results

1 month ago 20:11, 15 March 2014

1

Jorm (WMF) (talk | contribs)

I have run two sets of user tests with Winter to determine the usability of in-header page action icons and whether or not users can easily recognize their personal tools menu and the search box, especially after scrolling in the page.

Two tests were run because the first test had some possible errors and confusions. The second test (Winter Harness Two Electric Boogaloo) had some modifications to the flow to avoid people getting lost on user talk pages (this was the result of the first version of Harness Two telling them to click on the Speech Bubble icon in the top right if they were lost - but they had scrolled to the top already). H2:EB corrected this by directing them to the context action ribbon.

  • Only one user out of ten correctly used the in-header page action icons. Further, his language indicated that he had some icon confusion: he thought that only a few icons were added, and that existing ones were moved (e.g., history and edit were new, but the watch list icon was still the same).
  • Most users were unable to recognize the personal tools section as being "my stuff" unless their username was also included. Once the username was gone, it was invisible to them (with rare exceptions, and mostly by accident then).
  • No users had trouble with the search box. At all.
  • Most users ended up using the context action ribbon and ignored other navigation hints.
  • The in-header TOC might as well be invisible.
  • At this point, with 10 testers and a 10% success rate, I'd say that the benefits of putting page icons in the header are outweighed by the negatives of losing the username for discoverability.

1 month ago 20:11, 15 March 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)

First User Test Battery Results

1 month ago 01:44, 14 March 2014

2

Jorm (WMF) (talk | contribs)

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the testing section on the main Winter page.

All tests are annotated, but highlights are included in-line.

The primary take-aways are:

  • No tester had difficulty recognizing the search bar.
  • All testers quickly grasped the in-page context action ribbon.
  • Several testers expressed surprise that Wikipedia had discussions, which lends even more credence to the idea that Vector tabs are effectively invisible.
  • The "Cancel" button from the editor may need work.
  • All testers found their way to the contributions page, even when faced with bugs/difficulties. They just did it in other routes.

1 month ago 03:00, 8 March 2014

Reply
50.17.174.94 (talk)
Jorm (WMF) (talk | contribs)

If you are interested, please review some of the tests and provide feedback soonish. I want to run the second harness on Monday (the one that tests the discoverability of actions when they become available in the fixed header) but I also want to fix any bugs in the tests before then.

1 month ago 03:06, 8 March 2014

Reply
50.17.174.94 (talk)
Sven Manguard (talk | contribs)

I took a look at the current version and I would recommend that the cancel button be moved over to the right side, or that you move the three things on the left over to the right. Either way, preview and save should be in the same place as cancel. I was able to find it only because I was looking for it (having read this thread), and because I knew that there were only a limited number of places it could be.

1 month ago 22:03, 13 March 2014

Reply
Jorm (WMF) (talk | contribs)

Sven Manguard: The editor changes were really only experimental and haven't had a lot of thought behind them (though the Cancel button issue you mentioned definitely was informational - I know exactly what you're talking about). Mostly, we wanted to test if people could find the edit button, so I had to fake up an actual editor to let them (the testers) know that they had succeeded.

I expect that editor changes are are going to be a big, long running thing.

1 month ago 01:44, 14 March 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
50.17.174.94 (talk)

Amboxes

1 month ago 20:12, 21 February 2014

3

Tucvbif (talk | contribs)

I see, amboxes is not separated from the article body. It's bad.

1 month ago 17:23, 21 February 2014

Reply
50.17.174.94 (talk)
Edokter (talk | contribs)

That is because they are templates, which are always part of content.

1 month ago 17:27, 21 February 2014

Reply
50.17.174.94 (talk)
Jorm (WMF) (talk | contribs)

It's also possible that the css used by them was not ported to the Winter prototype. The HTML is loaded through the API, but I'm not using anything that may be in enwiki's Common.css.

1 month ago 20:12, 21 February 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)

Bunched edit links

Show changes
Last modified by TheDJ

1 month ago 19:00, 27 February 2014

  • TheDJ, This, that and the other, Sven Manguard and 1 other
  • 9 comments

4

TheDJ (talk | contribs)

I see Winter is running into the Bunched edit links problem (bug 1629) https://en.wikipedia.org/wiki/Wikipedia:How_to_fix_bunched-up_edit_links

This was a very famous problem in earlier versions of monobook/vector. It is NOT a bug, it is just how CSS is supposed to work in this situation. A workaround was added in 2010 that avoids this problem. See bug 26449.

Show changes
Last modified by TheDJ

1 month ago 10:04, 19 February 2014

Reply
Jorm (WMF) (talk | contribs)

TheDJ: Can you point me to an article that shows the problem? I'm having difficulty finding one, so any fix I add is a shot in the dark at best.

1 month ago 20:15, 21 February 2014

Reply
50.17.174.94 (talk)
Sven Manguard (talk | contribs)

I wonder if TheDJ is talking about File:Winter prototype edit link cluster.png?

1 month ago 22:19, 26 February 2014

Reply
50.17.174.94 (talk)
Jorm (WMF) (talk | contribs)

Sven Manguard: Oh, shizzit! That's perfect. I can play with that one.

1 month ago 22:44, 26 February 2014

Reply
50.17.174.94 (talk)
Sven Manguard (talk | contribs)

Jorm (WMF): I have an observation on those. When I loaded up the Winter demo today, all of the links were in the right place before the files on the right hand side loaded. Once the files on the right hand side loaded, the edit links moved to the bottom, like they are in that screenshot. I looked at the page Hail, which has fewer images, and it certainly appears that there is a direct relationship between images that protrude into the next subsection down and misplaced edit links. I suspect that the placement of the images in the wikitext itself is a factor. I created File:Winter prototype edit link analysis.png to illustrate my theory.

1 month ago 03:01, 27 February 2014

Reply
50.17.174.94 (talk)
Jorm (WMF) (talk | contribs)

Sven Manguard: I actually fixed it in my version, and I'll upload it probably early next week.

1 month ago 03:09, 27 February 2014

Reply
50.17.174.94 (talk)
TheDJ (talk | contribs)

Sven Manguard: File:Winter prototype edit link cluster.png is exactly what I meant yes. This is a not so well known side effect of using float and clear. It behaves perfectly according to spec, it's just not what you expect it to do.

Show changes
Last modified by TheDJ

1 month ago 19:00, 27 February 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
This, that and the other (talk | contribs)

When I view the Thailand article with Firefox maximised to 1920x1080, the "History" section edit link gets shunted down to the wrong place.

1 month ago 03:31, 22 February 2014

Reply
Jorm (WMF) (talk | contribs)

This, that and the other: Thanks! That's exactly what I'm looking for.

1 month ago 06:37, 22 February 2014

Reply
50.17.174.94 (talk)
50.17.174.94 (talk)
50.17.174.94 (talk)