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)

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)

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)


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

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.