Talk:Winter/Archive 1

Please leave feedback below.

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)
 * The drop downs suffer from the designer gray text accessibility problem. again :D TheDJ (talk) 21:34, 24 January 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)


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

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)

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:
 * The "Leave Feedback" link goes to this page;
 * The "Typography" link applies a restricted measure to the page;
 * 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)

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: NeilK (talk) 00:05, 21 January 2014 (UTC)
 * 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.
 * 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" 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)


 * 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). πr2 (t • c) 01:45, 21 January 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 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 http://www.usatoday.com/. --維基小霸王 (talk) 04:15, 26 January 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 [//i.imgur.com/lLKUycA.png this] or search field must be changed to [//i.imgur.com/gGwfCWk.png 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.

First impressions by TMg
--TMg 00:21, 23 January 2014 (UTC)
 * 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.
 * 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.
 * 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).
 * 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.
 * 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".
 * 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.
 * This is a design decision to reduce the section edit buttons in visual weight while also making visual callbacks to the header treatment.
 * 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)


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

First impressions by JAnD
JAn Dudík (talk) 11:39, 27 January 2014 (UTC)
 * 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]

Did you find any bugs?
Bugs are listed on the MediaWiki page.