Talk:Winter/Archive 1

What do you hate?

• It's very redesigned-gmail-like: clearly delineated buttons (or text links) are for chumps, the font is extra-big so you see less on your screen, and there's whitespace everywhere. Seems like it would be nice for tablets, but I would prefer not to see it on my PC. --Dogcow (talk) 00:08, 21 January 2014 (UTC)

• The text is too big in my opinion. I have to strain my eyes to read it. I think an option to change the size of the text would be great (and I would also suggest making the default text size smaller). -Newyorkadam (talk) 00:20, 21 January 2014 (UTC)Newyorkadam
  • We've talked on IRC about this and I'm not sure how you're getting the great size. There seems to be a disparity within your system and the way Winter renders text. It shouldn't be that painful. I'll look into it.--Jorm (WMF) (talk) 01:28, 23 January 2014 (UTC)

• TOC uncollapsed, at bottom of long lede. old problem of white space around infobox & TOC Slowking4 (talk) 02:45, 21 January 2014 (UTC)
  • The position of the TOC in general is one we want to look at overall. 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.)--Jorm (WMF) (talk) 01:28, 23 January 2014 (UTC)

• Since the earliest prototype I have been watching the site icon disappearing and appearing depending on your position in the page. I didn't say anything because I thought that maybe I would get used to it. I just want to say that I still hate that, and it's the only thing I hate about this whole experiment. Also, I can't recall any site doing this with its brand. I can't offer a perfect solution, as I see the point of having a 100% wide top bar stuck at the top while the rest scrolls. If you stick the full logo on the left then it is probably awkward to see the rest of the column scrolling. If you disable any scrolling to the column then the behavior reminds a bit to the old "frames" (Is that bad? I'm not sure). On the other hand, how would this work for site logos with a different structure than Wikipedia's (image-only, text on top of image...)--Qgil (talk) 20:14, 21 January 2014 (UTC)
  • The site icon disappears entirely upon scroll with the current skins (Vector and Monobook). Retaining branding of any kind is preferable to none at all, I should think. As far as other sites doing things like this, I've seen a few. I know techcrunch used to do a similar trick up until their most recent redesign.--Jorm (WMF) (talk) 01:28, 23 January 2014 (UTC)

• Honestly, I don't like this at all. This isn't about the actual design, that's nice (apart from some issues already mentioned on the page). It's about the way you propose to introduce this. You write: "changes ... to the Vector interface design". No. Your proposal isn't some changes, but an entirely new skin. Every extension and gadget that relies on the Vector design will break. For example adding items to portals (side bar, actions menu etc.) are completely different: Some items (like the "Data item" from WikiBase-Client) have to go to different portals than before, items for the actions menu have to provide an icon, etc. It's okay for a new skin to break things that worked in other skins, but it's not okay to change an existing skin in a way that breaks working things. So again: This is not an update for Vector, this is a new skin. Actually, this looks very much like an "Athena light". I don't know whether you remember all those complaints about Vector when it was introduced, but some users – especially long-time users – really hate any update. Sometimes it is necessary to update a skin, but you shouldn't do this more often than really necessary. I don't know the roadmap for Athena, but introducing Winter, and only a year later Athena is not a good idea. If you want a new skin, then go ahead and implement Athena, use the good ideas from the Winter-prototype and merge them with the proposals for Athena. But this Vector-Winter-looks-like-Athena-proposal is just confusing and IMHO a bad idea. --Schnark (talk) 09:11, 23 January 2014 (UTC)
  • I'm confused as well. Why work on three redesigns? (With Typography refresh being the third one, since it also does a lot non-typography skin changes.) --TMg 12:29, 24 January 2014 (UTC)
    • I agree and actually think that we should just stick with this one and kill both the Typography refresh and Athena because of several reasons that I'll post on the requisite pages. This is the best thing that's come out of development for Wikipedia in quite some time! When will it come out of development/prototyping/alpha and become a Beta feature? — RandomDSdevel (talk) 18:37, 9 February 2014 (UTC)

• The drop downs suffer from the designer gray text accessibility problem. again :D TheDJ (talk) 21:34, 24 January 2014 (UTC)
  • {u|TheDJ}: I've darkened them. Is it better? --Jorm (WMF) (talk) 03:29, 7 February 2014 (UTC)

That panel sticked to my screen is as annoying as a fly. My eyes are getting focused on it instead on text. --Base (talk) 20:46, 25 January 2014 (UTC)

• The upper panel consumes the paper space. I don't need it when I read an article. It would be better to fix (or set separate scrollbar on) the left panel which is really useful while examining the text; maybe its elements and the copy of upper toolbox should be accessible as dropdown or on-hover boxes from it. And please, don't do it to interwikis! Ignatus (talk) 13:46, 27 January 2014 (UTC)
  • I think that it would be quite useful to have the left sidebar stay locked where it is when you first load a page while you scroll, too (at least on the desktop, where scrolling isn't normally preceded by tapping the page to grab it with your finger 'cursor.') — RandomDSdevel (talk) 18:41, 9 February 2014 (UTC)

• The light gray text on a white background is hard to read, and my eyes are just fine. It seems like an accessibility concern. Jonesey95 (talk) 15:24, 27 January 2014 (UTC)
  • {u|Jonesey95}: I've darkened them. Is it better? --Jorm (WMF) (talk) 03:29, 7 February 2014 (UTC)

The shadow appearing and disappearing on scroll is distracting. Why not simply letting it stay after the user stops scrolling, as an indicator that some content is obscured under the header? --Waldir (talk) 15:29, 27 January 2014 (UTC)

{u|Waldir}: I'm thinking about chopping the shadow entirely. It's got weird timing issues that are hard to get right. There's a purpose for it, but it may not be needed.--Jorm (WMF) (talk) 03:29, 7 February 2014 (UTC)

Some thoughts:

• Not obvious how to add a page to one's watchlist - the icon one has used for some time (the star) leads to the current watchlist.
• The search space is way too big and really feels like it's in the wrong place; if it's not clearly going to be a box, then it needs to be at the far right. In fact, on almost every site I go to, it's on the far right, and that was something we supposedly addressed by moving to Vector.
• Take out "leave feedback": it's essentially deprecated on most projects since nobody has the time to deal with the stuff.
• What's this "clear saved data" all about? Does it clear the editing screen? Clear one's preferences? Do something else entirely?
• Unclear what the purpose of the "Typography" link is.
• Absolutely loathe the grey text; it's very, very difficult to read.
• I tend to agree with some of the others who are pointing out that this is a new skin, not some minor tweaking to Vector. Risker (talk) 19:32, 27 January 2014 (UTC)
  • Ha...kept looking again and again, and finally found how to add to a watchlist. Tabs belong at the top of the page, sorry to say. This is a usability thing: almost all websites have the tabs at the top, and that is where people expect them. I'd like to see a broadscale (non-WMF specific) usability study that demonstrates conclusively that tabs below the title are more effective; I'm pretty sure that won't be the finding, though.
  • The tabs don't actually look like tabs, they just look like disembodied words, with no obvious reason for anyone to click on them. Risker (talk) 19:41, 27 January 2014 (UTC)
    • Final thought: I use Monobook because it's a lot more accessible than Vector is (kind of ironic given Vector was supposed to be the "accessibility solution"), and nothing that has been modified here seems to rectify the issues that Vector caused. It also feels like it's absolutely loaded with javascript (lots of funny lags when using the old/slow computer), which is increasingly becoming a problem in keeping Wikipedia accessible to thsoe with less-than-ideal internet connections or slow/old devices. Risker (talk) 19:46, 27 January 2014 (UTC)
  • The links in the sidebar are about the prototype only. If you'd clicked on them, they'd be apparent what the uses are:
    1. The "Leave Feedback" link goes to this page;
    2. The "Typography" link applies a restricted measure to the page;
    3. The "Clear saved data" link clears all cookies stored with the page (like the saved username). It's only the one for now but I'm adding some more sticky values.
  • As far as the tabs below the title go, we know that the tabs outside of the content area are not being seen by the bulk of our users. So we know that the current situation does not work and I'm willing to bet a chunk of change that putting them inside the content area (and thus strongly tied to the content) that they become stronger affordances. This is not just a change for changes sake. When you refer to "most sites having tabs at the top" you are referring to what we call "site navigation chrome" - they are a function of the whole site's information architecture (on Wikipedia, this is typically in the sidebar). Another purpose of this change is to take actions that are effectively lost and buried in the sidebar toolbox and actually connect them to the page itself.
  • As far as "new skin vs. vector", this is not a new skin. It may appear that way, but it isn't: the underlying skin code is effectively the same.
  • If you're seeing disembodied words, that's a weirdness. They should be appearing as buttons, with the exception of the section edit links.
  • The search box not being on the far right is addressed elsewhere on this page - this article helps to explain reasoning. --Jorm (WMF) (talk) 21:07, 27 January 2014 (UTC)
    • Umm, the search box in this prototype pretty much ignores every single suggestion in that column. It's hard to find, it's not clearly separated or delineated from the surrounding area, it's not in the upper right, and it doesn't have a really obvious search button. It's one thing to make a major change like this based on evidence, but if the best evidence that can be produced is a column that recommends doing things other than what is being proposed here, there's a pretty big disconnect. I can go with a bigger search box, but let's see the evidence that people are having a hard time finding the search box in the upper right corner now, and that they're better able to see this proposed search box.
    • Link to the research showing how you know that the tabs outside of the content area are not being seen? And link to any research showing that this is more effective and increases actions? (I'm fine with moving the edit link, as long as it's a big, bright button. Of course making it a big bright tab at the top would probably have the same effect, but meh.)
    • What is the point of moving all those things from the sidebar, where people are currently using them, to a hard-to-find, unlabeled dropdown box in the middle of the text? More importantly, why are admin functions being mixed with "page" functions? This is a key usability principle, not mixing various functions into the same tab or dropdown.
    • The words look disembodied to me...they're grey, they're in a grey box, they're hard to read, and they have no context relative to the rest of the page. Risker (talk) 21:48, 27 January 2014 (UTC)
      • {u|Risker}: Well, we're just going to have to agree that we have different interpretations of what the research in that article says. Either way, we're going to be testing the search discovery very soon now.
      • The research we have about the tabs comes from several user tests and observable tests. I plan on running additional ones targeting specifically this issue.
      • The point in moving things from the sidebar is described in the main page of this document, but I'll again summarize: most of those actions are buried in the "Toolbox", which is collapsed by default. Further, users are trained to only pretty much ignore the sidebar because it doesn't obviously appear to contain local-context functionality. As far as the mix-in within the single menu, I did that for ease of use. Admin functions could easily be pulled out into their own menu. However, there's issues with that: some actions are admin-only depending on the wiki.
      • Re: disembodiment: The current version has a default modification to make them not appear as buttons and pulls them up tighter to the article title (with the exception of the Edit button, which is its own ball of wax). --Jorm (WMF) (talk) 03:26, 7 February 2014 (UTC)

• No keyboard shortcuts that I can find (e.g. alt-shift-T for talk page—assuming Windows). I only use a mouse or other pointing device if I absolutely have to. Beeswaxcandle (talk) 05:14, 28 January 2014 (UTC)
  • I came here to say the same thing. Keyboard shortcuts are also absolutely essential for screen reader users such as myself. Other problems include the lack of alt text on the images and labels on the buttons. However I do kinda like the new edit section buttons – they handily fix bug 11555. However, I use Monobook, so I assume I won't be affected by any of these changes. Graham87 (talk) 10:14, 28 January 2014 (UTC)

• Unfortunately, this is a prototype, and does not support keyboard shortcuts. Rest assured, however, that the production version will, as it will inherit the current skin's behavior in that regard. --Jorm (WMF) (talk) 03:26, 7 February 2014 (UTC)

• When I click on a section in a TOC, I was taken to that section. But, the section title and the first line of that section is covered by the floating top bar. It is not affirming that I reached the right place. — Veeven (talk) 10:46, 28 January 2014 (UTC)

  {u|Veeven}: This was a bug and should be fixed now.--Jorm (WMF) (talk) 03:26, 7 February 2014 (UTC)

• It is a bit uncomfortable for me to look for page actions in two places (in the fixed header or below the page title) depending on my position on the page. (May be by habit I am tending to go to top, instead of using the top bar.) The page actions below the page title seems more obtrusive. — Veeven (talk) 10:46, 28 January 2014 (UTC)

  {u|Veeven}: This is something I have concerns about as well. I'm not entirely certain that floating page actions as you go is a great win yet, specifically because so many people know instinctively to go back to the top. But again: this is something we're going to be testing.--Jorm (WMF) (talk) 03:26, 7 February 2014 (UTC)

• I had a look at the demo page, then I clicked Discussion from the navigation (choice?) panel Discussion History Watch. Indeed, the talk page was then displayed. However, there was no clear way to move back to the article. I expected that on the talk page Article or Read would replace Discussion in the panel, but this was not the case.

Gżdacz (talk) 17:55, 28 January 2014 (UTC)

• {u|Gżdacz}: This was an oversight in some of my display logic that should now be fixed. --Jorm (WMF) (talk) 03:26, 7 February 2014 (UTC)

What do you love?

The disappearing line of course, among other areas described below! MGalloway (WMF) (talk)

+1 on the editing/navigation interface that becomes part of a static header. NeilK (talk) 00:18, 21 January 2014 (UTC)

love the new layout, new menu dropdowns, bigger search box, are we migrating phone aesthetics to laptop? Slowking4 (talk) 02:47, 21 January 2014 (UTC)

• The whole thing is a lot more modular than current vector and it seems to be a lot more easier to customize via plain MediaWiki:Common.css, allowing sites to get custom look & feel without digging really deep into Vector's rigidness. Big bravo for getting rid of the hardcoded blue lines.--Qgil (talk) 20:17, 21 January 2014 (UTC)

• I love this and we should totally do it. Requires some polish, but it's the way to go. TheDJ (talk) 22:04, 24 January 2014 (UTC)
• +1 to TheDJ's comment.//Hannibal (talk) 21:49, 25 January 2014 (UTC)
• I like that the "edit" location has reverted to far right, instead of right after the header. Honestly, if you're going to move it anywhere from the far right, it should be to the far left of the line. Its current extremely variable location is a real pain. Risker (talk) 19:49, 27 January 2014 (UTC)

What would you change?

The line weight to half it's current size or lighter color. Or making the header a light grey without the use of lines to distinguish header from content. There's currently too many lines enough to be distracting. When the controls for the subsections expand, the general site/page buttons should minimize, so many options to choose from otherwise. +100 to the fact that you surfaced only most used page/site actions and kept the rest in the drawer. You should also make use of the header as a progress bar to give readers an idea of their current position in relative to the length of the article. MGalloway (WMF) (talk)

Some comments on first look:

• Toolbar directly underneath the article title is too distracting, IMO. 99.9% of users of this page want to read it.
• Underlining buttons to show hover is a bit much. The button already has a shape, you can highlight that rather than add a new shape to the page. Actually, any kind of hover action is on its way out, if we consider mobile.
• I know what you're trying to do now with the floating header, but I expect that most users will be confused if the search box is not on the top right. That said Facebook does it that way, so maybe I'm wrong. Maybe it's me but a search box with an "open" top like that doesn't feel like a search box. Perhaps I could get used to it. "4 million articles", seems a bit too self-promotional for WP.
• It feels like there's too many icons for user-related stuff, especially once the editing icons join the party. Can there just be an avatar, with a notifications indicator, that reveals the rest?
• I think you are struggling with making interface elements visible while not impeding reading flow. But I'd prefer interface elements to be light type/thin lines and darker, rather than thick and lighter. Bold and middle-grey text looks kind of fluffy to me.
• Can the lock icon be merged into the Edit icon(s)? This isn't really a comment on your design, but I've often thought they should be somehow merged.

NeilK (talk) 00:05, 21 January 2014 (UTC)

Re: Toolbar under the title: This is very specifically one of the things this refresh is meant to address: the idea of "tab blindness" by not directly associating context-local actions with the local page. Putting them under the title is currently what I think is the "best" choice among a sea of problems (like, having them float to the right interferes with lock/topic icons, under the title we have problems with co-ordinates, etc.). I don't necessarily disagree that people are there to read but we also want people to know that there are other things, and the toolbar is something you can quickly move past or ignore.

The "four million" articles thing is just placeholder text.

Re: underlining buttons: I'm not entirely sure I know what you mean by that, but I think you're referring to the section edit buttons. Those have the current appearance because:

• Having them appear on hover was too much
• Giving them a button shape at start felt clunky
• Nestling them on the edit line mimicked the line behavior in the header.

Re: too many icons: Yeah, we're actively talking about the entire "moving local-context actions into the toolbar" bit. As I've said on the design list, my gut instinct is that doing so is a bad idea for several reasons, but we want to explore the idea anyway. As far as the personal bar goes, the visible icons are: watchlist, talk, echo, and user (avatar). We're looking at collapsing this within certain contexts (like edit mode) but for now we're down to those.

Re: search box in the right: that's not entirely true. This is a good article that explains a lot about how search should be placed. In our case, search is the primary entry point and so can be emphasized greater.

Re: lock icon merging: Yes, it can be; in fact, I have one that is intended to be used for the edit icon if the user isn't able to edit the page. I just haven't included it in the prototype because, well, there are no users. As it were.--Jorm (WMF) (talk) 01:37, 23 January 2014 (UTC)

• Too many icons are bad! Too much time figure them out. This would be especially painful for casual editors/readers. Especially since Wikipedia doesn't have an icon culture i.e. almost no established patterns except the star which IIRC was also painful ;-). And sin Wikipedia is multicultural - as multicultural as a site can get ;-)... There is a lot of space up there. So you don't have to hide the text. Also avatar icon should be separated from other things. Don't get me wrong - I like that there are icons, but at a very least in the first phase this should be icons and text (at least for large screens that can hold them). --Nux (talk) 22:56, 27 January 2014 (UTC)

"Toolbar directly underneath the article title is too distracting, IMO. 99.9% of users of this page want to read it."

I totally agree; I suggest moving it to where the header is, but farther on the right (like so :) -Newyorkadam (talk) 00:31, 21 January 2014 (UTC)Newyorkadam

I agree as well with the problem, let's not introduce UI elements between the title and the body content. For what is worth the Translate extension already does this with "Translate this page" (bug 51533) and it is really obtrusive. I agree that simply moving everything to the right might just work.--Qgil (talk) 21:48, 22 January 2014 (UTC)

I'd be interested in hearing any alternative suggestions you may have.--Jorm (WMF) (talk) 01:37, 23 January 2014 (UTC)

I actually don't mind how the tabs are below the article name and am quite annoyed by how these same tabs disappear when you start scrolling (maybe we could have them stick to the bottom of the search box where the name of the article that you've been reading goes after it has been scrolled out of sight?) since I've always thought of them as just another part of the header. I do understand, though, that having a two-line header can be slightly annoying, but where would the tabs fit into the main toolbar if they moved up into it like the name of the article that you're reading does after you scroll past it? Having them wedge themselves in between the search box and the toolbar icons would just be awkward, if you really think about it… — RandomDSdevel (talk) 19:13, 9 February 2014 (UTC)

• The name, because it is too similar to Extension:Winter and could cause confusion (or maybe not, just letting you know I confused them at first when I saw this in the RCs). πr² (t • c) 01:45, 21 January 2014 (UTC)

I think that this prototype's name is 'Winter' simply because its testers see English Wikipedia article on 'Winter' when they load it. — RandomDSdevel (talk) 19:13, 9 February 2014 (UTC)

• i would like to see a skin with indents on paragraphs. more book-like, less technical documentation-like. Slowking4 (talk) 02:48, 21 January 2014 (UTC)

I agree, but think that this should just be an option in MediaWiki preferences and/or configuration options instead of something enabled by a skin. — RandomDSdevel (talk) 19:21, 9 February 2014 (UTC)

• I would like a little bit more color. It's very grey now.//Hannibal (talk) 21:49, 25 January 2014 (UTC)

• Agree with Base. I think there should be a nail button on the panel, click on which the panel will be fixed on the top of the whole page.

• Maybe it's just because I'm used to the old interface, but I think the Discussion...Edit section better be moved above or to the right of the title.

• And the url should change when user goes to another article like the website http://www.usatoday.com/ does.

--維基小霸王 (talk) 04:15, 26 January 2014 (UTC)

• Can anyone reply?--維基小霸王 (talk) 16:26, 28 January 2014 (UTC)

  {u|維基小霸王|維基小霸王} The urls should now change for you. Moving the links to the right or above the title is actually pretty problematic - that area is reserved for use by the community which makes it hard to work with.--Jorm (WMF) (talk) 03:16, 7 February 2014 (UTC)

• it's a bad idea to show article name, not language name in interwiki. Just imagine sidebar with interwikis to this article, for example Rubin16 (talk) 11:50, 27 January 2014 (UTC)
  • This was a bug and is now fixed in my version. I was generating the links from the langlinks bit in the API; this does not provide the language name. I had to create a separate lookup table for that.--Jorm (WMF) (talk) 20:56, 27 January 2014 (UTC)

  +1. Also, it makes it difficult to find a language, as many pages in different languages have the same name. --Yair rand (talk) 13:33, 27 January 2014 (UTC)

  In ru.wiki one user showed possible article - IBM Rubin16 (talk) 13:38, 27 January 2014 (UTC)

• Not seeing any value to having "add image" and "insert template" to the edit options. Risker (talk) 19:54, 27 January 2014 (UTC)
  • It's there to demonstrate how a secondary pull-down button can be used for additional options other than "Edit". It's a way to solve for the Edit/Edit source problem.--Jorm (WMF) (talk) 20:56, 27 January 2014 (UTC)
    • Which problem is that? The current solution seems to be working just fine. Risker (talk) 20:59, 27 January 2014 (UTC)
• I think that text must be moved like this or search field must be changed to this. (Also on this screenshots you can see bug in Firefox with buttons’ padding) Saint Johann (talk) 20:36, 27 January 2014 (UTC)

  I've actually haven't noticed that it's a search bar ;-). I think there should be visible border around it at least until user clicks on it. Maybe just a top border and box shadow would help? Like so: search-top-boarder-shadow.png --Nux (talk) 22:56, 27 January 2014 (UTC) PS: Just to clarify - of course box-sizing must be prefixed for now... But note that since default box-sizing in old IE is box sizing set to "border-box" works everywhere - even in old IE.

  {u|Nux} - Your shadow idea has some interesting merits. We're going to be testing the search system pretty heavily in the next week or so (user testing), and I wouldn't be surprised if we end up playing around with something like that. As far as issues with IE, the prototype is only going to work in Chrome and Firefox for now, I'm afraid. It's just faster to develop prototypes that way. We'll get to other browser support later, when we enter production.--Jorm (WMF) (talk) 03:16, 7 February 2014 (UTC)

First Impressions

First impressions by TMg

1. The search isn't recognizable as an input field. First, I thought it's because if the icon in front instead of the back. But that's not the problem. The color changes of the icon are very nice. I think this will work. The problem is, it doesn't look like an input field at all. It's the same 2 pixel gray border everywhere. It looks like an additional headline or advertisement. No (inset) shadow, no border above, no additional padding. The hover changes are nice but do not solve the problem if you are looking at the page and not moving the mouse so far up.
2. Some of the icons on the right are a bit non-informative. Here is what I saw when I looked first: something with text (?), a favorites star, something about talk, more about talk, this time with a number of probably unread messages, a square (?), my user name, an arrow for more tools.
3. Especially the square is strange. If I remember right from Flow discussions there will be no avatars.
4. Is the "contents" icon on the top really needed? I found it confusing when I saw it first. I had no idea what it does judging from how it looks and where it is in the interface. The icon doesn't tell a story. It shows three lines of (probably) text. Could be anything. I think I understand why you placed it there (don't get me wrong, please) but I think it does not belong there. All other article tools are moved down to the article area (instead of being a tab). The same time the table of contents is moved to a tab? This feels strange.
5. The hover behavior on the popup menus is a bit strange (and wasting rendering time). Click one of the arrows. The menu opens and stays. Now move the mouse. The button under the menu changes when the mouse leaves and enters the menu. Instead it should stay in the "active" state. This is notable on the edit widgets since they use a blue "active" state.
6. The section edit widgets look a bit broken. This may be my Opera 12. The border is missing and the white background cuts the gray underline from the headline.
7. Performance. Some of the transitions feel slow and clunky. For example the blue hover on the edit widgets is delayed but should be instant. Again, maybe an Opera 12 issue.

--TMg 00:21, 23 January 2014 (UTC)

1. This is one of my concerns as well. My thoughts are mostly about changing the text to the title of the article - I think it may impede recognizability that it's a search. This is something we want to test; it could be that very few people miss it.
2. There's a lot of talk about the duplication of icons and such not. As I mentioned above, it's my gut that we shouldn't move article actions into the header for just this reason (among others).
3. Re: avatars: yeah, Flow will not have avatars (but GlobalProfile likely will). That square is a placeholder for a user icon (that I just got today, actually).

Word on the not breaking things up; I'm going to split this into its own section so that others can do the same.

4. Re: Header TOC icon: We're actually planning a test (I think it's the first one) to see how that icon and its functionality plays out. I'm not sure its needed, either - there's a lot to be said for the cognitive switch to "scrolling to the top".
5. This seems like a bug behavior; the button should stay blue if the menu is opened. I'll look into it. Re: tooltip hovers: yeah, this was a gamble and it failed. I've killed them from my version and will update the primary prototype soon.
6. This is a design decision to reduce the section edit buttons in visual weight while also making visual callbacks to the header treatment.
7. Regarding transition performance: I suspect that may be an Opera thing. I built the prototype for Chrome/Firefox, and it's entirely possible/probable that Opera requires its own special transition keywords. Is it possible for you to test in Chrome and see if the performance is the same? If so, it may be something else.--Jorm (WMF) (talk) 01:50, 23 January 2014 (UTC)

Edit widgets

1. Changing the text will not help. When a user is lost on a website and needs a search he does not read text. He scans for either a short input field or the word "search". But this one here is completely different. It spans the whole page. No other search does that. Look at the home pages at Google, Bing, Yahoo, DuckDuckGo and so on. They are all using short input fields with a button at the end.
6. I'm aware that the borderless edit buttons are probably not an accident. But they look like. See the screenshot. The tiny bit of the gray line on the right makes it look like an accident. The edit button is not aligned. It should be either centered on the gray line or below the gray line without cutting it.
7. I think I found the problem. Hovering the edit buttons causes a reflow of the whole page. This makes it feel clunky. See the screenshot. When not hovering the button the text is fine ("Cats" is on the next line). It seems the "active" state uses some negative margins or something like that?

--TMg 12:22, 24 January 2014 (UTC)

{u|TMg}:

1. We are going to be testing exactly this thing very soon (user testing). There's about five things I want to test with the search box.
2. Are you, perchance, on firefox? There was an issue that was possibly causing the reflow that should be fixed now.
3. Re: Transitions: I added some browser specific code for those that may improve your performance.--Jorm (WMF) (talk) 03:10, 7 February 2014 (UTC)

First impressions by JAnD

1. Search field is hidden - I searched for it about 20 seconds - only by watching, not with mouse.
2. I'm afraid there will be problem like with Vector - in vector are some action buttons (move, delete, protect) hidden under one tab, so many active editors/sysops still use monobook. This skin/interface make it worse than vector.
3. Interlanglinks as name of foreign article should be fine until I want to go specially to one language or until reading article about place. When there is hundert links of [New York], which one is the language I want?
4. Edit link: Many people wanted them right nex to header of paragraph. When it is default now, you will move it again to the right?
5. What about viewing/editing in browser without js+css? (old mobile phones, old computers, some security reasons, slow connection)?
6. When I click to [Discussion], this button should change to [Article], because now I must search for link for going back to article
7. There are missing some links like to [Special:Specialpages]

JAn Dudík (talk) 11:39, 27 January 2014 (UTC)

JAn Dudík:

1. We're going to be running some fairly rigorous user tests on this exact problem. I have some personal concerns about the way this works, but I have been wrong before. The purpose of building the prototype is to be able to test it, which is just what we're going to do.
2. I actually disagree with that: many of the actions that are truly hidden in Vector are now more discoverable (e.g., not being hidden in the Toolbox). Further, we can also surface more buttons from outside of the pulldown menu if we so choose, since there is a great deal more real-estate.
   • That said, this is an interesting idea and one I think we should explore: pulling more actions into the toolbar ribbon.
3. I have never agreed with moving the section edit links to the left for several reasons - but the biggest one is that they were inconsistently placed. The primary argument for doing so is that users would be better able to judge which section they are editing. However, we have ideas on how to avoid that problem (and they worked in the first version of the prototype; unfortunately moving it to a full API system broke that technology and I haven't had a chance to fix it.)
4. In the case of old browsers, no JS, etc, they would fall back to the current system (e.g., exactly what Vector uses today).
5. This should be fixed. I went through a great deal of logic problems about that.
6. The API doesn't support loading Special pages very easily, if at all. Since the prototype works through the API, they cannot be included.

-Best, --Jorm (WMF) (talk) 02:49, 7 February 2014 (UTC)

First impressions by Sven Manguard

I have voiced lots of objections to lots of things that the design team has come up with, so I might be coming at this with the disadvantage of being "that guy that poo-poos everything we do, but...

There is no feature on websites that bothers me more than pieces of the page moving with the page when I scroll. I actively avoid websites that do that, be it sidebars that move, top bars that move, icons on the bottom that move, what have you. This isn't a visual aesthetics thing, this is a "this fucks with the way my brain works and is a deeply unpleasurable experience" thing. Whenever something on a page moves that shouldn't move, in this case the top bar, it completely breaks my concentration. I tried reading the article on cat, but every time I scrolled down, my concentration shifted from where I was in the prose on the bottom of the page, back up to the top of the page to focus on the moving section, and then back down towards the bottom of the page, where I had to find where I was again. It's tremendously distracting, and it is something that I cannot train myself not to do. This is especially pronounced because of the shadow that briefly appears each time the page scrolls. Because the top bar changes when I scroll, it grabs my attention even though I know consciously that the change is nothing of import. For long articles, that means I am shifting my vision unnecessarily 20 or 30 times, losing my place 20 or 30 times, and it is fatiguing.

Of much less concern, but still something that I want to mention, is the one pixel difference between the bottom of the Discussion/History/Watch box and the smaller box with the drop down arrow that's attached to it. That one pixel gap is very noticeable, and not in a good way. If you made the gap slightly larger, it would look more like a deliberate stylistic choice. As it is now, where that one pixel gap is used only in the two boxes up top, it looks like an alignment mistake. I have been informed that this is, in fact, a bug.

Third, I see a box next to my name that, when I tried to copy it, came up as "avatar". I take this to mean that you mean to allow people their own personal image, like Wikia does. I don't have any real objections to this, but before it is rolled out, there needs to be a discussion with Commons and with the larger projects about ground rules for what I assume will be an influx of new images. Will avatars have to be freely licensed? (I would say "Yes"). Will avatars have to be stored on Commons or can they be stored locally on other projects? (I would say Commons only, for both technical and enforcement reasons). Will local projects have the ability to enforce certain guidelines locally, or will there be one central guideline? If the latter, on which project? (I would say one guideline, on Commons, but I doubt that EnWiki would cede power over policy like that). Please don't just roll it out one day without giving advanced notice. We will need to build policy ahead of time to prevent abuse and make the whole system manageable.

Finally, I find the lines a bit thick, and would keep the width vector uses. To me, the think lines and square build that this uses (I'm going to call it the Microsoft 8 look) feels especially bland. While I know that simple, minimalist design is supposed to be accessible, it comes across as too simple. This is nowhere near as serious a concern as the first point, but if I'm going to do a first impression, I might as well mention it.

Feel free to reach out to me. I don't check this project... well... ever, but if you leave a note for me here, I'll come back. Sven Manguard (talk) 07:39, 4 February 2014 (UTC)

Sven Manguard:

First, I'd never ignore you, you know that.

You raise an interesting point about the fixed header. Moving stuff doesn't bother me, but it clearly does you (and, I'd presume, some other people as well). Would having an option to not scroll the header along with you help? I should expect that something could be built fairly easily but I'd rather not spend the time building it if you don't think it would help you.

The shadow appearing/disappearing is something I'm wrestling with myself. I wonder if part of my issues aren't due to the length of time it's visible. It's a bit tricky, that code (checking when the user stops scrolling, really), so it may get cut entirely.

The avatar was an artifact. I've replaced it with a default "user" icon now. Avatars are outside of this scope, but are part of Global Profile.

Other people felt the lines were thick, too. I, as well, after a while. By default they are now only 1 pixel wide, but there is a sidebar toggle (thin mode) that returns them to their former fatness.

I've sent you an echo ping with this, but I'll leave a note on your enwiki page as well.--Jorm (WMF) (talk) 03:05, 7 February 2014 (UTC)

Also, your firefox bug should be fixed. Good catch!--Jorm (WMF) (talk) 03:07, 7 February 2014 (UTC)

Jorm (WMF)

I've spent half an hour trying to put my thoughts down into words, but it's not coming easily. If you don't mind, I think it might be easier to speak with you over IRC. Doing that will also afford me the benefit of being fully awake, which always helps when trying to put thoughts into words. In the mean time, I wanted to point you to this image, which shows a bug involving a large number of inexplicable edit links. Sven Manguard (talk) 08:39, 7 February 2014 (UTC)

I shot you an email with some additional information, but in the interests of public community dialogue, here are my thoughts:

I know that you, personally, would never ignore me. When I wrote that comment, however, I didn't know who was behind Winter. I am also acutely aware of just how much WMF-proposal-bashing I have been doing lately (I only complain because I care!), and I don't want to tarnish my perception among the general WMF staff by being perceived as (or becoming) a perpetual whiner.

Onto the matter at hand: I don't think that it's the fixed-in-place header itself that is causing me an issue, but that it has visual changes when I scroll. There are, best I can tell, four changes to the bar when you scroll (I labeled them in this image). The pop-in Wikipedia bar [A], change in search bar to article title [B], and change to the right-side icons [D] change only when you scroll from the very top of the page down. While jarring to me, they only happen once per page. It's livable, and ultimately I understand the reasoning behind them. The shadow [C] happens every time, and as you have indicated, isn't necessary. As such, I personally would advocate getting rid of the shadow.

Having an option not to scroll the header would be something that I would personally use (although if the shadow is dropped and the right side icons don't change when I scroll, I likely won't have to), but if it's something that takes more than an hour or two to code, I'm not sure if that's something that could be cost-justified.

On the subject of changes to the bar, I am not a fan of the change to the right-side icons [D] from the personalized icons to the editing icons, not only because it's the most jarring of the visual changes that happens when I scroll, but also because I think it would be valuable to have both sets of icons on the bar at all times. Yes, this does shrink the amount of space available to the title/search bar area, but both sets of icons are useful regardless of where you happen to be in a given article.

Finally, I personally like the green-smiley-face-in-a-speech-bubble icon for Thanks over the heart, but it's certainly not a major issue.

I'm, as a whole, very impressed by this product. I will honestly miss the blue-ness of old-vector - I'm not a huge fan of greyscale in general - but I understand the reasoning behind getting rid of the blue shading. With the exception of [C] and [D] from above, I either think are great ideas or am entirely neutral about. Sven Manguard (talk) 21:21, 11 February 2014 (UTC)

First impressions by ArdWar

Well, there are some difficulties that may lessen the user experience.

1. Any anchor navigation get obstructed by toolbar, including click in TOC, notes, references, etc. Giving impression that the click brought you into wrong reference number, etc.
   • Same with pageup/pagedown navigations, something got covered by toolbar!
2. Sidebar is breaking when it is longer than the article.
3. Subscript and superscript make the line look crowded when it happens to be placed alone in a new line. (ex. [citation needed] and [clarification needed])
4. h3 is more prominent than h2.
5. Some (if not all) template formatting is broken.

ArdWar (talk) 00:14, 6 February 2014 (UTC)

ArdWar, some responses:

1. This should be fixed now. It also has some little magic scrolling.
   • This I haven't seen and will look into.
2. A problem with the prototype specifically, I'm afraid. The production version will not have this. Could you point me to an article that you're seeing this on, though?
3. This should be fixed, as I ported over a lot of the css rules from Wikipedia. If not, it is, again, something that would only happen in the prototype.
4. Ditto this.
5. And ditto that. Template formatting depends heavily on css that is in Wikipedia's Common.css file, which I did not include.

Hope that answers some mystery.--Jorm (WMF) (talk) 02:37, 7 February 2014 (UTC)

Did you find any bugs?

Bugs are listed on the MediaWiki page.

Can I first just say thanks to the design team, this looks great, amazing job etc. etc. One very minor bug I found: on my userpage, I have an administrator and DYK topicon (you can see them here) - interestingly in Winter, the administrator topicon does show but the DYK one does not? Also, a scroll bar appears around the user-ad I've got on the page which is very large, unsightly and unecessary. That's all I could find, but it looks really good! :) Acather96 (talk) 21:18, 13 February 2014 (UTC)

Serif fonts.

http://i.imgur.com/2qRB3n1.png

Frankly I think it looks better.

https://www.dropbox.com/s/qb6sxcm61lykrpr/bootstrap.min.css

For default

https://www.dropbox.com/s/nyq13zqi66i6r61/winter.css

For new type layout

You'll need to add the font stylesheet, althought I bet any serif font would look nice..

<link rel="stylesheet" href="https://use.typekit.net/c/ef4131/freight-text-pro:i4:i7:n4:n7,jaf-bernino-sans:n3:n4:n6:n7.WHZ:N:2,WHc:N:2,WHY:N:2,WHb:N:2,Zv2:N:2,Zv4:N:2,Zv6:N:2,Zv8:N:2/d?3bb2a6e53c9684ffdc9a9bf21f5b2a62e0aa097ce99d70af0d47c9d0f7c12685b0bbf3a7027ef83ad670470dcacaf97d64069c1f5d4f44ad28ca446b38f16fdcbc614072e6181ef1df7f32063b47fcad74682ec81ee0655b1d20e4cc2a293a47f2dc03c6a6728c93e6fbad384b343ea644ee02a91edd77f01a87683427b3939382c3730bb6bf80cc64cd416ef47fa77875">

edit: alternatively

http://i.imgur.com/68s12Rh.png

Serif fonts are a non-starter for us as the use of them causes visual "gutters" in people who suffer from dyslexia and certain other kinds of macro-degenerative vision problems. --Jorm (WMF) (talk) 17:06, 7 February 2014 (UTC)