Talk:Winter/Archive 2/Flow export

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

Bunched edit links

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. —TheDJ (Not WMF) (talk • contribs) 10:04, 19 February 2014 (UTC)

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. Jorm (WMF) (talk) 20:15, 21 February 2014 (UTC)

I wonder if TheDJ is talking about File:Winter prototype edit link cluster.png? Sven Manguard (talk) 22:19, 26 February 2014 (UTC)

Sven Manguard: Oh, shizzit! That's perfect. I can play with that one. Jorm (WMF) (talk) 22:44, 26 February 2014 (UTC)

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. Sven Manguard (talk) 03:01, 27 February 2014 (UTC)

Sven Manguard: I actually fixed it in my version, and I'll upload it probably early next week. Jorm (WMF) (talk) 03:09, 27 February 2014 (UTC)

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. —TheDJ (Not WMF) (talk • contribs) 19:00, 27 February 2014 (UTC)

When I view the Thailand article with Firefox maximised to 1920x1080, the "History" section edit link gets shunted down to the wrong place. This, that and the other (talk) 03:31, 22 February 2014 (UTC)

This, that and the other: Thanks! That's exactly what I'm looking for. Jorm (WMF) (talk) 06:37, 22 February 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Amboxes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I see, amboxes is not separated from the article body. It's bad. Tucvbif (talk) 17:23, 21 February 2014 (UTC)

That is because they are templates, which are always part of content. -- [[User:Edokter]] {{talk}} 17:27, 21 February 2014 (UTC)

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. Jorm (WMF) (talk) 20:12, 21 February 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

First User Test Battery Results

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Jorm (WMF) (talk) 03:00, 8 March 2014 (UTC)

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. Jorm (WMF) (talk) 03:06, 8 March 2014 (UTC)

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. Sven Manguard (talk) 22:03, 13 March 2014 (UTC)

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. Jorm (WMF) (talk) 01:44, 14 March 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Second User Test Battery Results

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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.

• Winter#Harness_Two:_Winter
• Harness_Two:_Electric_Boogaloo

• 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. Jorm (WMF) (talk) 20:11, 15 March 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Third and Fourth Test Battery Results

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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:

• Winter#Harness Three: Winter: No Header Icons
• Winter#Harness Four: Winter: Only Header Actions

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. Jorm (WMF) (talk) 19:37, 19 March 2014 (UTC)

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. Amir E. Aharoni {{🌎🌍🌏}} 20:19, 19 March 2014 (UTC)

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). Jorm (WMF) (talk) 20:31, 19 March 2014 (UTC)

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. Sven Manguard (talk) 05:47, 26 March 2014 (UTC)

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. Jorm (WMF) (talk) 17:44, 26 March 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Clock

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Sven Manguard (talk) 20:36, 25 March 2014 (UTC)

The clock is on the bottom half of http://bulbapedia.bulbagarden.net/wiki/MediaWiki:Monobook.js Sven Manguard (talk) 23:09, 25 March 2014 (UTC)

You have a clock in the taskbar of your desktop as well, no need to waste space on the toolbar to add another one. And they usually allow to add more than one clock for different timezones as well. Ciencia Al Poder (talk) 09:36, 28 April 2014 (UTC)

Ciencia Al Poder: Wow, I had no idea I could do that. Thanks! I suppose that the clock isn't as important to me now, although an easy purge link (that appears on every page) is still something that's useful to me, considering that is transcluded from subpages doesn't update unless I purge. Sven Manguard (talk) 03:20, 30 April 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Typography refresh

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? Julia\^talk 20:42, 4 April 2014 (UTC)

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. Jorm (WMF) (talk) 01:01, 5 April 2014 (UTC)

Jorm (WMF): Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) Julia\^talk 23:33, 5 April 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Personal toolbar icons flickering

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. ATDT (talk) 19:24, 20 April 2014 (UTC)

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. Jorm (WMF) (talk) 19:27, 20 April 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Language toolbar / other projects toolbar

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?

Thanks Trizek ^{from FR} 19:33, 20 April 2014 (UTC)

Trizek: Why yes, it is possible to do that. And, in fact, something like that is on my radar/roadmap. I've a couple ideas for content exploration, but it'll be a little while before I can get to them. Jorm (WMF) (talk) 19:48, 20 April 2014 (UTC)

Trizek: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. Jorm (WMF) (talk) 05:15, 14 July 2014 (UTC)

nice

• 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? Slowking4 (talk) 22:29, 20 April 2014 (UTC)

Slowking4:

• 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. Jorm (WMF) (talk) 23:49, 20 April 2014 (UTC)

Slowking4: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. Jorm (WMF) (talk) 05:13, 14 July 2014 (UTC)

Jorm (WMF):

wow, even nicer - menus across the top seems to be the standard. and will work better with VE this is going to be a game changer for mobile, tablet. kudos, hope you get the ovation at wikimania the team deserves. Slowking4 (talk) 20:34, 15 July 2014 (UTC)

• 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. Slowking4 (talk) 13:42, 21 April 2014 (UTC)

xoxo Slowking4 (talk) 20:33, 15 July 2014 (UTC)

TOC gets a little small

The TOC on pages with lots of nested sections winds up with difficult-to-read text in the smaller sections. Maybe it's not necessary to so drastically change the font size with each iteration? Maybe have a minimum level? MarkTraceur (talk) 16:18, 21 April 2014 (UTC)

MarkTraceur: Are you referring to the in-page ToC or the menu-pull down one? What browser are you using? It shouldn't be getting smaller. Jorm (WMF) (talk) 17:42, 21 April 2014 (UTC)

Jorm (WMF): In-page. I see this in Firefox: https://i.imgur.com/7sV5CHK.png

(Separate issue: the menu-pulldown ToC doesn't scroll in Firefox. Possibly a known issue with the prototype) –Quiddity (talk) 17:56, 26 April 2014 (UTC)

IE8

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~ Geni (talk) 04:32, 22 April 2014 (UTC)

Geni: The prototype is not designed to work with Internet Explorer, unfortunately. Jorm (WMF) (talk) 15:22, 22 April 2014 (UTC)

If latest trend will continue IE8 will perish by the end of the year so I wouldn't worry too match. I think older skin (e.g. Vector) could be served for old browsers. This could save some work and complex CSS and JS workarounds would not be needed. Nux (talk) 18:13, 5 May 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Fixed sidebar

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). Jay8g (talk) 03:35, 23 April 2014 (UTC)

Jay8g: Sidebars can be of varying length. If you can't control the vertical height of an element, you can't set it to be fixed without independent scrolling mechanisms - which, in this case, are the browser scroll itself - so there's no value added. Jorm (WMF) (talk) 02:03, 29 April 2014 (UTC)

Jorm (WMF): But if you make it have an independent scrollbar, it is visible when you scroll down, like the header. Other websites have done this--see Google News for an example. Jay8g (talk) 02:14, 29 April 2014 (UTC)

Jay8g: We're actually working out ways to get rid of the sidebar entirely. Jorm (WMF) (talk) 02:28, 29 April 2014 (UTC)

Good idea. It could be useful especially combined with collapsible menu items. KuboF Hromoslav (talk) 15:21, 28 April 2014 (UTC)

Search box

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). Jay8g (talk) 04:02, 23 April 2014 (UTC)

+1 to that. Mixing title of the page and the search box is a bad idea. It suggest this is a current page search, not site search. Nux (talk) 18:09, 5 May 2014 (UTC)

Narrow screens and the search bar

When the screen is too narrow, the search bar is moved down below the toolbar, but the rest of the page is not moved: So the searchbar is partly covered.

Also when the screen is narrow, the side bar should better collapse and be replaced by a small version of the site logo in the toolbar; which will open as a popup when hovered (a dropdown, or a horizontally sliding pane from the left border), so that we get back more width for the content (this is important for users of smartphones and phablets; but as well when users want to split their screen in two parts side by side on reasonnably large enough desktop/notebook displays: here this is a snapshot on a notebook where the window uses about 50% of the width i.e. a width of about 640 pixels including the window frame of the browser; or 620 pixels in the display area; without the side bar, there remains the width of margins and the display area for the site content is only about 380 pixels; the side bar takes as much as about 172 pixels which could increase the width of the content area of about 50%; still this is not the minimum width and on msartphones and phablets the screen will not be much narrower than the equivalent of 400 pixels, because the high resolution of these small devices forces users to use wider fonts for readability or accessibility; then the 172 pixels are really too large so the side bar should be hidden be default like on the mobile versions of wikis).

[The current setting using the "Hide Sidebar: on" link in the side bar is really ugly, and does not remove the side bar which is only blanked without gaining its space. In my opinon there should just exist a "pin" icon in the top-right corner of the side bar, allowing it to remain fixed to the left of the scrollable content area, otherwise it will autocollapse and only a small site logo will be in the top-left corner of the top "Winter" bar to open the Sidebar (which will still be vertically scrollable with the page content); the side bar should be unpinned by default, and also collapsed if the window width is less than about 480 pixels; it will appear only when the mouse hovers the small icon in the top-left, or is within the pane, or has the input focus; when the side bar collapse, it should not be deleted, and should preserve its content state, notably the state of its "toolbox" section which is also collapsible vertically]. Verdy p (talk) 14:37, 26 April 2014 (UTC)

The idea of a collapsible sidebar coming from the logo in the toolbar, for small resolutions, would be very cool! Ciencia Al Poder (talk) 09:28, 28 April 2014 (UTC)

Note: the mini logo could remain in the top toolbar, but if the window is high enough and the width is not too narrow, the full logo may remain to the right of the top bar the search bar (when it is displayed below it), the top title and the "updated" notice and the Edit button.

This full logo could still collapse to the mini logo in the top toolbar, when scrolling down the page (along with the title, "updated" notide and "Edit" button), keeping only the top toolbar above the rest of the content.

One problem: all wikis have PNG logos (with a fixed size) but they are not easy to scale down. However we already have SVG versions of official logos which could be the simplified one without text.

These minilogos (that we need to keep displayed in the left of the top toolbar, or the right for RTL wikis, so that we can hover these logos in order to "popup" the side toolbar, sliding from the left of the window within the scrollable content area just below the top toolbar) would require a per-wiki setup, otherwise rescaling the existing PNG logo could still be used in the interim as long as these wikis have not configured their mini logo mini logos also exist in PNG versions without text, they are used for example in wiki ho,e pages showing the other available projects generally at botto, of pages in a navigation table.

But a good question remains: shouldn't the edit button be part of the fixed toolbar at top of window above the scrolling area for the content? Or do we need to scroll up to the top of page to see this button?

Note: some users will prefer not having the side bar collapse automatically when their screen is large enough. Others will prefer seeing the side toolbar collapsed by default even on large screens. My opinion is that this side bar should then be pinnable.

When pinned, it no longer covers the content aarea but is displayed to the right of it; as it is today:: The "autocollapse side bar on large screen" could then be a preference, off by defaut, or the wiki could just automatically remember the pinned state when navigating between pages, using a session cookie: the preference would still be stored and used when there's no session cookie.

In all cases, the "pin" icon (displayed in the top right corner of the side bar, or top left corner on RTL pages) would always be visible on large windows. On narrow windows (including for those that open two browser windows, or two navigation tabs side by side in the same browser window) it would be disabled. (Both conditions would also apply for the mobile version depending on window width). Verdy p (talk) 19:32, 2 May 2014 (UTC)

Additional notes:

(1) The small "pin" button in the collapsible and vertically scrollable side bar should not scroll by itself, it should remain in the visible top-left corner (even if it covers some contents of the side bar when it is scrolled down).

(2) When the side bar is pinned, it could also scroll independantly of the content area, to preserve the position on screen of its displayed tools even when we scroll down the content.

But this would require an additional vertical scrollbar; if this side bar does not fully fit in the height of the scrollable area, taking some additional width (which is also browser dependant). That's why I suggest keeping the side bar (autocollapsible or pinned) scrolling along with the content area, with the exception of the pin button on top of it with option (1). However if the screen is high engough to fully fit the side bar, it should not scroll with the content.

All this requires monitoring precisely the window width and height in order to generate a usable layout between what is scrollable and what is not.

(3) some people will still want to see the top bar disappearing when scrolling down (like today) in order to see more vertical content. So this top bar could also have its own "pin" button to detach it from the window top border and attach it to the content and in that case only this pin button should remain on screen. This pin button could be the same mini-logo icon but it could give confusion (because you would nee to hover the top-right pin to uncollapse the top toolbar, and then see the top-left mini icon controling the visibility of the side bar). Verdy p (talk) 19:50, 2 May 2014 (UTC)

Version 0.6, released today, contains the beginnings of experiments with responsive design. The specific bug shown should be fixed (though it should be pointed out that the right rail experiment tends to break a lot of the responsive technology). Jorm (WMF) (talk) 05:11, 14 July 2014 (UTC)

Current skin isn't enough?

We can done a fixed head in Vector as well, please see my CSS code to do this - en:User:Rezonansowy/scripts/FloatHead. Rezonansowy (talk) 12:30, 28 April 2014 (UTC)

Rezonansowy: This is being built on top of Vector, actually. Jorm (WMF) (talk) 02:03, 29 April 2014 (UTC)

Jorm (WMF): I really hope it will be considered a separate skin, as it is even more different from Vector than Vector was from Monobook... Jay8g (talk) 03:39, 29 April 2014 (UTC)

Jay8g: It will not be a separate skin. It's being implemented as an extension to the existing one. Jorm (WMF) (talk) 03:43, 29 April 2014 (UTC)

But do we need a separate design for it? I suggest we should create an effort to enhance the current Vector skin.

Winter's current paper milestones and proposed alternatives in Vector:

• Fixed Header - we can use FloatHead.css
• Larger Search Area - this could be done with CSS as well (see my commons.css)
• Minimized User Actions Area - see mockup File:New Menu.png
• No More Blue Border - CSS, this could be customized by any wiki itself (see http://nonsensopedia.wikia.com) Rezonansowy (talk) 18:05, 29 April 2014 (UTC)

Rezonansowy: It may help you to know that a great deal of this development work has already been done. We have some specific goals in mind for these changes which require a more holistic approach to the implementation; just attaching stock/pre-built css modules isn't going to solve the problems. Jorm (WMF) (talk) 18:20, 29 April 2014 (UTC)

Make it more airy and focussed

On stubs and short articles, the line that saperates the footer and the article, like here, seems to suffocate the experience, as if the reader is gasping for fresh air. Like the current vector skin, make the sidebar and header a little dark shaded so as to bring attention to the main article. Also the search bar is too big for a desktop experience. It might be OK for a mobile site. Let the default text in the search bar stay simply as "Search". Make the header a bit smaller. Fauzan (talk) 18:20, 28 April 2014 (UTC)

I agree that the search bar is too long on a desktop screen, but I particularly agree that showing any default text in the search bar than “Search” is a bad idea. “Enter search terms here” is unnecessarily long and the “Search over four million articles” looks wrong when it changes to “Enter search terms here” and isn’t really relevant anyway.

I am particularly dissatisfied with the enormous edit buttons placed at the right of every section header. I realize we want people to know they can edit articles and remind them of it, but having huge buttons like these just distracts the reader and looks really wrong. Rastus Vernon (talk) 14:40, 17 May 2014 (UTC)

Where is the code for this?

Some very basic documentation on where git repo is for this, and how to install it are in order. Ian Kelling (talk) 03:16, 3 May 2014 (UTC)

Ian Kelling: The code for this is extremely alpha and I'd suggest against installing it. Jorm (WMF) (talk) 03:52, 3 May 2014 (UTC)

Jorm (WMF): I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). 50.163.53.37 (talk) 19:38, 10 July 2014 (UTC)

50.163.53.37: Very soon now - like, within the next week - I'll be putting the code into a depot. Jorm (WMF) (talk) 19:40, 10 July 2014 (UTC)

50.163.53.37: Source code is available now. Jorm (WMF) (talk) 05:06, 14 July 2014 (UTC)

Ian Kelling: The source is available now, and you can find it on Winter. Jorm (WMF) (talk) 05:07, 14 July 2014 (UTC)

I'm a software developer. I might have some useful contribution to make. Ian Kelling (talk) 21:14, 3 May 2014 (UTC)

Page title and buttons (history, discussion, watch) on the same lin

Right of the title is a lot of space where the buttons fit perfectly. Giving the page approx. two centimeters vertical space. 2003:63:2F35:5C00:1019:46FF:21C:56CF (talk) 17:43, 14 May 2014 (UTC)

2003:63:2F35:5C00:1019:46FF:21C:56CF: 2 problems:

• That's only the case for articles with short titles. It wouldn't work for Three Studies for Figures at the Base of a Crucifixion or List of cricketers who have scored centuries in both innings of a Test match (both Featured pages).
• It would make the location of the buttons inconsistent for every page. They could be on the left, or the middle or the right, or linewrapped. –Quiddity (talk) 21:04, 15 May 2014 (UTC)

More prominent access to permalinks would be good

Very few people beyond our direct community are aware of the existence of links to particular versions of any given page - on the English Wikipedia, the "Permalink" option is squirreled away in the Tools section of the navigation bar on the left. The word "permalink" itself is even jargon. I think the future interface for MediaWiki would benefit readers of all types by offering somewhere an obvious and simple point of provision of a permanent link to whatever page is being currently viewed. — Scott • talk 18:07, 15 May 2014 (UTC)

JavaScript and drop down menus

As Sven Manguard has already mentioned, one of the strong advantages of the MediaWiki skins is that they do not require JavaScript. This is essential for users who have it disabled, but also for users of text browsers or users who need to use screen readers.

Putting everything into drop down menus might cause accessibility problems for these users, and also for users who disable JavaScript for other reasons. I think this new design should be tested with text browsers and screen readers in order to make sure that it works at least as well as the current Vector skin with them.

I also like how the Vector and the Monobook skins make all their functions available directly, plain in view. I realize the need for compactness, but I don’t think putting essential links in drop down menus is a good idea. Rastus Vernon (talk) 16:17, 17 May 2014 (UTC)

Drop-down menus don't require JavaScript, they can easily be done with hover and active CSS states. 137.147.156.9 (talk) 03:29, 18 May 2014 (UTC)

I think the primary reason it is JS right now, is because dom changes are required in the BETA phase of this project. When I spoke to the team last hackathon, they said that if successful it would probably get a rewrite to be less dependent on JS. —TheDJ (Not WMF) (talk • contribs) 13:05, 19 May 2014 (UTC)

TheDJ: Also, it's written entirely in Javascript and CSS - at least the prototype. Jorm (WMF) (talk) 02:56, 20 May 2014 (UTC)

Experimental layout

In the discussion at Typography Refresh, an experimental layout was announced (but never implemented), where all templates and images are separated from the text into a column on the right, as they are in this image. Is there a future for this idea, either in Winter or elsewhere? Ypna (talk) 11:29, 20 May 2014 (UTC)

JamesDouch: It is a future idea, and it is part of Winter. You'll likely see prototype work on it in the next couple weeks. Jorm (WMF) (talk) 00:42, 21 May 2014 (UTC)

JamesDouch: Version 0.6, deployed this evening, has this feature. Jorm (WMF) (talk) 05:05, 14 July 2014 (UTC)

Jorm (WMF): How do you enable it? I don't see anything in the interface about it... 128.29.43.2 (talk) 17:45, 14 July 2014 (UTC)

128.29.43.2: It's already enabled. It just doesn't move all the templates over; only a subset at this point. Jorm (WMF) (talk) 17:52, 14 July 2014 (UTC)

Jorm (WMF): Will it move images over? That would make use of the empty space and declutter the body text. Ypna (talk) 11:25, 16 July 2014 (UTC)

Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) Ypna (talk) 10:02, 21 May 2014 (UTC)

Fixed header - notes

Just a note (though you probably already know): The extension:Translate adds a fixed header, when we scroll down past the filtering-line. Test at https://meta.wikimedia.org/wiki/Special:Translate?language=de&filter=!translated&action=translate

These 2 systems would need to play well with each other. :) –Quiddity (talk) 17:13, 22 May 2014 (UTC)

Other sites that use a fixed-header (aka sticky navigation) in good/interesting ways:

Scroll-up, to have the header pop-down

• Washington Post
• Medium
• Happycog (Zeldman's design studio)
• (same idea implemented with headroom.js demo - code)

Standard fixed headers

• gmail
• youtube
• facebook
• twitter
• link-deluge of smaller sites and commentary at teamtreehouse and awwwards –Quiddity (talk) 21:05, 12 October 2014 (UTC)

A very interesting idea about getting content elements to become temporary-fixed-headers, eg for table-headings: demo - code –Quiddity (talk) 21:05, 12 October 2014 (UTC)

Watchlist icon hidden

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. Swordman97 (talk) 17:37, 19 June 2014 (UTC)

Swordman97: That's actually a bug in that specific version of Winter. It will get fixed in the next version. Jorm (WMF) (talk) 18:54, 19 June 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Could this be used to keep TOC from scrolling page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

https://github.com/Robdel12/DropKick Jaredzimmerman (WMF) (talk) 21:03, 28 June 2014 (UTC)

Jaredzimmerman (WMF): No; this only works on SELECT tags and the ToC is significantly more complicated. Jorm (WMF) (talk) 20:05, 2 July 2014 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Opt-out

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? BethNaught (talk) 09:53, 12 July 2014 (UTC)

BethNaught: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. Jorm (WMF) (talk) 06:38, 13 July 2014 (UTC)

An option to unfix the header

I would like an option to unfix the header. Partially because I like having as much content on screen as possible and on smaller screens it eats a notable portion of the screen, and partly because things following me as I scroll that I can't get away from has just always bugged me. Having search and tools accessible is not a notable advantage to me since with a scroll wheel flipping back to the top takes a fraction of a second, while the annoyance and loss of some space is. Ideally via something relatively easy to find (user preferences?) rather than digging about in gadgets or custom css/js.

Other than the fixed header, I'm liking the look of this a lot. etesp (talk) 21:08, 13 July 2014 (UTC)

Etesp: There's a request for a "snowflake" that will do something similar to what you're asking - I just have to build it (or someone else can, I suppose).

One of the primary reasons to have the personal tools always available is that, in the future, we'll want to have the notifications system do polling, which will then allow for immediate updates. Another reason is to allow for the table of contents to always be available, as well as access to the talk page and history.

There's going to be a new version released very soon (like, maybe today if I can get off my ass and finish writing up some documentation), and hopefully some of the thinking will make more sense. Jorm (WMF) (talk) 22:26, 13 July 2014 (UTC)

Jorm (WMF): Ah, I missed that, glad to see it's in the plan.

And yep, I see the reasons for it and imagine the fixed header will be useful to many people, I just want a way to turn it off personally. Looking forward to being able to use it :). etesp (talk) 00:48, 14 July 2014 (UTC)

Etesp: Do you browse in fullscreen then? Because the tab bar, address bar and task bar all "follow" you when you scroll. How is having a search bar do so too annoying? 124.180.202.60 (talk) 04:33, 14 July 2014 (UTC)

124.180.202.60: No, but I generally use firefox and customize it to have only the tabs and address bar (with bookmark icons on the same bar, rather than below) to minimize lost screen space. Being able to quickly switch tabs and programs comes in handy vastly more often than search or the other MW tools.

I guess it's also a psychological thing, I separate "website" out from "program" and find it much more annoying when websites don't let me scroll away from some part of them, whereas programs are kinda there all the time you're using them so I get used to it, though I try to tidy up any program which has customizable UI. etesp (talk) 14:06, 14 July 2014 (UTC)

124.180.202.60: The scroll bar is for the contents of the web page pane, not the greater program interface. Look at where the scroll bar ends. Does it extend above the tabs, address bar, and task bar? No. It ends at the top of the web page.

Having web page contents disobey the scroll bar (without an option to disable it) breaks the interface. I very much agree we need the option to unfix the header, at the very least. 71.19.177.226 (talk) 17:05, 16 July 2014 (UTC)

71.19.177.226: That's barely noticeable, and certainly doesn't make it seem more like it's "following" you. That's not too difficult to fix anyway. Just put a container around the rest of the page that isn't part of the header and set that to overflow:auto; height:100% and set the body to overflow:hidden. 124.180.202.60 (talk) 06:55, 17 July 2014 (UTC)

0.6 comments

1. Took me six minutes to find the "Watch page" icon... should be grouped with page actions.
2. .mw-echo-timestamp font-size should be 11px, not 9px (as in production). 9px is too small.

I feel grouping and icon order could use some work in general; such as user/user-talk pages, while others are duplicated too much, such as article discussion links. -- [[User:Edokter]] {{talk}} 09:35, 14 July 2014 (UTC)

Waste of space

(Sorry for the bad grammar)

I'm on a 15" laptop (it's pretty standard for me).

The left and right column eat 50 % of the screen's space... For two empty menu :

The left have 6 links + 1 icon.

The right have a interlanguage link template roll up + a vertical nawbox (which are pretty uncommon on wp.fr) + some interwiki template (When wikidata and for projects want to integrate them on the left column). I personally don't want to use a skin with so waste of space. Nouill (talk) 12:06, 14 July 2014 (UTC)

Interlanguage links 1: should suggest the most likely languages first

The language links are quite nicely done, but we really should consider using the logic from the ULS compact links beta feature to show the likely languages first. It automatically picks the languages that the user is most likely to use according to geolocation, the previous languages that the user clicked on, the Accept-Language value in the request, the MediaWiki UI language, browser UI language, and the previous languages that the user selected.

As of now, 7,629 people selected it in enwiki and thousands more in other languages, and it's an indicator that people probably want such a thing. Amir E. Aharoni {{🌎🌍🌏}} 15:10, 14 July 2014 (UTC)

Amire80: This is the plan, but, with the prototype, there's no way to do that. So I have to pick either the first four or five, or randomize, and it's just easiest to count to five. Jorm (WMF) (talk) 15:55, 14 July 2014 (UTC)

Interlanguage links 2: language name search

The interlanguage links selector should have a search box when the list is long and the needed language is not one of those that appear in the top box. The ULS search box already handles this nicely, including search for language name in any language. The code is modular and can be easily adapted for Winter. Amir E. Aharoni {{🌎🌍🌏}} 15:12, 14 July 2014 (UTC)

Interlanguage links 3: expand and collapse

It's very odd that the three dots that expand the full interlanguage links list are centered and the arrow that collapses it is right-aligned. This may have something to do with the fact that in Chrome the top of the list is aligned with the top of the arrow that collapses the list and in Firefox it begins further down. It should be fixed to work the same way, of course, but more importantly, the location of the collapse and expand triggers should be re-thought. Amir E. Aharoni {{🌎🌍🌏}} 15:20, 14 July 2014 (UTC)

Mobile only?

Sorry if this is too negative - but I have to say I dislike the core principle behind this concept: the forced narrow screen for the main text. Especially at larger screens (and with many pictures in-text), it comes off as clogged and makes me almost feel claustrophobic because stuff is being pushed in a small space unnecessarily. It is nice that there is a seperation between general content and templates & stuff, but I would prefer if you could find another way to accomplish that. 2001:981:8932:1:B5BA:249B:CDE3:71E3 (talk) 15:24, 14 July 2014 (UTC)

I have to say that this criticism is exactly right - that putting navigation templates on the right side is a huge mistake. That forces readers to scroll excessively for the longer articles - which are the ones that get more page views. And having no TOC (see above) exacerbates the problem. John Broughton (talk) 03:15, 22 July 2014 (UTC)

Interlanguage links 4: possible "more languages" label

I am not entirely sure that the three dots that expand the interlanguage list properly convey the idea that there are more languages. In the ULS compact links beta feature the user gets a further hint that there are more languages because there's a label that says "X more languages" (where X is a number). The users' response to this label in the testing has been pretty good, but of course more testing can have different results.

(Another possibility that I just thought about is to show a couple of more languages and fade the list out. I suppose that professional designers probably know the pros and cons of this and the possible solutions.) Amir E. Aharoni {{🌎🌍🌏}} 15:25, 14 July 2014 (UTC)

I asked Hebrew Wikipedia users for feedback and the first comment that somebody had was that he couldn't find Hebrew and didn't see where are more languages, so this is probably an area to give some thought. (And if Hebrew was auto-identified using geolocation, he wouldn't have to look.) Amir E. Aharoni {{🌎🌍🌏}} 16:38, 14 July 2014 (UTC)

Interlanguage links 5: try showing target article name

Last comment about interlanguage links for now: We should consider showing not just the language name but also the target article name. This is done in MobileFrontend, and I think that it's pretty good, but I don't have any actual user testing results that show how useful it is for other people.

The changelog for Winter 0.4 says that showing the article name was "a pain" because the info had to be in an API call. Is it only a technical problem then? IIRC that MobileFrontend prepares the article name list server-side. Amir E. Aharoni {{🌎🌍🌏}} 15:30, 14 July 2014 (UTC)

0.6 feedback

It looks good, but the addition of the right rail makes it really cluttered. Just my two cents. Apart from that, keep up the good work! Kangaroopowah 16:04, 14 July 2014 (UTC)

History: how to get diffs?

Very pretty, but when I clicked on "updated 13 days ago", I got to a history list without an easy way to find a diff between two versions. Without that tool, vandalism is much harder to fight. Did I just miss it? Slashme (talk) 18:02, 14 July 2014 (UTC)

Slashme: Since this is a prototype, there really isn't a way to do that. The focus was creating a "history" page that users can recognize as a history page. Going any further than that would be effort spent for little value (the major value is testing whether or not users understand what a "history" may be, not its exact workings - which may be food for a future test, but not in the near term). Jorm (WMF) (talk) 18:53, 14 July 2014 (UTC)

I don't understand. Are you saying that you're NOT going to provide a way of generating a diff from a history page? Because if you are saying that, you're proposing to remove a very important tool that experienced editors use whether an article has been vandalized or needs a closer look.

There may be an underlying presumption here - that most readers actually *care* about prior versions of an article. That's a *huge* presumption. My presumption is exactly the opposite - that readers care almost exclusively about the *current* version of the article. Experienced editors, on the other hand, are *quite* interested in prior versions. And - as I said - they need diffs. John Broughton (talk) 03:11, 22 July 2014 (UTC)

Page Title and Bullet Points

I would add the page title to the head element if possible. The display of just the URL is not very good looking.

Additionally the page Wikipedia:Microcephaly appears broken in Winter. The bullets on it appear all wrong. Zellfaze (talk) 18:46, 14 July 2014 (UTC)

ToC always visible?

If I understand correctly, in version 0.6 the ToC is hidden by default. People in hewiki complained about it, and I agree. Hiding the ToC in a clever way may make sense on small screens, but on a desktop screen it should probably be shown by default and not hidden under a button.

Jorm says in Talk:Winter/Archive_1: "There is a strong series of requests to retain it "in page" at its current location, no matter what, and uncollapsed (collapsing it reduces usefulness and requires a full click to open.)"

I agree that requiring a click to open reduces usefulness. Was there any decision to hide by default? I cannot find it. Amir E. Aharoni {{🌎🌍🌏}} 19:02, 14 July 2014 (UTC)

Amire80: It's an experiment. Mostly we're going to see how many people miss it and can't find it, and even notice that the in-page ToC is gone. Jorm (WMF) (talk) 19:04, 14 July 2014 (UTC)

Jorm (WMF): One !vote for having the TOC visible by default. It's useful when you land on a page to get some sense of the size, structure and detail an article has; often my first action is to click on a TOC heading. EdSaperia (talk) 18:37, 15 July 2014 (UTC)

The TOC should be visible by default. If you really believe that such a basic change is important, then I suggest a Request for Comments (RfC) at the English Wikipedia and a couple of other language versions. If someone really dislikes the TOC, they should be able to have it hidden via a preference (which assumes being a registered user, of course). John Broughton (talk) 03:07, 22 July 2014 (UTC)

Width browser window

Hello, I usually have my browser window not on the whole screen. Often I give it 50-70 % of the with of my screen, so that the lines are not too long or for having another window open. E.g. when writing articles I usually have something on one side of the screen and the Wikipedia page on the other. / With Winter, when I make my Wikipedia browser window half of the screen, then the article text is just one thin unreadable column. How can I change that? Ziko (talk) 19:07, 14 July 2014 (UTC)

Ziko: You're encountering a bug that I hope to fix within the next day or so. The problem is that the responsive design code was written independent of the right rail, and so it doesn't behave like it should. Jorm (WMF) (talk) 20:23, 14 July 2014 (UTC)

Ah, the problem is on the radar already. :-) Great. Ziko (talk) 20:34, 14 July 2014 (UTC)

Customising colours, fonts?

Has there been considered to give (logged-in) users the chance to change background and font colours, standard font etc.? Ziko (talk) 19:15, 14 July 2014 (UTC)

Headings design

A Hebrew Wikipedia user complained that it's hard to discern the different heading levels in the Winter view. In Vector and Monobook h2 headings have a line below, which makes them clearly different from h3 and h4. There is also a significant difference in font size: h2 is 21px and h3 is 16px.

In Winter 0.6 there is no horizontal line, and the size is closer: h2 is 25px is h3 is 21px. Amir E. Aharoni {{🌎🌍🌏}} 19:16, 14 July 2014 (UTC)

Discussion / talk

Has there never come up a problem with the difference of these two terms? On the article page, the other page is referred to as "discussion", while that page itself is called "talk:" Ziko (talk) 19:20, 14 July 2014 (UTC)

Ziko: Yes, actually. This is something I'm fairly concerned about. We're using "Discussions" because we're looking at individual discussions on the talk page in this context. In the future, with Flow, that will become even more confusing.

When Vector was first rolled out, the word "Talk" was replaced with "Discussion", and this became a problem because so many templates said things like "Leave a note on the talk page". The English Wikipedia changed it back to "Talk" because of this. Jorm (WMF) (talk) 20:21, 14 July 2014 (UTC)

Oh, I didn't know that. Thanks. Actually, it seems that it did not come up in the tests with the test persons... maybe it is less a problem than I would think. - I was not surprised about the reaction of one of the testers regarding the difference between "article talk" and "my talk". "My user talk" might be clearer. I remember that in German "My contributions" had been changed to "One's own contributions". Ziko (talk) 20:32, 14 July 2014 (UTC)

"Updated 7 days ago"

The article "Summer" has a little clock with the remark "updated 7 days ago". This sounds as if the article has been updated (= made up-to-date) recently, but the real meaning is that it has been edited 7 days ago?

"Updated" sounds as if someone skilled has checked the whole article and updated recent events, numbers etc. Ziko (talk) 19:25, 14 July 2014 (UTC)

Ziko: That's a good point, and a great suggestion. "Edited X days ago" sounds better. I suspect there might be some concern about things like "is template insertion actual editing" and the like but I think the distinction is minimal. Jorm (WMF) (talk) 20:20, 14 July 2014 (UTC)

Hm. "Last change made X days ago"? Ziko (talk) 20:33, 14 July 2014 (UTC)

Comments to 0.6

I haven't read the other posted comments, so bear with me if I repeat them :P

• - The right bar should be easily collapsible (directly, i.e. with a little button that does the job, like in [1]).
• - In the languages list, most popular languages (or languages selected by the user via Config) should be shown first.
• - Both the article headline and the top bar of the page look great :) However...
• - ... I'm not friend of useless, repeated links. Sometimes they are just confusing. The little menu next to the search bar (left side) shows the same links than the article headline (article, edit, discussion, history). The "user menu" (right of the search bar) shows 4 repeated links that are just next to it (userpage, user talk, watchlist, notifications). I'd suggest to remove the links in the menus (as the other ones are faster to click and look good).

[1] http://web2py-instant-admin.readthedocs.org/en/latest/_images/sidebar.png Racso (talk) 22:09, 14 July 2014 (UTC)

Bug report (rendering - footer top sometime too high)

it seems there's a problem in calculating the (vertical) location "end of page, that causes pages with long template on right-hand side and shorter content to place the footer too high, obstructing part of the template. (you may need to play a bit with browser width to find a width where the problem is obvious).

see http://unicorn.wmflabs.org/winter/index.html?page=Phyprosopus%20callitrichoides

peace. קיפודנחש (talk) 05:09, 15 July 2014 (UTC)

separators in sidebar

The good old "|" separators look a little - crass IMO (example:Winter). How about this instead:

$('#wsidebar table.vertical-navbox li').css({'border-right':'2px solid #DDD','margin-right':'2px'}) Magnus Manske (talk) 18:19, 15 July 2014 (UTC)

Magnus Manske: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. Jorm (WMF) (talk) 19:33, 15 July 2014 (UTC)

Not working for me

http://unicorn.wmflabs.org/winter/ says that I must enter a username, even though I've put a name (many names, many times) in the username box. I'm running Safari 6.1.4 on Mac OS 10.8.5. Whatamidoing (WMF) (talk) 18:54, 15 July 2014 (UTC)

Whatamidoing (WMF): Are you unchecking the "save for next time" thing? I just fixed a bug with that, but I'd recommend not unchecking it. Jorm (WMF) (talk) 19:32, 15 July 2014 (UTC)

Yes, I was. That must have been the problem. I'll try again later. Whatamidoing (WMF) (talk) 23:07, 15 July 2014 (UTC)

Language box

So does the language box at the top need to be so prominent? Surely thats something that the user is unlikely to change very often, if at all. As so, why is it right at the top of the sidebar? CaptainPedge (talk) 19:09, 15 July 2014 (UTC)

CaptainPedge: 70% of our user base is multilingual (with 30% speaking three or more languages). The multi-lingual facet of the projects is arguably the most important feature of the entire encyclopedia.

We're experimenting with various language selection designs and this is just one of them. The reason the language selector is so prominent is that you need to be able to find it if you accidentally end up on a page in a language you do not speak or recognize anything from - specifically things with non-latin scripts, in many cases.

I'm working on a test harness that will allow us to replace everything with Russian, which is a good way to see if English speakers can find out how to get to their own language. Jorm (WMF) (talk) 19:31, 15 July 2014 (UTC)

CaptainPedge: I have to second this thought. When consuming wiki content (Wikipedia or 3rd party) changing the language is low on my activity radar. Full disclosure. I'm an English native and have never edited or visited other language-versions of pages.

Besides this, I really like the direction of this project. Ckoerner (talk) 20:39, 15 July 2014 (UTC)

VisualEditor

Where does VisualEditor fall into this demo? I'm a little surprised that the toolbar is very similar to, but not the same as VisualEditor. I was actually expecting the non-wikitext interface to load (yes, I know it's a demo!)

Aren't both initiatives from WMF? It's seems incongruous to have two very large, very impactful projects diverge in such a manner. Ckoerner (talk) 20:42, 15 July 2014 (UTC)

Ckoerner: The editor designs in Winter are the current thinking of where both of our editors should be heading. Jorm (WMF) (talk) 05:52, 16 July 2014 (UTC)

Jorm (WMF): Ah, that makes sense. You all are doing yeoman’s work! Ckoerner (talk) 14:24, 16 July 2014 (UTC)

Screen width

http://i.imgur.com/8TkkQLP.png - Need I say more? CaptainPedge (talk) 21:03, 15 July 2014 (UTC)

CaptainPedge: I just now - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. Jorm (WMF) (talk) 21:10, 15 July 2014 (UTC)

Jorm (WMF): Fair enough :)

What about the whitespace underneath the right hand sidebar? CaptainPedge (talk) 21:19, 15 July 2014 (UTC)

CaptainPedge: I'll have to take a look. I'm not seeing it at my current configuration. Jorm (WMF) (talk) 21:20, 15 July 2014 (UTC)

Jorm (WMF): http://i.imgur.com/hLaaZp0.png CaptainPedge (talk) 21:40, 15 July 2014 (UTC)

CaptainPedge: OH! That is actually intended. It will (eventually) start being filled with other tools and methods for surfacing additional content related to the article you're viewing, plus additional mechanisms for contribution.

I just haven't written them or faked them up yet.

Things like gallery browsers, or discussion stubs, or a list of popular quotations, or whatever. Jorm (WMF) (talk) 21:42, 15 July 2014 (UTC)

Jorm (WMF): 2 things:

1. Is the plan to expand the body of the article underneath the sidebar, like the current design expands beneath the infobox, or is the whitespace there to stay?

2. Its amazing that you're being this responsive and it is very much appreciated :) CaptainPedge (talk) 21:47, 15 July 2014 (UTC)

CaptainPedge: Ideally, we'd like to fill it with useful things, and we'd also like to move away from a lot of the current re-flow problems the current layouts encounter. If you look at the current site, there are sometimes places where huge swaths of "null content" exist that, by virtue of the content engine's design, are not usable. Consider the space next to most Tables of Contents.

And thanks for your appreciation! Getting comments is how I find bugs in the design, and the best way to get them is to be responsive. I'm locked out of the Boingboing thread, though, so that sucks. Jorm (WMF) (talk) 21:53, 15 July 2014 (UTC)

Jorm (WMF): I just feel that on a long article, youre just gonna end up with a long column of whitespace that could be used. Oh one more thing, I don't know if this is just me, or if it's something the bothers other people. but I prefer when everything on the page scrolls the same way, and you don't end up with like top-bars that hang off the top of the window (not that it's happening here, but I just thought I should make the point) In my experience those sorts of thing only end up bugging out in some way and screwing the whole thing up. CaptainPedge (talk) 22:02, 15 July 2014 (UTC)

CaptainPedge: Winter does look a lot better when looking at a specific article, like say Scotland as an example. That right bar doesn't appear as awkward.

Jorm (WMF) That might be something to think about when sharing Winter with more people - don't lead with the Main Page or other visually 'empty' pages as examples. It wasn't until I dug into a few pages that I figured out what was going on. Ckoerner (talk) 15:50, 17 July 2014 (UTC)

Ckoerner: Sorry, I'm still not buying it. Look at http://unicorn.wmflabs.org/winter/index.html?page=Les_Mis%C3%A9rables_(musical) compared to https://en.wikipedia.org/wiki/Les_Mis%C3%A9rables_(musical). As soon as you get past the info box at the top the rest of the text flows into the space below, filling the screen. On the new proposal, there's nothing there, just wasted space, requiring me to scroll further to get to the bottom of the page, and squashing tables to comedy levels. CaptainPedge (talk) 02:45, 24 July 2014 (UTC)

CaptainPedge: Good example! Ckoerner (talk) 21:35, 25 July 2014 (UTC)

I hate the logo in the top left corner

When I scroll down, the Wikipedia globe covers up what I want to read. If you're going to keep something for "branding" (which is IMO unnecessary) then it needs to be much smaller and maybe horizontal (perhaps just the "Wikipedia" text?). Floating logos shouldn't interfere with viewing content. Whatamidoing (WMF) (talk) 02:03, 16 July 2014 (UTC)

Whatamidoing (WMF): That is not the behavior that should happen. The logo should literally turn only to the wordmark.

Can I get a screenshot? Jorm (WMF) (talk) 03:01, 16 July 2014 (UTC)

Jorm (WMF): Sadly, no: I thought about grabbing one last night, and then decided that since it was intentional, it would be unnecessary. (I should know better.) However, if you check your e-mail, you'll see a related screenshot. Whatamidoing (WMF) (talk) 17:12, 16 July 2014 (UTC)

Widescreen

Played with CSS on a wide screen, and for >1600px, this makes a reasonable hack of a ~960px central column: $('#container').css({'max-width':'1550px','margin-left':'auto','margin-right':'auto'}) Magnus Manske (talk) 15:48, 16 July 2014 (UTC)

Why not taking existing concepts from designers?

It may be a little awkward but why not take finished concepts from professional designers with measurable feedback like these:

http://wikipedia.gkvasnikov.com/

http://www.wikipediaredefined.com/ Julian Claus (talk) 15:34, 17 July 2014 (UTC)

Julian Claus: Pretty much what Ckoerner said below. For instance, both the examples you posted downplay or even ignore the multi-lingual facet of the site, which is arguably its most important feature. Jorm (WMF) (talk) 18:19, 17 July 2014 (UTC)

Julian Claus: I've wondered this for most of the design projects I have participated in. And there are at least a few individual ideas in each of those designs that I find wonderful. But it is a major shift in social norms and practice to switch from the idea of designing your own solution to curating and combining solutions offered by others. In my experience it is rare to find people and fields where the latter is the norm -- while it has happened with some scientists, coders, and writers, I have yet to see it happen with design.

Ckoerner: some of those designs turn out to be excellent. Cf. user innovation in general and a certain cool cooler in particular ;)

Jorm (WMF): you're right about licensing, and one could ask those designers for an acceptable reuse license if they have any good ideas worth incorporating. Sj (talk) 22:16, 1 September 2014 (UTC)

I can't speak for WMF, but as someone who has designed systems, it's never as easy do approach it from the outside (like these designers have) without multiple, deep, conversations with those who manage a product. In my experience it's more beneficial (faster, better end result, more thought out in edge cases) to have a dedicated team - with years of experience with the 'product' - learning, developing, and evolving the interface and experiences.

I could show an automaker a great concept for a car, with all the features I'd love, but then we'd end up with The Homer. Ckoerner (talk) 15:45, 17 July 2014 (UTC)

There's another aspect to this, by the way: most of those redesigns do not include licensing that would allow us to reuse the ideas. Jorm (WMF) (talk) 21:29, 22 July 2014 (UTC)

Echo's icon and number are misaligned

It seems the bell icon (for Echo) and the number that shows the number of new messages are misaligned with each other. I'm running on Chrome OS 35 with a 1024x600 display. Thanks. -24^Talk 23:55, 17 July 2014 (UTC)

Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f Sven Manguard (talk) 18:31, 21 July 2014 (UTC)

Thanks! I'll see about getting a fix for this in soonish. Jorm (WMF) (talk) 21:29, 22 July 2014 (UTC)

General feedback, a bug, and a complaint about an icon

Hey, awesome to see how this is coming along.

I'm torn about putting all of the infoboxes off to the right. On the on hand, it seems useful as a way of getting information to people efficiently. On the other hand, having a thin link bar on the left and a much thicker infobox bar on the right throws the balance of the page off, and makes all of the text and images feel kind of squished in the center. As was said below, a way to collapse that bar (and have the text spread back out into that space) would be nice. I think it should default to having the bar open each time you go to a page, though (i.e. if I go to autumn, collapse the bar, go to summer, and then go back to autumn, the bar should be expanded again).

I went to the page en:And Yet It Moves, and noticed that the Reception template (the one that details the review scores) has been moved to the right. The word "Reception", however, is still where the template was originally, and is surrounded by a whitespace gap. This might be because that word is part of the trigger to collapse the table down.

On the plus side, I actually went to that page to check on how Winter handled en:Template:multiple image, and it looks awesome. It was rapidly becoming one of my favorite toys before, and Winter will only make me want to use it more.

Lastly, I wanted to suggest that you use a circle with a plus in it, instead of a star, for indicating Good Articles in the box up at the top of the right bar (And Yet It Moves has one). Stars are the domain of Featured content (articles, pictures, portals, and topics), and I'd rather not use them for Good Articles because there can be a pretty sizable quality gap between GAs and FAs. Sven Manguard (talk) 18:22, 21 July 2014 (UTC)

Sven Manguard: The icon for "Good" articles is only the star because I didn't have time to create a new one. I just cloned the code that handles "Featured". We'll have different icons. Jorm (WMF) (talk) 21:28, 22 July 2014 (UTC)

margins etc.

Hi.

   I suggest to use margins in percentage, not fix, so you get more air, esp. on bigger screens. And don't use centered tags in the sidebar. I mean don't use it anywhere. 
   Provide larger vertical top-margins in the sidebar for headlines, so you get your structure more visible.

And you should keep the text together with a max-width of the main-div, so you get no more than about 75 letters in one line. This is for readability reasons.

  Don' be afraid of "wasting" space. Let it breathe!

Thx for reading. 62.216.204.25 (talk) 23:50, 21 July 2014 (UTC)

About 75-80 letters per line is about 36-40em with most common fonts (excluding those in narrow and wide styles or old legacy fonts with incorrect metrics made for some South-East Asian Indic scripts or decorative designs).

Ideally all pages should avoid creating text columns narrower than 12em or larger than 50em (when it includes left or right floating elements which should be about 240px wide for images and never more than 50% of the page width between margins).

Ideally,pages should still be able to adapt themselves to wide screens (to avoid wasting it) by using columns. But if multicolumns are used, the paragraphs should not exceed about 40 lines and with colmun width set to 36em for about 75 letters and 2 columns, this means blocks of text about 6000 letters; (avoid this, you shold create subsections) ; with list of simple names (not sentences) such as toponyms, the ideal column width is about 18em, and you should avoid groupng in the same section two lists that exeed about 200 items.

Once the width of columns is determined, it remains easy to adjist the side margins to "auto" (instead of 0).

But be careful: these widths in ems are only valid for the main content (or for smaller texts sch as lists of referneces). Heading generally use bigger fonts and should continue spanning across text columns for heading levels 1 to 3 by putting them outside the multilcumn layout in a general page content of about 50em.

Don't set excessive margins and avoid builing portals with too many columns that can't fit (it is really hard to fit more than 2 columns or just 1 columns wth elements floating only on side; don't use floatting elements on both sides ! unless they are thumnailed images each with width lower than 150px). Verdy p (talk) 23:41, 25 July 2014 (UTC)

About Typography refresh (Snowflakes)

I am Japanese Wiki user. Is it possible to change Snowflakes module of "Typography Refresh" every language? Setting of "font-family: Georgia, serif" causes some problems for a non-Latin user. See Talk:Typography refresh/Archive 4#Languages problems. Wolf359borg (talk) 22:59, 22 July 2014 (UTC)

Wolf359borg: Are you seeing these issues if you switch to a Japanese-language article from within the prototype?

I can easily disable the refresh for any specific language; it just gets complicated when I try to do it piecemeal. I'll probably just disable it for all languages except en. Jorm (WMF) (talk) 21:45, 27 August 2014 (UTC)

Editor Feedback

IMO, the edit toolbar (Bold, Italics, Underline) should be underneath the toolbar that has read, edit, history, etc. on it because it doesn't make sense for something thats secondary to a certain function on one toolbar (in this case edit), to be above the original toolbar. Kangaroopowah 18:42, 23 July 2014 (UTC)

Languages and meta-info in smaller screens

I like a lot the right column with the language and meta-info links. I also like the fact that it goes away if/when the screen is smaller (and if it's small enough the left column goes away as well, very cool). However, where can the user of smaller screens find the vanished content? Maybe we could have a slider button in the edges allowing the user to pull that content? Qgil-WMF (talk) 10:12, 24 July 2014 (UTC)

The File namespace (formerly "Problems following files with an !")

I went to the page http://unicorn.wmflabs.org/winter/index.html?page=Blanc_de_Hotot and tried to click on the image. Instead of opening up the image in a new page, as clicking on images had done with other images, clicking on that image gave me a 404 error. I think it might be because the ! threw something off. Not sure if this is a Winter error or a Labs error. Sven Manguard (talk) 18:21, 30 July 2014 (UTC)

Sven Manguard: It's actually the File: namespace. I haven't built in support for handling File:urls. The API is fairly opaque with regards to those. Jorm (WMF) (talk) 18:40, 30 July 2014 (UTC)

Jorm (WMF): Ah. If you're not set on your design for the file namespace, I have some ideas. I'm going to go off and build a mock up, and will post it when I'm done. Sven Manguard (talk) 19:25, 30 July 2014 (UTC)

Jorm (WMF): My file namespace ideas are at File:Winter file namespace ideas.png

I'd love to hear your thoughts, especially on the "human readable" license to the right.

Edit: I didn't put it in the mock up, but all of the templates and history that appear below the image in the current version of the file namespace I don't have any ideas for at the moment. The "human readable" license to the right wouldn't replace the one below the image, especially as the "human readable" license will probably not work for really complicated licenses, personalized licenses, or OTRS tickets. Sven Manguard (talk) 20:54, 30 July 2014 (UTC)

Is Winter not in BetaFeatures anymore?

Winter is apart of VectorBeta and not BetaFeatures.

I just did a copy of BetaFeatures master branch and found out that I couldn't enable Winter by adding $wgVectorBetaWinter = true;. I also noticed that all the documentation about the beta features included in BetaFeatures were removed from Extension:BetaFeatures. When was this changed and what can I do to get back Winter? -24^Talk 23:04, 4 August 2014 (UTC)

I would also like to see this in beta features. Gryllida 08:03, 10 August 2014 (UTC)

Thought I already left such request somewhere. Don't see it. Gryllida 08:04, 10 August 2014 (UTC)

I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. -24^Talk 13:08, 10 August 2014 (UTC)

Someone said "Winter is apart of VectorBeta and not BetaFeatures.". I don't see who.

Can we have VectorBeta be listed in Beta Features please? Gryllida 01:43, 11 August 2014 (UTC)

And can we please stop closing topics aggressively? Topics need to stay open, unless inactive (for instance, for a week).

No past discussion system locked topics like this. It should not even be technically possible.

Most users will be unable to even re-open the topic, the button is not easy to find.

(I would be happy to dedicate a sub-topic to this question, but this system doesn't let me make subsections here with the expected consequences (a separate discussion, etc). Filed bug bug 69383. about subsections.) Gryllida 01:45, 11 August 2014 (UTC)

I, the original poster, closed the topic because the matter of this one topic was resolved. It is good practice to close topics that have been resolved and if a participant thinks that a discussion should be reactivated then they can reactivate it by replying with the usual method and Flow will take care of the rest. The close topic is used to close a discussion about a particular matter. If something else comes up then a new post should be posted not sub posted in an existing topic. The close topic feature was implemented so that talk pages wouldn't become clogged by old discussions without needing an archive bot. If you wish to pursue this you should do so on Extension Talk:Flow, not here. This page is about Winter not Flow. -24^Talk 02:48, 11 August 2014 (UTC)

By the way, it is very obvious who closed the topic. It is displayed prominently at the top of the topic header as "This topic was closed by Negative24" and it seems that replying doesn't un-close a topic. That must have just been changed but once again dispute this on Extension talk:Flow. -24^Talk 02:51, 11 August 2014 (UTC)

Images in right rail

Is it part of the plan to put images in the right rail? I think that'd be nice; it would make use of the empty space and declutter the body text. Ypna (talk) 10:43, 12 August 2014 (UTC)

JamesDouch: Yes, there are thoughts about it. It's more likely that we will insert galleries rather than images straight up. In-page images usually require the context of the article for usefulness. Jorm (WMF) (talk) 00:29, 13 August 2014 (UTC)

One small thing...

If I go to http://unicorn.wmflabs.org/winter/index.html?page=H%C3%A5kan_Juholt I can see the article, but if I search for "Håkan Juholt" (without the " " ) and press it in the list, is shows nothing, but a white screen. Josve05a (talk) 02:25, 13 August 2014 (UTC)

Josve05a: Probably a bug in the way the prototype handles the JSON queries for the search suggestions. It won't happen in the production instance, though. Jorm (WMF) (talk) 21:43, 27 August 2014 (UTC)

The sidebar hiding doesn't work good.

If I want to re-show it, I have to be fast and hover over the Wikipedia puzzle ball, then click on "show" before the sidebar is gone again. Also, editing, in a monospace font, please. Mountainhead (talk) 19:09, 14 August 2014 (UTC)

WOLF LΔMBERT: Yeah; I'm not a fan of how this behaves at all. I honestly think this is a bit of a failed idea. It's an interesting thought - remove all the clutter - but I don't wonder if it's too much. Jorm (WMF) (talk) 21:42, 27 August 2014 (UTC)

Seconding the monospace font for the edit box. Editing in a proportional font is painful. Scott5114 (talk) 07:10, 15 August 2014 (UTC)

Scott5114: You know what's weird? The font is proportional for me using the stock editor on a stock account instance. I'm not sure when that changed, or if I even noticed it. Jorm (WMF) (talk) 21:42, 27 August 2014 (UTC)

Jorm (WMF): Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. Scott5114 (talk) 20:05, 28 August 2014 (UTC)

Indeed; it might be good for newbies but I really don't like it. And I'm not going to use the VE, I'm too used to wikitext. So please. Mountainhead (talk) 14:16, 17 August 2014 (UTC)

Winter breaks some infobox applications

On the English Wikipedia's highway articles, we have some mini-infoboxes that serve as an infobox for a specific subsection of the article. Winter breaks pages making use of these by shoving all of these infoboxes to the right rail area. Compare https://en.wikipedia.org/wiki/Bannered_routes_of_U.S._Route_60 under Vector with http://unicorn.wmflabs.org/winter/index.html?page=Bannered%20routes%20of%20U.S.%20Route%2060 —note how the infoboxes no longer line up with the content they illustrate. Scott5114 (talk) 07:09, 15 August 2014 (UTC)

This is also an issue in other applications where the smaller infobox for a related road or highway appears in a section. For example, look at http://unicorn.wmflabs.org/winter/index.html?page=M-553_(Michigan_highway) compared to https://en.wikipedia.org/wiki/M-553_(Michigan_highway) . There is the mini infobox for County Road 553, which is the immediate predecessor to M-553, that is located in the history section. Further down, there is a mini infobox for M-554, a highway whose history is intimately related to M-553 and CR 553. These are also slid over into the right rail and shoved to the top of the article, disconnecting them from the content they reference. Imzadi1979 (talk) 05:39, 18 August 2014 (UTC)

Navboxes and categories

Are these being removed? Michigan State Trunkline Highway System should have a navbox below the items in the bulleted list in the External links section, yet the box is missing.

Also, how are categories going to be displayed since they don't appear at the bottom of the articles. Imzadi1979 (talk) 14:17, 15 August 2014 (UTC)

Imzadi1979: Some things are not displayed simply because they display buggy out of the gate and I haven't had a chance to clean up the css for them. Jorm (WMF) (talk) 00:30, 16 August 2014 (UTC)

Infoboxes that are longer than the article text

In many shorter articles such as this one, the infobox is longer than the article text. The gray bar at the bottom of the page still appears at the end of the article text, though, so it obscures part of the infobox. TheCatalyst31 (talk) 03:07, 16 August 2014 (UTC)

TheCatalyst31: This is listed on the main page as one of the known issues. Below it, it says "This only affects the prototype; it's part of the way it is constructed." Ypna (talk) 10:23, 17 August 2014 (UTC)

TheCatalyst31: I'm just going to echo what JamesDouch said. It's a prototype-only bug. Jorm (WMF) (talk) 21:40, 27 August 2014 (UTC)

Table of contents icon

The icon indicating the table of contents (now located up to the left of the search box) looks the same whether or not the article currently being viewed is a 1-line stub, or a very long article. In the current WP interface, the table of contents automatically appears when there is a few sub-sections in the article. Now in 'Winter' it looks the same either way. I think this would be confusing to many people (even when they get over the initial shock of the ToC disappearing from where they're used to it. I would personally like to see if more visible than you've currently got it, but at least make a visual differentiation between when there IS and ISN'T a ToC to show. Wittylama (talk) 15:57, 17 August 2014 (UTC)

Wittylama: We are actively looking at this specific part of the interface. We agree that the icon isn't sufficient (and testing has shown that with actual data).

There are a couple ways we can move on this, including but not limited to:

• Changing the icon to something more meaningful;
• Modifying the icon based on the content it includes;
• Applying a "bounce" effect on the menu (or something similar) to aid in discoverabilty;
• Removing the in-header Table of Contents altogether;

We'll probably start with the bounce thing and see what that gets us. Jorm (WMF) (talk) 21:40, 27 August 2014 (UTC)

Search bar inconsistent wording

• changning text on hover is really strange
• why change placeholder text to page's title? That's really confusing. I initially thought that this would change search from global to inside article (was rightly expecting global search though) The intention was probably to keep the page's title visible, but that's certainly not the way to go. Lazowik (talk) 18:06, 20 August 2014 (UTC)

Fonts

I don't like the default font. Is there a simple way to change it to a serif font, or will I need to edit the related javascript files? Llywrch (talk) 17:01, 3 September 2014 (UTC)

Llywrch: You'll have to make changes in your personal css, I'm afraid. While I think many people can agree that serif fonts are subjectively "prettier" for display and reading, there are design constraints involved with font selection.

For users who have dyslexia, large text blocks of serif fonts can be extremely difficult to read (they create "gutters" in the text). (There are also issues involving people who have certain forms of macular degeneration where this can occur, too).

Accordingly, for accessibility's sake, we must stick with sans-serif fonts for blocks of text. Jorm (WMF) (talk) 20:25, 3 September 2014 (UTC)

Some confusing things

In my opinion the Idea oft winter is good, but there are some things which are a little bit confusing:

1. The Design: It seems to be mixture of the actual vector surface and the mobile surface, two totaly different things which doesn't fit together. It has no clear structure, because there are three different kind of things to klick on. In the Personal Toolbar you have grey icons; in the toolbar on the top of the articletext you have a bold text with icons; below the wikiglobe you have "normal" links like in vector.
2. The dropdownmenus and the toolbars: The personal toolbar contains all points which are also part of the dropdownmenu, why? Same question for the dropdownmenu next to the wikipedialogo, which contains all features of the toolbar on the top of the articletext. In my opinion you should use either a toolbar or a dropdownmenu.
3. The Table of Content: it is a part of the article, so it should be visible on its normal position and not hidden in a dropdownmenu.
4. The searchbar: It is too large for the desktop version.
5. The right colum: If you have an article without infobox and Commons-Template (e.g. the german version of the winter, the colum is nearly empty and wastes much space on the screen especially on small screens. In my opinion it would be better to remove the collum an put the interwikis into the left collum, the infobox into the text area (like in vector) and the Commons-Template below the infobox, because the Article itself is the most important thing and should get as many space as possible.
6. The technik behind the surface: if JS was turned off, it is impossible to read the article, because you don't see it. In my opinion the text must be readable without js, because there are people who disamble js or they use computers where js is blocked for security reasons. Because of this, there should be a textbox which says "you should enamble Javascript to see the full layout and use all tools" on the top of a readable version of the article itselft.
7. the layout of the headlines: there should be a line below the headline like in the vector skin, because without this line you don't see where a main-section starts and ends, because all headlines nearly look the same.
8. the history page: there must be a possibility to visit the diff-pages, because without this possibility the history-page looses much of its sense.
9. the backgroundcolors: the background is completely white, only the background of the right colum is grey. Why? In my opinion there should be a clear difference between the article text background and the background of the rest of the page like in vector, so that the reader can see this is the article and this is the other stuff around the article, which is not a part of the article.
10. the top bar which you see all the time: in my opinion this bar wastes much space, if you have a small display, so its better to remove the bar or give a possibility to fix the bar on the top of the article.
11. hover-effects: they should be removed, because they don't work on a touchscreen and especially the hover-effect in the searchbar is very confusing.
12. hiding things in dropdownmenus: in my opinion all links should be visible like in vector. Only buttons which are less important like move, delete or protect should be hidden in a dropdownmenu, if there is not enough space on the screen.
13. the "more"-button in the toolbar on the top of the article (bug?): it behaves strange, because the box around the text, which apears, when you move the mouse over the button, ends around the "r" of "more" and does not include the arrow next to the text.

I think these are all things, which are confusing for me. Patrick Stützel (talk) 17:19, 5 September 2014 (UTC)

First impressions

I've just discovered the prototype, and I want to write down my first impressions before any other rational analysis:

• I miss Wikipedia puzzle-ball logo. I've later discovered that it can be seen by zooming out to 90%, but the first gut feeling was one of a void, bare, unadorned page, not aesthetically pleasing. Recovering the left column with the logo made that impression go away.
• I love the clean, modern design, new layout for tools and navigation, and the right sidebar with useful, contextual tools! Good work.

Accessed on chrome browser on Windows 7. Diego Moya (talk) 12:23, 8 September 2014 (UTC)

Ok, I have now seen that the design is reactive and the left panel is shown with the window maximized, as well as the labels for buttons.

I have found a big no-no, a showstopper that would make me avoid using this interface in its entirety: none of the new interface buttons work as standard links with respect to the context menu and the "open link in new tab" option. As my navigation style involves opening lots of links at new tabs and accessing them later, I couldn't use this skin except by:

• copying the url,
• manually opening a new tab,
• pasting and loading the url,
• only then navigating to the target section,
• repating the above for each link I want to open.

I usually do all that in quick succession with fast middle-clicks on several links, so this interface makes my usual workflow slow as molasses. Diego Moya (talk) 15:58, 8 September 2014 (UTC)

Hrm. They *should* open in new tabs. You are referring to the links below the title (read/edit/history/etc.) ? I'll have to take a look at it.

Either way, this is not something that the production version will encounter. Jorm (WMF) (talk) 18:27, 8 September 2014 (UTC)

I should probably explain why the production version won't encounter it: the prototype isn't built on top of MediaWiki and is instead scrubbed entirely "in ram" from Javascript. That means that the links actually don't do anything when they first load, and have to have their actions connected after the fact.

Real MediaWiki installs won't have this problem. Jorm (WMF) (talk) 18:30, 8 September 2014 (UTC)

Yes, I was referring to those buttons. They appear as plain text button elements to the context menu, so the "open link in new tab" option is missing.

As these are navigation actions, and not POST forms, it would be best to make them links so that they work as expected for default browser operations (copying the target URL to the clipboard, opening in new tabs, "save target as...") Diego Moya (talk) 09:28, 9 September 2014 (UTC)

Have you seen WikiWand?

Hi. I wonder if you have checked out WikiWand, which does something very similar to Winter. It could be interesting to see what features they've implemented and how relevant they could be to Winter.

http://www.wikiwand.com/

What's interesting is that the website claims to increase Wikipedia load speed by 3 times, which is astonishingly fast. I wonder if the Winter team could look into what makes Wikiwand faster, and maybe implement something along similar lines to increase speed as well. Soni (talk) 05:58, 14 September 2014 (UTC)

Yup, WikiWand is well known (well-sold? :p ) and all possible questions have been probably answered. Imho the greatest difference between WikiWand and Winter is its target: Winter team works for contributors and readers when WikiWand team seems to underestimate "Edit" button (are they aware of the existence of our community?). This fact excludes WikiWand from further discussion. Moreover, projects that aim to modernise MediaWiki interface are numerous (I think there was an analysis of them!). WikiWand wants to be known as the most 'trendy', 'cool' etc. WMF staff was improving MediaWiki design before it was cool :p Tar Lócesilion (queta) 16:54, 14 September 2014 (UTC)

Weird Sidebar Behavior

Has anybody noticed that the sidebar looks kind of weird if you scroll away from the top of the page after hiding the sidebar and then showing it again? I like how this makes the sidebar come with you as you scroll, but shouldn't its formatting remain the same as that which it takes on when you're at the top of the page after you've scrolled away from there? RandomDSdevel (talk) 20:24, 11 October 2014 (UTC)

On the Behavior of Wikipedia's Logo in Winter

I don't really like it that Wikipedia's logo disappears from Winter when you scroll past it. I understand that the idea is to make the prototype's navigational tools take up less space, but couldn't that be achieved just as well by having the Wikipedia logo shrink and move to the left of Wikipedia's name and slogan? RandomDSdevel (talk) 20:27, 11 October 2014 (UTC)

You mean switch from the main logo to the horizontal logo shown above? That could work, but we'd need to go and create each of the hundreds of horizontal logos as we've not used it widely. Also, as has been widely observed before, the logo isn't very good as a logo and at small scale like this is very indistinct; using just the word mark is I think preferable. Jdforrester (WMF) (talk) 18:52, 14 October 2014 (UTC)

Hmm…you're probably right in saying that creating so many horizontal labels (they're for the various languages in which Wikipedia is available, right?) would take a lot of work, but do you have an estimate as to how much work it would actually take? And maybe having the icon in the horizontal version of the logo could be optional and/or experimental? RandomDSdevel (talk) 01:01, 9 November 2014 (UTC)

It took a concerted effort over a couple of years to re-create all the different language versions of the vertical logo after the Wikipedia logo changed in 2007 (I believe the effort started in 2009 and was declared "mostly done" in 2011). Creating them from scratch rather than needing to also drop them into place and thus negotiate with a community will make it faster, but… Mostly, this is a question of "who will do this?" rather than "how much work is it?" I feel. Jdforrester (WMF) (talk) 10:54, 10 November 2014 (UTC)

Why would creating a bunch of new, but differently sized, image files from ones that currently exist be so hard? Do the logos' image files already have their text embedded within them? That would certainly complicate things, I suppose. The text within the images would probably have to be redesigned for use in a vertical layout language by language…man, this would be so much easier if the logo text was just part of Wikipedia's general page layout (either as a separate image or as actual text,) wouldn't it? I'd help, but I don't really have that good of grasp of all the issues, let alone of how to use image-editing tools. This stinks… RandomDSdevel (talk) 23:43, 11 December 2014 (UTC)

Sadly, yes, the bespoke existing images each have localised text embedded inside the images. It'll need re-laying and possibly re-thinking in some cases. :-( Jdforrester (WMF) (talk) 03:44, 12 December 2014 (UTC)

Well, curse our luck! Would the powers that be possibly consider separating this text out like I suggested above? Like I said before, that would make work on this issue so much easier! RandomDSdevel (talk) 00:28, 16 December 2014 (UTC)

Improved or Different Header Views?

I kind of like it when an article's title replaces the search prompt in Winter right now, but shouldn't the 'Watch Article' star come along for the ride? I also understand how confusing this mechanic can be for people who haven't read up on Winter before test-driving it, so maybe the search bar and the 'article name' bar could be separated but remain side by side? If that were to happen, I'd like to see the 'article views and actions' bar currently residing underneath article titles be merged into this 'article name' bar. Maybe the toolbar could contain, in order, the 'Pin to watchlist' star, a pop-up menu from which you could select either 'Read' or 'Edit,' a pop-up menu from which you could select either 'the article on' or 'discussion about,' the current article's name, an article history button, the 'More' pop-up menu currently at the end of the present 'article views and actions' bar, the search bar, and then, finally, Winter's implementation of the Compact Personal Bar. Or maybe the search bar could still be accessible through a field containing articles' names, but it should just be pointed out to users more obviously that clicking on an article's name would allow them to switch to other articles? Could Winter's search functionality's 'magnifying glass' icon be dimmed? Or could something else differentiate the top bar's functionality for displaying article names and for displaying search terms? Maybe this set of ideas, especially the one about the combined navigation bar, isn't such a good one, though? Should users just have the ability to dock the 'article views and actions' toolbar to the bottom of the main one to create a two-tiered toolbar like the one that already exists in Vector? Perhaps these aren't the best ways to propose how to make Winter's toolbar more useable, though… RandomDSdevel (talk) 20:44, 11 October 2014 (UTC)

On the Location of Articles' Tables of Contents

I like being able to access articles' tables of contents from Winter's main toolbar, but shouldn't this functionality only appear once users have scrolled past articles' actual tables of contents? RandomDSdevel (talk) 20:46, 11 October 2014 (UTC)

Prototype

Hey, I'm very impressed with the prototype! There's no mention on this project page, but I'm wondering if it is yet possible to port any of the source code to MW 1.23? Cloning into the skins directory revealed no means of inclusion, thus I can't test or develop locally. ~Φנσѕєρнєяυм ^w•t•c 19:51, 19 October 2014 (UTC)

Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. Jorm (WMF) (talk) 00:30, 20 October 2014 (UTC)

As far as I know, this is a MediaWiki-less prototype, floating on raw HTML/CSS/JS. Qgil-WMF (talk) 00:23, 20 October 2014 (UTC)

Fixed header on Beta Labs

I tried the "Fixed header" on Beta Labs (with VE also enabled), and ran into trouble with the big blue Edit button. The little dot on the right has a hover menu to choose between Edit source and VE, but it's very tricky to get the mouse from the blue edit button to the menu links. It usually disappears when I start to move the mouse toward the menu.

Also, on my browsers at least (Iceweasel and Chromium on Debian Testing), the button isn't rendering as intended; there's overlap between the text and the three-dot-menu icon. See http://imgur.com/Vq8Zunf Ragesoss (talk) 18:24, 22 October 2014 (UTC)

see also: T85247 VisualEditor incompatible with "Fixed header" beta feature se4598 (talk) 00:32, 26 December 2014 (UTC)

Large tables

Reducing the width of the text might be a good idea to improve readability. But some pages contains large tables, for data or just presentation, especially sport projects but not only.

When there is nothing any more on the right side (so below the infobox), these tables should be able to expand to this part, because it feels really strange to have a big tables condensed to a small size in the middle of the page when there is blank area on left and right. I'm thinking about pages like this one or that one. Zebulon84 (talk) 23:58, 10 November 2014 (UTC)

Some of the first items in the right-hand sidebar of the second article to which you linked seem to be cut off, too, and zooming the page seems to exacerbate this problem. RandomDSdevel (talk) 23:49, 11 December 2014 (UTC)

Release

Roughly when is Winter expected to be released as a beta feature and as the default skin? Ypna (talk) 03:40, 14 December 2014 (UTC)

I don't know. I don't think there are any current plans for anyone to do that work, sorry. Jdforrester (WMF) (talk) 17:49, 15 December 2014 (UTC)

IIUC, Winter is not ever intended to be released as a Complete Skin, or a Beta Feature. See Winter#The Winter Framework - it's a test-bed for people (anyone) to experiment at. Quiddity (WMF) (talk) 19:10, 15 December 2014 (UTC)

What does any of this experimentation achieve, if there is no intended future for Winter? Is it to build a resource for whichever actual skin will be made in the future? My life is a lie. Ypna (talk) 08:24, 16 December 2014 (UTC)

The elements ("snowflakes" in Winter's terminology) can potentially be deployed as either new elements of the existing skin(s), or as standalone BetaFeatures that could also eventually/potentially be merged into a skin. E.g. at http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures we can try out the "Fixed header" BetaFeature. Quiddity (WMF) (talk) 20:16, 16 December 2014 (UTC)

Right, so what about Right Rail as a BetaFeature? It'd be highly useful for designing wp, help, portal etc. pages, not to mention obvious advantages concerning the main ns. Tar Lócesilion (queta) 22:15, 17 December 2014 (UTC)

I'm not sure how much work would need to be done (as the note on the project page says, "This is fairly large in scope."). There are currently no developers or product managers with the many needed hours to spare. All I can see offhand (but I am not a developer) is https://git.wikimedia.org/tree/winter%2Fsnowflakes/HEAD/rightrail

However, Pau is working on some interesting designs for modular rightrail components in Flow (nothing online, yet), for metadata and checklists and similar, so that might be where the work re-begins. Quiddity (WMF) (talk) 21:46, 18 December 2014 (UTC)

:-( Helder 01:03, 29 March 2015 (UTC)

Maybe an old and done...

The design of text&pic seems to me (German user) very oldfashioned, because it reminds in a way the first printed books in 15th century, trying to copy the handwitten medieval manuscripts. What I mean: Did you want persons to read articles as they are used to or do you want to present a new medium? Felistoria (talk) 03:31, 3 January 2015 (UTC)

Great stuff - this should be priority

I have lots of issues with the current Wikipedia layout and the Winter prototype appears to fix/improve on nearly all of them! This is great work. Even though most of the time I spend on the site is in edit mode, I instantly appreciate the changes to the read mode.

Out of every single project I've seen, I think *this* should be the priority for the WikiMedia Foundation. It profoundly affects the way the site is seen and used - for the better. I think the dated look and basic functionality of the software is underestimated as a factor in known declining participation.

Only one suggestion - when entering the edit mode, the right rail area remains empty. It would be much more preferable to use this space to either (a) extend the edit text view to a width similar to the current one (in edit mode, the sole focus is the editing area and presentational spacing for improved prose comprehension is not a factor) , or (b) move the most useful editing links/tools/toolbars into this area. Sillyfolkboy (talk) 22:55, 24 January 2015 (UTC)

Actually, two more points: categories, portals and navigation boxes should have sections in the right rail. I actually drafted a right aligned box in Wikipedia for this very same purpose two and half years ago and would very much like to see the delivery of that concept by people more technically able than I. Transformation of our "See also" sections into a right rail gadget would also be very useful. All together, these would be nothing short of a navigation revolution for Wikipedia (especially for oft-missed categories and portals). Sillyfolkboy (talk) 22:59, 24 January 2015 (UTC)

Suggestions

On the upcoming skin (I think), is there a way that we can have a profile pic instead of a icon; and on the hide sidebar feature, is there a way that we can tap on the logo, and would show the hover menu without going to the main page on mobile when we want to use the full site? 1989 (talk) 14:17, 27 January 2015 (UTC)

Still active?

Is this still an active project? [[kgh]] (talk) 14:52, 23 March 2015 (UTC)

I have no insider information so this is all speculation, but my understanding that with Jorm's departure Winter is in stasis as a separate 'thing'. He was one of the large proponents behind it. As Tar mentions, it's really the bringing together of multiple projects to bring a more cohesive design to the interface of MediaWiki/WMF-projects.

I'd love to be corrected on this if wrong, but I think reaching out to the design team and looking at the MediaWiki UI and UI Standardization Board in Phabricator might shed more light on where things are going. Ckoerner (talk) 15:04, 24 March 2015 (UTC)

Afaik, strictly speaking, this was never a project. It's rather a vision of several projects, developed separately and with different priority. We can see some of them already (Typography Refresh, MediaWiki UI, if I'm correct) and have to wait for the next (e.g. Right Rail). Tar Lócesilion (queta) 16:25, 23 March 2015 (UTC)

Thanks for your reply. I believe most people think that this was about creating the next generation skin for MediaWiki. Personally I have never seen it as a "mutilated" Vector thing. So Winter did not end up in permafrost... [[kgh]] (talk) 16:41, 23 March 2015 (UTC)

Ha! I see what you did there, and I like your sense of humor. RandomDSdevel (talk) 16:39, 24 March 2015 (UTC)

Some problems

See http://m.imgur.com/a/027fP , on mobile chrome browser, the first image show bottombar blocked some language selection on the right when content is too short and there are too many languages, and secondly at the same time while in the winter page the jump to Ænglisc page and arabic page is successful, it can't jump to like chinese or canton C933103 (talk) 12:53, 16 June 2015 (UTC)

fwiw... there is a fair number of invalid entries in the current winter.css file and your observation is most likely being caused by one or more of these invalid entries -- primarily

• ''overflow:" is set to invalid entry ''show'' rather than the proper value ''visible''; possibly followed by
• several instances where the absolute positioning attributes such as ''top:" and/or ''left:'' are set to unit-less values such as ''10'', ''155'' & ''40'' instead of ''10px'', ''155px'' & ''40px''
• . . . among several other "mistakes".

In fact, all the winter/snowflake related .css files need to be [re]checked against W3.org's .css validator at:

http://jigsaw.w3.org/css-validator/ George Orwell III (talk) 22:48, 16 June 2015 (UTC)

What happens next?

This seemed to be a very cool project, but it's a bit disappointing that it's no longer 'maintained'. It looked liked there was a lot of effort that went into this, especially considering money was paid to start user testing. ( https://www.usertesting.com/plans Man these are expensive!)

So, since it's dead, what happens to it? Is there something that's going to replace this framework? Or could it still be picked back up? SamanthaNguyen (talk) 21:56, 7 August 2015 (UTC)

bump SamanthaNguyen (talk) 14:40, 9 August 2015 (UTC)

Screenshots

Anyone have screenshots of Winter designs? I don't see any collections on Commons czar 10:04, 21 July 2016 (UTC)

I can't find any screenshots in Commons, but there are the usertesting videos linked at Winter/User tests that could be used for visual reference. Quiddity (WMF) (talk) 01:41, 22 July 2016 (UTC)