MediaWiki - User contributions [en]

Reading/Web/Accessibility for reading/Reporting/en.wikipedia.org

2025-05-23T06:52:02Z

RandomDSdevel: /* Planetary hours dark mode error */ Added my signature after I forgot to include it earlier.

__NEWSECTIONLINK__
{{Auto archiving
|archive = Reading/Web/Accessibility for reading/Reporting/en.wikipedia.org/Archive %(counter)d
|algo = old(30d)
|counter = 2
|maxarchivesize = 250K
|minthreadsleft = 5
|minthreadstoarchive = 5
|archiveheader = {{talk archive}}
}}
{{Archives}}{{-}}{{Center|'''[[Special:NewSection/{{PAGENAME}}|CREATE A REPORT]]'''}}
Key: The following emojis in the title mean someone has looked at the feedback and worked out what to do with it.
{| class="wikitable"
|+ Caption
! Icon !! Meaning
|-
| 📢 || User is providing general feedback and it should be reviewed by designer/PM. If the template is legible in dark mode (just bright!) you can also consider it feedback and use this emoji. For popular templates, please consider adding a comment on the talk page when adding this emoji.
|-
|❓
|Report was unclear and we don't know what to do with it.
|-
|✅
|This has been fixed or reported on wiki.
|-
|🐛
|This is tracked in a bug or a talk page comment (please use the Tracked template).
|-
|🤖
|Concerns a gadget
|}

== ✅ [https://en.wikipedia.org/wiki/Portal:Current_events Current events] dark mode error ==


'''Issue Description'''
The color is fine. However, the screen is not going into wide mode. This occurred in both the home page and the Current Events Portal.

== [https://en.wikipedia.org/wiki/Taipei_101 Taipei 101] dark mode error ==


Tower logo in infobox doesn't display well in dark mode. It has a transparent background and assumes a light background. – [[User:OdinintheNorth|OdinintheNorth]] ([[User talk:OdinintheNorth|talk]]) 00:47, 28 March 2025 (UTC)

== Dark mode error ==


'''Issue Description'''
Simple request: Have the same logo appear for Wikipedia on dark mode. Seeing the inverted version is weird and gives the impression of something going wrong (why it works for Testpedia). - [[User:Klein Muçi|Klein Muçi]] ([[User talk:Klein Muçi|talk]]) 17:52, 28 March 2025 (UTC)

:@[[User:Klein Muçi|Klein Muçi]] You have to be more specific. If you see a color-shifted inverted logo, that is probably because the non-inverted version is not dark mode compatible and no one created a inverted version by hand yet. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 21:35, 31 March 2025 (UTC)
::Ah... I thought it was a global thing. I was talking about the Albanian Wikipedia. - [[User:Klein Muçi|Klein Muçi]] ([[User talk:Klein Muçi|talk]]) 22:08, 31 March 2025 (UTC)
:::Upon further inspection I see that it IS a global thing. Every Wikipedia has a logo with inverted colors in their dark mode version. That is what I'm proposing to change. - [[User:Klein Muçi|Klein Muçi]] ([[User talk:Klein Muçi|talk]]) 22:23, 31 March 2025 (UTC)

== [https://en.wikipedia.org/wiki/Kia Kia] dark mode error ==


'''Issue Description'''
Section: Logo History
Logo in question: 2021 - present
Example photo 6
Logo hard to see in dark mode

== [https://en.wikipedia.org/wiki/Microsoft Microsoft] dark mode error ==


'''Issue Description''' Well in Wikipedia, when you search for Microsoft Corporation the color was a little bit off

== ✅ [https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Guild_of_Copy_Editors/How_to WikiProject Guild of Copy Editors/How to] dark mode error ==


'''Issue Description'''
The main content on this page seems to have had some of its styling overridden. Namely, it appears in a white box below two rows of what appear to be tabs. The content in the white box is mostly readable (although it of course does not obey the theme preference), but headings have an abysmal contrast ratio and I can barely discern the text within them without selecting them to create a blue highlight for contrast ratio (it would appear that their style is not overridden by the page-specific style and they are thus obeying my dark mode preference, at the expense of being able to read them).
:That page's tabs are using the default settings provided by Template:Start tab, which uses [https://en.wikipedia.org/wiki/Template:Tab Template:Tab] to build the tabs. That is the template that needs dark mode attention. [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:29, 1 May 2025 (UTC)

== ✅ [https://en.wikipedia.org/wiki/Wade–Giles Wade–Giles] dark mode error ==


'''Issue Description'''

The main image in the page "Wade-Giles" (his portrait) seems to be tagged as color-invertible somehow --- it becomes a negative when viewed in dark mode. I'm not sure whether this is an automated process or what, but the file is a regular old .jpg (https://en.wikipedia.org/wiki/Wade%E2%80%93Giles#/media/File:Herbert_Giles.jpg)
:This is because Infobox_romanization, uses Inbox_writing_system, which sets this by default, because it (somewhat rightly) assumes that all example images are script examples, not images of people related to the writing system. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 12:52, 1 May 2025 (UTC)
:: Now fixed —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 12:52, 1 May 2025 (UTC)

== ✅ [https://en.wikipedia.org/wiki/I_Corps_(Grande_Armée) I Corps (Grande Armée)] dark mode error ==


'''Issue Description'''
The heading for 'order of battle' is incredibly difficult to read as it is a slightly lighter shade of grey, and hitting show for the order of battle also yields a list that is extremely hard to read.

== [https://en.wikipedia.org/wiki/Wikipedia:Community_response_to_the_Wikimedia_Foundation's_ban_of_Fram Community response to the Wikimedia Foundation's ban of Fram] dark mode error ==


https://en.wikipedia.org/wiki/Wikipedia:Community_response_to_the_Wikimedia_Foundation%27s_ban_of_Fram

This page has black on brown/green/black text, making some of it difficult to read, and most of it impossible to read.

== ✅ [https://en.wikipedia.org/wiki/Cardinal_vowels Cardinal vowels] dark mode error ==


'''Issue Description'''
Images with transparent backgrounds are displayed weirdly in dark mode.

== 📢 [https://en.wikipedia.org/wiki/Dark_horse Dark horse] dark mode error ==

'''Issue Description'''
The current dark mode is too high contrast like a bright white font on an almost black background.
I nicer (easier to read) dark mode has a light grey font on a dark grey background.

== 🐛 Dark mode CSS filter problems ==
{{tracked| T391800}}

A brightness filter for images overrides other CSS classes used to apply filters. In particular, it overrides <code>skin-invert</code> and <code>skin-invert-image</code>. For an example page see [[w:RiPP]].

I noticed this days ago, but was hoping whoever made the change would have noticed and addressed it or written about it somewhere I could find. Of course they haven't and I haven't found any writing on it. For example, they haven't bothered updating advice regarding the situations where these CSS filters like <code>skin-invert</code> are useful: [[Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Apply_filters_to_dark_images_with_transparent_background]].

The simplest fix for this would be to use a shade of gray for the background (like #ccc) rather than using a filter to adjust down the statically coloured --background-color-base-fixed (#fff). If design tokens must be used, go for --background-color-tab-list-item-framed--active until something more semantically meaningful can be added, as the tokens --background-color-backdrop-dark and --background-color-backdrop-light are not right for the job. Alternatively, arbitrarily increase the specificity of the CSS rules involving <code>skin-invert</code> or add <code>!important</code> to those rules.
{{collapse top|The CSS rule in question}}
<syntaxhighlight lang="CSS">@media screen {
html.skin-theme-clientpref-night .mw-parser-output > span.mw-default-size img,
html.skin-theme-clientpref-night section .mw-heading ~ div > span.mw-default-size img,
html.skin-theme-clientpref-night section > span.mw-default-size img,
html.skin-theme-clientpref-night dd > span.mw-default-size img,
html.skin-theme-clientpref-night p > span.mw-default-size img,
html.skin-theme-clientpref-night .mw-parser-output > figure[typeof="mw:File"] img,
html.skin-theme-clientpref-night section .mw-heading ~ div > figure[typeof="mw:File"] img,
html.skin-theme-clientpref-night section > figure[typeof="mw:File"] img,
html.skin-theme-clientpref-night dd > figure[typeof="mw:File"] img,
html.skin-theme-clientpref-night p > figure[typeof="mw:File"] img,
html.skin-theme-clientpref-night .mw-parser-output > figure[typeof="mw:File/Thumb"] img,
html.skin-theme-clientpref-night section .mw-heading ~ div > figure[typeof="mw:File/Thumb"] img,
html.skin-theme-clientpref-night section > figure[typeof="mw:File/Thumb"] img,
html.skin-theme-clientpref-night dd > figure[typeof="mw:File/Thumb"] img,
html.skin-theme-clientpref-night p > figure[typeof="mw:File/Thumb"] img,
html.skin-theme-clientpref-night .mw-parser-output > figure[typeof="mw:File/Frameless"] img,
html.skin-theme-clientpref-night section .mw-heading ~ div > figure[typeof="mw:File/Frameless"] img,
html.skin-theme-clientpref-night section > figure[typeof="mw:File/Frameless"] img,
html.skin-theme-clientpref-night dd > figure[typeof="mw:File/Frameless"] img,
html.skin-theme-clientpref-night p > figure[typeof="mw:File/Frameless"] img {
background-color: var(--background-color-base-fixed,#fff);
filter: brightness(0.8);
}</syntaxhighlight>
{{collapse bottom}} [[User:Synpath|Synpath]] ([[User talk:Synpath|talk]]) 18:29, 25 April 2025 (UTC)

== ✅ [https://en.wikipedia.org/wiki/Flags_of_North_America Flags of North America] dark mode error ==


'''Issue Description'''
none of the text in the tables in the sections "Flags of North American sovereign states" or "Flags of dependencies and other territories in North America" is visible

== ❓[https://en.wikipedia.org/wiki/Main_Page Main Page] dark mode error ==


'''Issue Description'''
make more dark the dark mode

== ❓[https://en.wikipedia.org/wiki/Draft:Titus_Kofi_Beyuo Titus Kofi Beyuo] dark mode error ==


'''Issue Description'''

== ✅ [https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Disambiguation_pages#Introductory_line MOS:DAB] dark mode error ==


'''Issue description:'''
It seems like many of the block indents' text fully blend in with the background when using dark mode.
:Fixed with https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Disambiguation_pages&diff=prev&oldid=1288253230 —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:15, 1 May 2025 (UTC)

== [https://en.wikipedia.org/wiki/Main_Page Main Page] Dunkelmodus-Fehler ==


'''On the English Wiki-Main Page, the "Wikipedia languages" part, the languages are unreadable. https://en.wikipedia.org/wiki/Main_Page'''

== [https://en.wikipedia.org/wiki/Identity_(mathematics) Identity (mathematics)] dark mode error ==


'''Issue Description'''
The LaTeX mathematical equations are black with white highlighting in dark mode in the side info panel under the visual representation of the cos²θ + sin²θ = 1 identity.

== [https://en.wikipedia.org/wiki/Médecins_Sans_Frontières Médecins Sans Frontières] dark mode error ==


'''Issue Description''' The text in the logo in the infobox is very difficult to read in dark mode.

== [https://en.wikipedia.org/wiki/Special:Watchlist Watchlist] dark mode error ==


'''Issue Description'''

== [https://en.wikipedia.org/wiki/Timeline_of_the_telephone Timeline of the telephone] dark mode error ==


'''Issue Description'''
When you hover over a citation link with JavaScript enabled on the new UI with Dark Mode enabled, you can't see the little down arrow at the bottom of the pop-up.
Image: https://silvanzwick.com/847296.png

== [https://en.wikipedia.org/wiki/English_language English language] dark mode error ==


'''Issue Description'''
The familycolor in Language Infoboxes doesn't show on Dark Mode for all colors.

== [https://en.wikipedia.org/wiki/Dwayne_Johnson Dwayne Johnson] dark mode error ==


'''Issue Description''' nothing is wrong, but the bell icon and notices icon become super dark when hovering over them

== [https://en.wikipedia.org/wiki/1983_Air_Force_Falcons_football_team 1983 Air Force Falcons football team] dark mode error ==


'''Issue Description'''

Article - 1983 Air Force Falcons football team. The part that was hard to read is the "Schedule" section and the table in it. The white text on pastel yellow and pink boxes is completely illegible. It is in the 1st, 3rd, 5th, 6th, and 7th boxes.

== [https://en.wikipedia.org/wiki/Planetary_hours Planetary hours] dark mode error ==


'''Issue Description'''

''Platform:''
:Safari, iPadOS v18.3.2
:12.9" 6Th-generation iPad Pro

''Sections and text locations:''

* [https://en.wikipedia.org/wiki/Planetary_hours#History History], paragraph 2
* [https://en.wikipedia.org/wiki/Planetary_hours#Table_of_hours Table of hours]

     Astronomical symbols are hidden (black on black) on dark (black) background coloring but show up on light (white) background coloring. (The latter occurs in some cells in the table in the 'Table of hours' section of the problematic article. If Smart Invert is enabled on your device, then image colors are inverted and the situation reverses: previously-hidden symbols are now white and visible on the dark (black) background coloring and previously-visible symbols are now white and hidden on the light (white) background coloring (in those table cells as mentioned.)

— [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 06:52, 23 May 2025 (UTC)

Reading/Web/Accessibility for reading/Reporting/en.wikipedia.org

2025-05-23T06:51:00Z

RandomDSdevel: /* Planetary hours dark mode error */ new section

Requests for comment/CheckUser requirements

2016-09-09T20:23:21Z

RandomDSdevel: /* Background */ Improved this page's spelling, grammar, and readability in parallel with its Phabricator counterpart.

{{RFC
| component = CheckUser
| authors = {{u|Huji}}
| created = 2016-08-31
| bug =T139810
| status = in discussion
}}

In [https://phabricator.wikimedia.org/T139810 T139810] we have come to the conclusion that the best way to revamp the [[Extension:CheckUser|CheckUser extension]] is to come up with a list of desired features, then decide how to implement them (rewrite the code, patch parts of it, etc.) This RFC allows us to reach consensus about, dare we say, the CheckUser 2.0 (the future CheckUser extension).

== Background ==
Designed c. 2005, the extension is one of the critical tools that helps us to deal with problematic cases of abuse such as sock puppetry, vandalism, and spam ([[m:History_of_user_rights#CheckUser|see history here]]). As time went by, the needs of the projects increased, and, as we can see in the [[phab:project/view/203/|CheckUser work board]], the bugs accumulated without being resolved, primarily because its code, albeit old, also seems hard for developers to read and work with developers (refer to [https://phabricator.wikimedia.org/T132892 T132892: CheckUser UI revamp] and its related tasks, as well as the work board linked above).

== Problem ==
The lack of an active maintainer for the extension lowers development productivity in this area (i.e., bug resolution, testing and extension development ex Phabricator). One developer describes the CheckUser extension as follows: "the backend design is dubious, and the frontend is pretty archaic."

== Proposal ==
To resolve these issues, we think we need to think about overhauling the CheckUser extension. That overhaul should also be an opportunity to make the extension work with all the new features and the new code MediaWiki has at its current state. We can also take this opportunity to gather opinions from CheckUsers on which new functions the new CheckUser extension should have, etc.

Features needed:

* Sorting the results by IP (to make it easier to find common IP "ranges") as well as by time (currently, only the latter is supported).
* Getting a list of distinct [[En:User agent|user agents]] (UAs) used by a user.
** In fact, the "get IPs" function should be replaced by a "get summary" page which shows to you distinct IPs (sortable by time or by IP), distinct UAs (sortable by time or UA), and distinct IP-UA combinations (sorted by time or by IP).
* Providing additional information about UAs. Something like http://useragentstring.com/ or similar websites, would be the minimum. In the ideal world, the CheckUser tool should analyze the UA and show detailed information like:
** What browser, OS, etc. does the UA represent
** What year and month was that particular browser version released, and what year and month was a next version released (I find the date at which a user upgrades their browser a good clue for matching accounts or rejecting their similarity)
** Does it look like a valid or a forged UA?
* Providing additional information about IPs. For example, IP's ISP, its country, and the ISP's range. Of course this information changes over time, and is not publicly and freely available. However, the CheckUser code should be modified such that you could "extend" it by providing a CSV file containing IP-to-country and/or IP-to-ISP mappings. That way, we don't need to publish such a mapping as part of the code, but major users of the CheckUser tool such as WMF can pay for proprietary mappings and use them for their wiki.

Edit Review Improvements

2016-07-05T22:19:43Z

RandomDSdevel: /* Solutions */ Removed an unnecessary comma from the date stamp at the end of the first sentence.

<languages />
{{ptag|edit-review-improvements}}
{{Wikimedia engineering project information
| name = Edit Review Improvements
| description = Improve the edit-review process for good-faith new users.
| start = 2016-07-05
| end =
| group = {{ll|Collaboration|Collaboration}}
| EPM = [[User:JMatazzoni (WMF)|Joe Matazzoni]] (product manager), [[User:catrope|Roan Kattouw]] (engineering manager)
| team = Development team - [[User:sbisson_(WMF)|Stephane Bisson]], [[User:Trizek_(WMF)|Benoît Evellin]], [[wmf:User:Mattflaschen (WMF)|Matthew Flaschen]], [[User:Pginer-WMF|Pau Giner]], [[User:catrope|Roan Kattouw]], [[User:JMatazzoni (WMF)|Joe Matazzoni]], [[User: mooeypoo| Moriel Schottlender]], [[User: etonkovidova|Elena Tonkovidova]], [[User:Quiddity (WMF)|Nick Wilson]], [[User:Halfak (WMF)|Aaron Halfaker]]
| previous =
| next =
| projectpage = Content translation
| phabricator = edit-review-improvements
| display = {{{display|}}}
}}
<translate>

Edit Review Improvements is a project of the [[Collaboration]] Team, which is researching ways to reduce the negative effects current edit-review processes can have on new editors to the wikis.</translate>
<translate>

Most edit-review and patrolling tools were designed to safeguard content quality and fend off bad actors—both vitally important missions.</translate>
<translate>

A [[<tvar|1>#Related documents</>|body of research]], however, suggests that these processes, particularly when they involve automated or semi-automated tools, can have the unintended consequence of discouraging and even driving away good-faith new editors.


To solve this problem, Collaboration Team is investigating ways to separate good-faith new users from current edit-review workflows and, ultimately, to provide a supportive review process that helps new users become productive contributors.

== Problem == 
</translate>
* <translate>
Research shows that for new wiki editors in particular, “being reverted predicts both a decrease in activity and a reduction in the probability of survival” as editors.<ref>Halfaker, A., Kittur, A., & Riedl, J. (2011, October). [https://www-users.cs.umn.edu/~halfak/publications/Don%27t_Bite_the_Newbies/halfaker11bite-personal.pdf Don't bite the newbies: how reverts affect the quantity and quality of Wikipedia work.] In Proceedings of the 7th international symposium on wikis and open collaboration (pp. 163-172). ACM.</ref></translate>
* <translate>
At the same time, the increasing use of automated and semi-automated edit-review tools has brought about an increase in rejection of good-faith newcomers.</translate> <translate>
The use of these tools “significantly increases the negative effect of rejection on desirable newcomer retention.”<ref>“Several changes the Wikipedia community made to manage quality…have ironically crippled the very growth they were designed to manage. Specifically...the algorithmic tools used to reject contributions are implicated as key causes of decreased newcomer retention.” Halfaker, A., Geiger, R. S., Morgan, J. T., & Riedl, J. (2012). [https://www-users.cs.umn.edu/~halfak/publications/The_Rise_and_Decline/halfaker13rise-preprint.pdf The rise and decline of an open collaboration system: How Wikipedia’s reaction to popularity is causing its decline]. American Behavioral Scientist, 0002764212469365.</ref></translate>
* <translate>
The above notwithstanding, edit-review tools are essential for vandalism fighters and others working to maintain wiki integrity and quality.</translate> <translate>
How can we help and retain new users while maintaining the productivity of vandalism fighters and other edit reviewers?

== Goals == 
</translate>
* <translate>
Ensure good-faith new editors have more constructive, less discouraging experiences of edit and article review.</translate>
* <translate>
By providing richer data about recent changes, enable patrollers and edit-reviewers of all types to work more efficiently and to pursue diverse interests (e.g., fighting vandalism, supporting new users)  in a more effective and targeted way.</translate>
<translate>
Ultimately this project aims to have an effect on editor retention, an objective that aligns well with the overall goals of the [[m:Wikimedia Foundation Annual Plan/2016-2017/revised|Wikimedia Foundation 2016-17 Annual Plan]], developed in close consultation with the user community.</translate>
<translate>

The approach tracks in particular with the goals the Annual Plan lays out for the Product Team, which promise, among other things, to “Invest in new types of content…curation and collaboration tools.”

== Solutions == 


This project is in a research phase and no concrete product plans have been formalized as of this writing (in June 2016).</translate>
<translate>

To begin to address the problems of struggling but good-faith newcomers, however, a good first step will be to ensure that we can find them.</translate>
<translate>

The [[Wikimedia Engineering/2016-17 Q1 Goals|Collaboration Team’s quarterly goal]] for the first quarter of 2016-2017 (July-September 2016) is to “create a process that enables edit-reviewers to identify the edits of good-faith new users, so that these edits can be reviewed separately.”


To achieve this, we propose to analyze recent changes using data from a variety of sources, including and most notably the machine-learning program ORES ([[m:Objective Revision Evaluation Service|Objective Revision Evaluation Service]]).</translate>
<translate>

ORES’s [[m:Objective Revision Evaluation Service/goodfaith|good faith model]], trained on human judgement, can find 95% of good-faith edits with 98% accuracy.</translate>
<translate>

ORES can also predict edits that will be [[m:Objective Revision Evaluation Service/reverted|reverted]] and those that are [[m:Objective Revision Evaluation Service/damaging|damaging]] to the wikis.


While research shows that new editors are particularly vulnerable to rejection, there’s also evidence that edit-review and even rejection can be a powerful learning experience for newcomers.<ref>“We found that newcomers are particularly likely to decrease their contributions after they are reverted. We also saw some evidence that they can learn the most from being reverted. Newcomers should be reached out to actively to help them become socialized into Wikipedia.” Halfaker, A., Kittur, A., & Riedl, J. [https://www-users.cs.umn.edu/~halfak/publications/Don%27t_Bite_the_Newbies/halfaker11bite-personal.pdf Don't bite the newbies: how reverts affect the quantity and quality of Wikipedia work.] </ref> For reviewers interested in supporting new users, then, a stream of edits that are a) likely to be reverted but which were b) made in good faith will, we hope, represent a string of teachable moments.


The edit analysis described above may be presented to users in a number of ways, including:
</translate>
* <translate>
On a dedicated page similar to PageTriage's [[w:en:Special:NewPagesFeed|Special:NewPagesFeed]].</translate>
* <translate>
On Recent Changes and/or Watchlist via filters.</translate>
* <translate>
In machine-readable feeds that can be ingested by edit-review programs (e.g. Huggle/Snuggle/STiki/etc.).

== Current activity == 
</translate>
* <translate>
To visualize possible product directions, the Collaboration Team is [[phab:T137783|exploring design concepts]] while continuing to research the issues.</translate>
* <translate>
To better gauge the size of the problem and be able to track progress, we’re working to to define and [[phab:T137824|measure new-editor retention]].</translate>

* <translate>
[[Wikimedia Research/Design Research|Design Research]] is [[m:Research:New editor support strategies|organizing and conducting interviews]] with users touched by this issue in various ways, to better understand their motivations and workflows.</translate> <translate>
Groups who will be interviewed in the near term include: anti-vandalism patrollers, recent changes patrollers, Teahouse hosts, Welcoming Committee members, and AfC reviewers.</translate>
* <translate>
The [[Wikimedia Research/Research and Data|Research and Data]] team is working to make predictions better by refining the accuracy of prediction models.</translate>

* <translate>
There was a [[wm2016:Discussions/Quality tools|discussion of the project]] at Wikimania 2016, in June

== Future plans == 


Creating the streams/pages of “teachable moments” described above has the potential to establish edit-review as a new space for instructing and supporting new editors.</translate>
<translate>

The mere existence of such a platform, however, won’t in itself ensure that this new practice will take root.</translate>
<translate>

To truly have an impact on newcomer retention, interventions may be required at multiple points in the editing and review cycles: before publication, to spot problems and enable authors to seek help; during review, to facilitate a constructive process; and even after review, to help new users overcome rejection and learn from from their experiences.


In addition to exploring ideas for intervening at various points, we’re pursuing answers to questions such as these:
</translate>
* <translate>
How can we bring reviewers to this new activity?</translate>
* <translate>
What would make reviewers most effective in the job of supporting newcomers during edit review?</translate>
* <translate>
How can we make the process rewarding for reviewers, so that they stay involved?


The counter-vandalism community also has an important role to play in this arena.</translate>
<translate>

Richer data about edits and editors should make patrollers of all types not only more discriminating about which edits might be in good faith, but also more efficient at their job of combating harm.</translate>
<translate>

It will be important to work closely with vandalism fighters and others to understand how their processes and tools might best be adapted to realize these potential gains.

== Principles == 


As we pursue this project, the following principles will guide our planning.
</translate>
* <translate>
'''Smart but human'''. Use technology to support rather than replace human interaction. Artificial intelligence can provide analysis, but humans should make decisions.</translate>
* <translate>
'''Cross-community'''. Find solutions that will work across language groups and projects, rather than building wiki-specific tools.</translate>
* <translate>
'''Platform not feature'''. Seek solutions that are extensible and reusable by current and future community-created and WMF tools.</translate>
* <translate>
'''Mobile'''. Although edit-review is not currently popular on mobile, consider mobile users carefully in our plans.</translate>
* <translate>
'''Adoption'''. In addition to creating new technology, focus on finding ways to encourage reviewers to adopt and continue to use the new tools.</translate>
* <translate>
'''Integration'''. In seeking new solutions, build on and integrate with existing practices whenever possible.</translate>
* <translate>
'''Incremental approach'''. As we move into this new area, proceed incrementally to each milestone and then evaluate where to go next.</translate>
* <translate>
'''Participatory design'''. Collaborate with editors and tool developers already working in this space.
</translate>

{{anchor|Related documents}}
<translate>
== Related documents == 
</translate>
* [[m:Grants:IdeaLab/Fast and slow new article review|Grants:IdeaLab/Fast and slow new article review]]
* [[m:Research:Newcomer survival models|Research:Newcomer survival models]]
<references />

[[Category:New Editor Engagement{{translation}}]]

Topic:Se2z4gnt6uedykci

2015-03-24T16:39:49Z

RandomDSdevel (talk | contribs) commented on "Still active?" (Ha! I see what you did there, and I like your sense of humor.)

Talk:Winter/Archive 2/Flow export

2015-03-24T16:39:49Z

RandomDSdevel: /* Still active? */ Added reply

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. :-( [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 2014 (UTC)
:see also: [[phab:T85247|T85247 VisualEditor incompatible with "Fixed header" beta feature]] [[User:Se4598|se4598]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=2014_Toray_Pan_Pacific_Open_%E2%80%93_Singles this one] or [http://unicorn.wmflabs.org/winter/index.html?page=United_States_House_of_Representatives_elections,_2014 that one]. [[User:Zebulon84|Zebulon84]] ([[User talk: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. [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:Ypna|Ypna]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk: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. [[User:Ypna|Ypna]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk: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. [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk:Quiddity (WMF)|talk]]) 21:46, 18 December 2014 (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? [[User:Felistoria|Felistoria]] ([[User talk: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. [[User:Sillyfolkboy|Sillyfolkboy]] ([[User talk: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 [https://en.wikipedia.org/wiki/User_talk:Sillyfolkboy/TemplateSandbox 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). [[User:Sillyfolkboy|Sillyfolkboy]] ([[User talk: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? [[User:1989|1989]] ([[User talk:1989|talk]]) 14:17, 27 January 2015 (UTC)

== Still active? ==

:Is this still an active project? [[User:Kghbln|[[kgh]]]] ([[User talk:Kghbln|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 [[User:Tar_Lócesilion|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|MediaWiki UI]] and [https://phabricator.wikimedia.org/project/board/24/ UI Standardization Board] in Phabricator might shed more light on where things are going. [[User:Ckoerner|Ckoerner]] ([[User talk: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). [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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... [[User:Kghbln|[[kgh]]]] ([[User talk:Kghbln|talk]]) 16:41, 23 March 2015 (UTC)
:::Ha! I see what you did there, and I like your sense of humor. [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 16:39, 24 March 2015 (UTC)

User:RandomDSdevel

2015-03-24T16:38:18Z

RandomDSdevel: /* Сергей Бюргер */ Removed this section because it was spam (I didn't add it in the first place.)

Topic:S40dy25lag60j2je

2015-03-18T17:29:42Z

RandomDSdevel (talk | contribs) hid a post on "Weird Sidebar Behavior" (Reverted to previous status. (Now I know why it was hidden: somebody was being rude…) )

Talk:Winter/Archive 2/Flow export

2015-03-18T17:29:42Z

RandomDSdevel: /* Weird Sidebar Behavior */ Reverted to previous status. (Now I know why it was hidden: somebody was being rude…)

Topic:S40dy25lag60j2je

2015-03-18T17:29:01Z

RandomDSdevel (talk | contribs) restored a post on "Weird Sidebar Behavior" (The reason I'm unhiding this post is so that I can see its content so that I can determine why it was hidden in the first place. After I have viewed this content, I will hide it again. )

Talk:Winter/Archive 2/Flow export

2015-03-18T17:29:01Z

RandomDSdevel: /* Weird Sidebar Behavior */ The reason I'm unhiding this post is so that I can see its content so that I can determine why it was hidden in the first place. After I have viewed this content, I will hide it again.

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:24, 11 October 2014 (UTC)
:Fu [[Special:Contributions/216.4.56.150|216.4.56.150]] ([[User talk:216.4.56.150|talk]]) 15:00, 14 March 2015 (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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. :-( [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 2014 (UTC)
:see also: [[phab:T85247|T85247 VisualEditor incompatible with "Fixed header" beta feature]] [[User:Se4598|se4598]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=2014_Toray_Pan_Pacific_Open_%E2%80%93_Singles this one] or [http://unicorn.wmflabs.org/winter/index.html?page=United_States_House_of_Representatives_elections,_2014 that one]. [[User:Zebulon84|Zebulon84]] ([[User talk: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. [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:Ypna|Ypna]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk: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. [[User:Ypna|Ypna]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk: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. [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk:Quiddity (WMF)|talk]]) 21:46, 18 December 2014 (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? [[User:Felistoria|Felistoria]] ([[User talk: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. [[User:Sillyfolkboy|Sillyfolkboy]] ([[User talk: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 [https://en.wikipedia.org/wiki/User_talk:Sillyfolkboy/TemplateSandbox 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). [[User:Sillyfolkboy|Sillyfolkboy]] ([[User talk: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? [[User:1989|1989]] ([[User talk:1989|talk]]) 14:17, 27 January 2015 (UTC)

Topic:S40e3725xrrl3hcq

2014-12-16T00:28:39Z

RandomDSdevel (talk | contribs) commented on "On the Behavior of Wikipedia's Logo in Winter" (Well, curse our luck! Would the powers that be possibly consider separating this text out like I suggested above? Like I said before, tha...)

Talk:Winter/Archive 2/Flow export

2014-12-16T00:28:39Z

RandomDSdevel: /* On the Behavior of Wikipedia's Logo in Winter */ Added reply

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. :-( [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 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 [http://unicorn.wmflabs.org/winter/index.html?page=2014_Toray_Pan_Pacific_Open_%E2%80%93_Singles this one] or [http://unicorn.wmflabs.org/winter/index.html?page=United_States_House_of_Representatives_elections,_2014 that one]. [[User:Zebulon84|Zebulon84]] ([[User talk: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. [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:Ypna|Ypna]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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. [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk:Quiddity (WMF)|talk]]) 19:10, 15 December 2014 (UTC)

Topic:S5vjp0b3xk5zsiqm

2014-12-11T23:49:31Z

RandomDSdevel (talk | contribs) commented on "Large tables" (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...)

Talk:Winter/Archive 2/Flow export

2014-12-11T23:49:31Z

RandomDSdevel: /* Large tables */ Added reply

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 23:43, 11 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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 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 [http://unicorn.wmflabs.org/winter/index.html?page=2014_Toray_Pan_Pacific_Open_%E2%80%93_Singles this one] or [http://unicorn.wmflabs.org/winter/index.html?page=United_States_House_of_Representatives_elections,_2014 that one]. [[User:Zebulon84|Zebulon84]] ([[User talk: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. [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 23:49, 11 December 2014 (UTC)

Topic:S40e3725xrrl3hcq

2014-12-11T23:43:27Z

RandomDSdevel (talk | contribs) commented on "On the Behavior of Wikipedia's Logo in Winter" (Why would creating a bunch of new, but differently sized, image files from ones that currently exist be so hard? Do the logos' image file...)

Talk:Winter/Archive 2/Flow export

2014-12-11T23:43:27Z

RandomDSdevel: /* On the Behavior of Wikipedia's Logo in Winter */ Added reply

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 23:43, 11 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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 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 [http://unicorn.wmflabs.org/winter/index.html?page=2014_Toray_Pan_Pacific_Open_%E2%80%93_Singles this one] or [http://unicorn.wmflabs.org/winter/index.html?page=United_States_House_of_Representatives_elections,_2014 that one]. [[User:Zebulon84|Zebulon84]] ([[User talk:Zebulon84|talk]]) 23:58, 10 November 2014 (UTC)

Manual:$wgAllowSiteCSSOnRestrictedPages

2014-11-26T23:42:22Z

RandomDSdevel: /* Details */ Refactored to improve spelling, grammar, mechanics, word usage, word order, sentence order, paragraph flow, and readability.

{{Future|1.25.0}}
{{SettingSummary
|name = AllowSiteCSSOnRestrictedPages
|version_min = 1.25.0
|sha_introduced=I1bf4dd1845b6952c3985e179fbea48181ffb8907
|section = Frontend
|range = (boolean)
|default = false
|summary = Allow side-wide Cascading Style Sheets (CSS) on restricted special pages
}}

==Details==
This configuration setting allows wikis to re-enable site-wide CSS on restricted special pages, which is (as of MediaWiki versions 1.19.20, 1.22.12, and 1.23.5) disabled by default due to security concerns discussed in [[bugzilla:70672|bug 70672]], site-wide CSS was disabled starting with MediaWiki versions 1.19.20, 1.22.12 and 1.23.5. Many wikis use pages like [[MediaWiki:Common.css]] to create a custom 'theme' for their wiki, but the fact that this change has been implemented makes it so that, by default, such style sheets no longer load on [[Special:UserLogin|login]] or [[Special:Preferences|preference pages]], thus creating an inconsistent user interface.

==See also==
*[[Manual:Skins]]
*[[Manual:$wgUseSiteCss]]

{{languages}}

Topic:S40e3725xrrl3hcq

2014-11-09T01:01:56Z

RandomDSdevel (talk | contribs) commented on "On the Behavior of Wikipedia's Logo in Winter" (Hmm…you're probably right in saying that creating so many horizontal labels (they're for the various languages in which Wikipedia is avai...)

Talk:Winter/Archive 2/Flow export

2014-11-09T01:01:56Z

RandomDSdevel: /* On the Behavior of Wikipedia's Logo in Winter */ Added reply

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk: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. :) –[[User:Quiddity|Quiddity]] ([[User talk: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:
:* [http://www.washingtonpost.com/blogs/worldviews/wp/2014/10/09/bettors-have-already-picked-a-winner-for-the-nobel-peace-prize/ Washington Post]
:* [https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c Medium]
:* [http://happycog.com/ Happycog] ([//en.wikipedia.org/wiki/Jeffrey%20Zeldman Zeldman]'s design studio)
:* (same idea implemented with headroom.js [http://blog.templatemonster.com/demos/how-to-code-a-fixed-auto-hiding-nav-bar-with-javascript/demo/index.html demo] - [http://blog.templatemonster.com/2014/07/21/how-to-code-fixed-auto-hiding-nav-bar-with-javascript/ code])
:; Standard fixed headers:
:* [https://mail.google.com/ gmail]
:* [https://www.youtube.com/ youtube]
:* [https://facebook.com/ facebook]
:* [https://twitter.com/ twitter]
:* link-deluge of smaller sites and commentary at [http://blog.teamtreehouse.com/fixed-headers-and-navigation-bars-used-in-web-design teamtreehouse] and [http://www.awwwards.com/fixed-navigation-bars-pros-and-cons.html awwwards] –[[User:Quiddity|Quiddity]] ([[User talk: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: [http://css-tricks.com/examples/PersistantHeaders/ demo] - [http://css-tricks.com/persistent-headers/ code] –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:05, 12 October 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)
:[[File:Wp logo unified horiz rgb.svg|180x180px]]
: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. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 01:01, 9 November 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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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. ~[[User:PJosepherum|Φנσѕєρнєяυм]] [[User:PJosepherum|w]]•[[User_talk:PJosepherum|t]]•[[Special:Contributions/PJosepherum|c]] 19:51, 19 October 2014 (UTC)
::Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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 [[User:Ragesoss|Ragesoss]] ([[User talk:Ragesoss|talk]]) 18:24, 22 October 2014 (UTC)

Topic:S40f4v4l2dsl1t7f

2014-10-11T20:46:11Z

RandomDSdevel (talk | contribs) commented on "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 us...)

Talk:Winter/Archive 2/Flow export

2014-10-11T20:46:11Z

RandomDSdevel: /* On the Location of Articles' Tables of Contents */ New section

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:02, 21 May 2014 (UTC)

== Fixed header also in Special:Translate ==

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. :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:13, 22 May 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:46, 11 October 2014 (UTC)

Topic:S40f1v3n7b2vfl9b

2014-10-11T20:44:41Z

RandomDSdevel (talk | contribs) commented on "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 alo...)

Talk:Winter/Archive 2/Flow export

2014-10-11T20:44:41Z

RandomDSdevel: /* Improved or Different Header Views? */ New section

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:02, 21 May 2014 (UTC)

== Fixed header also in Special:Translate ==

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. :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:13, 22 May 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 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… [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:44, 11 October 2014 (UTC)

Topic:S40e3725xrrl3hcq

2014-10-11T20:27:24Z

RandomDSdevel (talk | contribs) commented on "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 pr...)

Talk:Winter/Archive 2/Flow export

2014-10-11T20:27:24Z

RandomDSdevel: /* On the Behavior of Wikipedia's Logo in Winter */ New section

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:02, 21 May 2014 (UTC)

== Fixed header also in Special:Translate ==

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. :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:13, 22 May 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:27, 11 October 2014 (UTC)

Topic:S40dy25lag60j2je

2014-10-11T20:24:50Z

RandomDSdevel (talk | contribs) commented on "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 sh...)

Talk:Winter/Archive 2/Flow export

2014-10-11T20:24:50Z

RandomDSdevel: /* Weird Sidebar Behavior */ New section

{{flow imported revision}}
{{Flow-enabled}}
Previous discussion is archived at [[Talk:Winter/Archive 1]].

== Bunched edit links ==
{{Archive top|result=All fixed.|status=resolved}}

: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:04, 19 February 2014 (UTC)
::[[User:TheDJ|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:15, 21 February 2014 (UTC)
::I wonder if TheDJ is talking about [[:File:Winter prototype edit link cluster.png]]? [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:19, 26 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: Oh, shizzit! That's perfect. I can play with that one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:44, 26 February 2014 (UTC)
::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Hail 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:01, 27 February 2014 (UTC)
::[[User:Sven Manguard|Sven Manguard]]: I actually fixed it in my version, and I'll upload it probably early next week. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:09, 27 February 2014 (UTC)
::[[User:Sven Manguard|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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 03:31, 22 February 2014 (UTC)
::[[User:This, that and the other|This, that and the other]]: Thanks! That's exactly what I'm looking for. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 06:37, 22 February 2014 (UTC)
{{Archive bottom}}

== Amboxes ==
{{Archive top|result=Bug about enwiki css that should be fixed.|status=resolved}}

I see, amboxes is not separated from the article body. It's bad. [[User:Tucvbif|Tucvbif]] ([[User talk:Tucvbif|talk]]) 17:23, 21 February 2014 (UTC)
:That is because they are templates, which are always part of content. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:12, 21 February 2014 (UTC)
{{Archive bottom}}

== First User Test Battery Results ==
{{Archive top|result=Results of previous tests.|status=resolved}}

The first battery of user tests have completed against the Winter prototype. I have included links to all of them in the [[Winter#Harness_One:_Winter|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 22:03, 13 March 2014 (UTC)
::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:44, 14 March 2014 (UTC)
{{Archive bottom}}

== Second User Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:11, 15 March 2014 (UTC)
{{Archive bottom}}

== Third and Fourth Test Battery Results ==
{{Archive top|result=Results of previous test batteries.|status=resolved}}

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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 20:19, 19 March 2014 (UTC)
::[[User:Amire80|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:31, 19 March 2014 (UTC)
:::[[User:Jorm (WMF)|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 [http://en.wikipedia.org/wiki/Template:Tmbox Template:Tmbox]-style formatting is stripped away, the visual clues that this is maintenance top matter also get stripped away. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 05:47, 26 March 2014 (UTC)
:::[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:44, 26 March 2014 (UTC)
{{Archive bottom}}

== Clock ==
{{Archive top|result=No need for a clock.|status=resolved}}

: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 [http://bulbapedia.bulbagarden.net/wiki/Main_Page 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk: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 [[User:Sven Manguard|Sven Manguard]] ([[User talk: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. [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk:Ciencia Al Poder|talk]]) 09:36, 28 April 2014 (UTC)
::[[User:Ciencia Al Poder|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 03:20, 30 April 2014 (UTC)
{{Archive bottom}}

== Typography refresh ==
{{Archive top|result=Typography refresh is now in the default showcase.|status=resolved}}

Could the typography changes be applied to Winter so that the prototype represents more closely what this interface would look like? [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 20:42, 4 April 2014 (UTC)
:[[User:Julia W|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 01:01, 5 April 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Oh, yeah, thank you! Not easy to see. Sorry for the stupid question. :) [[User:Julia W|Julia]]\[[User_talk:Julia W|talk]] 23:33, 5 April 2014 (UTC)
{{Archive bottom}}

== Personal toolbar icons flickering ==
{{Archive top|result=Bug about flickering images. Fixed.|status=resolved}}

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. [[User:ATDT|ATDT]] ([[User talk:ATDT|talk]]) 19:24, 20 April 2014 (UTC)
:[[User:Ori.livneh|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:27, 20 April 2014 (UTC)
{{Archive bottom}}

== 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 [[User:Trizek|Trizek]] [[:fr:User talk:Trizek|from FR]] 19:33, 20 April 2014 (UTC)
:[[User:Trizek|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:48, 20 April 2014 (UTC)
:[[User:Trizek|Trizek]]: Version 0.6, released this evening, includes a "right rail" experiment which starts to do this. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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? [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 22:29, 20 April 2014 (UTC)
::[[User:Slowking4|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 23:49, 20 April 2014 (UTC)
::[[User:Slowking4|Slowking4]]: So, we redesigned infoboxes. And we changed the text flow around the ToC by moving the ToC into the header, as a menu. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:13, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:Slowking4|Slowking4]] ([[User talk: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. [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 13:42, 21 April 2014 (UTC)
:xoxo [[User:Slowking4|Slowking4]] ([[User talk:Slowking4|talk]]) 20:33, 15 July 2014 (UTC)

== TOC gets a little small ==

The TOC on pages with [http://unicorn.wmflabs.org/winter/index.html?page=HTML_element 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? [[User:MarkTraceur|MarkTraceur]] ([[User talk:MarkTraceur|talk]]) 16:18, 21 April 2014 (UTC)
:[[User:MarkTraceur|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:42, 21 April 2014 (UTC)
::[[User:Jorm (WMF)|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) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:56, 26 April 2014 (UTC)

== IE8 ==
{{Archive top|result=The Winter prototype doesn't work in IE.|status=resolved}}

:<nowiki>The popup "Welcome to Winter!" box doesn't work in IE8. Left column appears jumbled.~</nowiki> [[User:Geni|Geni]] ([[User talk:Geni|talk]]) 04:32, 22 April 2014 (UTC)
::[[User:Geni|Geni]]: The prototype is not designed to work with Internet Explorer, unfortunately. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:13, 5 May 2014 (UTC)
{{Archive bottom}}

== 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). [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:35, 23 April 2014 (UTC)
::[[User:Jay8g|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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 [https://news.google.com Google News] for an example. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 02:14, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: We're actually working out ways to get rid of the sidebar entirely. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:28, 29 April 2014 (UTC)
:Good idea. It could be useful especially combined with collapsible menu items. [[User:KuboF Hromoslav|KuboF Hromoslav]] ([[User talk: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). [[User:Jay8g|Jay8g]] ([[User talk: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. [[User:Nux|Nux]] ([[User talk:Nux|talk]]) 18:09, 5 May 2014 (UTC)

== Narrow screens and the search bar ==

[[File:Winter-test-narrow-searchbar.png|639x639px]]

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]. [[User:Verdy p|Verdy p]] ([[User talk: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! [[User:Ciencia Al Poder|Ciencia Al Poder]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 - [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead en:User:Rezonansowy/scripts/FloatHead]. [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 12:30, 28 April 2014 (UTC)
::[[User:Rezonansowy|Rezonansowy]]: This is being built on top of Vector, actually. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 02:03, 29 April 2014 (UTC)
:::[[User:Jorm (WMF)|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... [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 03:39, 29 April 2014 (UTC)
:::[[User:Jay8g|Jay8g]]: It will not be a separate skin. It's being implemented as an extension to the existing one. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://en.wikipedia.org/wiki/User:Rezonansowy/scripts/FloatHead FloatHead.css]
:* ''Larger Search Area'' - this could be done with CSS as well (see [http://en.wikipedia.org/wiki/User:Rezonansowy/common.css 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) [[User:Rezonansowy|Rezonansowy]] ([[User talk:Rezonansowy|talk]]) 18:05, 29 April 2014 (UTC)
::[[User:Rezonansowy|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [http://unicorn.wmflabs.org/winter/index.html?page=Errorr 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. [[User:Fauzan|Fauzan]] ([[User talk: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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[User:Ian Kelling|Ian Kelling]] ([[User talk:Ian Kelling|talk]]) 03:16, 3 May 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The code for this is extremely alpha and I'd suggest against installing it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:52, 3 May 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: I'd also like to install a clone, as a base for a future experimental feature (real time collaboration). [[Special:Contributions/50.163.53.37|50.163.53.37]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:40, 10 July 2014 (UTC)
:::50.163.53.37: Source code is available now. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:06, 14 July 2014 (UTC)
::[[User:Ian Kelling|Ian Kelling]]: The source is available now, and you can find it on [[Winter]]. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:07, 14 July 2014 (UTC)
:I'm a software developer. I might have some useful contribution to make. [[User:Ian Kelling|Ian Kelling]] ([[User talk: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. [[Special:Contributions/2003:63:2F35:5C00:1019:46FF:21C:56CF|2003:63:2F35:5C00:1019:46FF:21C:56CF]] ([[User talk: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 ''[http://en.wikipedia.org/wiki/Three%20Studies%20for%20Figures%20at%20the%20Base%20of%20a%20Crucifixion Three Studies for Figures at the Base of a Crucifixion]'' or [http://en.wikipedia.org/wiki/List%20of%20cricketers%20who%20have%20scored%20centuries%20in%20both%20innings%20of%20a%20Test%20match 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. –[[User:Quiddity|Quiddity]] ([[User talk: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. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:07, 15 May 2014 (UTC)

== JavaScript and drop down menus ==

As Sven Manguard [https://www.mediawiki.org/w/index.php?title=Talk:Winter&workflow=rrmvqbu4azqu0xyz 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. [[User:Rastus Vernon|Rastus Vernon]] ([[User talk: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. [[Special:Contributions/137.147.156.9|137.147.156.9]] ([[User talk: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. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:05, 19 May 2014 (UTC)
::[[User:TheDJ|TheDJ]]: Also, it's written entirely in Javascript and CSS - at least the prototype. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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 [https://commons.wikimedia.org/wiki/File:Wikipedia_vision-1.png this image]. Is there a future for this idea, either in Winter or elsewhere? [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:29, 20 May 2014 (UTC)
::[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:42, 21 May 2014 (UTC)
::[[User:JamesDouch|JamesDouch]]: Version 0.6, deployed this evening, has this feature. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:05, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: How do you enable it? I don't see anything in the interface about it... [[Special:Contributions/128.29.43.2|128.29.43.2]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 17:52, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Will it move images over? That would make use of the empty space and declutter the body text. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 11:25, 16 July 2014 (UTC)
:Great! And great work with Winter. (Edit: Oops, it appears I clicked the wrong reply button) [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:02, 21 May 2014 (UTC)

== Fixed header also in Special:Translate ==

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. :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:13, 22 May 2014 (UTC)

== Watchlist icon hidden ==
{{Archive top|result=Bug is fixed in the deployed version.|status=resolved}}

http://i.imgur.com/RZxg9qt.png does anybody else notice this? It should be on the top bar. [[User:Swordman97|Swordman97]] ([[User talk:Swordman97|talk]]) 17:37, 19 June 2014 (UTC)
:[[User:Swordman97|Swordman97]]: That's actually a bug in that specific version of Winter. It will get fixed in the next version. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:54, 19 June 2014 (UTC)
{{Archive bottom}}

== Could this be used to keep TOC from scrolling page ==
{{Archive top|result=Thoughts about fixing a specific bug with the header ToC.|status=resolved}}

https://github.com/Robdel12/DropKick [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 21:03, 28 June 2014 (UTC)
:[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: No; this only works on SELECT tags and the ToC is significantly more complicated. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:05, 2 July 2014 (UTC)
{{Archive bottom}}

== Opt-out ==

Will there be a way to opt out of this while still using Vector? That is to say, keep using "old" Vector? [[User:BethNaught|BethNaught]] ([[User talk:BethNaught|talk]]) 09:53, 12 July 2014 (UTC)
:[[User:BethNaught|BethNaught]]: Winter will be more "opt-in" than "opt-out" for a time, and then it will be opt-out, I should imagine. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 21:08, 13 July 2014 (UTC)
::[[User:Etesp|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 22:26, 13 July 2014 (UTC)
:::[[User:Jorm (WMF)|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 :). [[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 00:48, 14 July 2014 (UTC)
::[[User:Etesp|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? [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. [[User:Etesp|etesp]] ([[User talk: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. [[Special:Contributions/71.19.177.226|71.19.177.226]] ([[User talk: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. [[Special:Contributions/124.180.202.60|124.180.202.60]] ([[User talk: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. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 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. [[User:Nouill|Nouill]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 15:10, 14 July 2014 (UTC)
:[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[Special:Contributions/2001:981:8932:1:B5BA:249B:CDE3:71E3|2001:981:8932:1:B5BA:249B:CDE3:71E3]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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.) [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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! [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Slashme|Slashme]] ([[User talk:Slashme|talk]]) 18:02, 14 July 2014 (UTC)
::[[User:Slashme|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). [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:John Broughton|John Broughton]] ([[User talk: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 [//en.wikipedia.org/wiki/Microcephaly Wikipedia:Microcephaly] appears broken in Winter. The bullets on it appear all wrong. [[User:Zellfaze|Zellfaze]] ([[User talk: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.
:[[User:Jorm (WMF)|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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 19:02, 14 July 2014 (UTC)
::[[User:Amire80|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:04, 14 July 2014 (UTC)
:::[[User:Jorm (WMF)|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. [[User:EdSaperia|EdSaperia]] ([[User talk: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). [[User:John Broughton|John Broughton]] ([[User talk: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? [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:07, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:23, 14 July 2014 (UTC)
:Ah, the problem is on the radar already. :-) Great. [[User:Ziko|Ziko]] ([[User talk: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.? [[User:Ziko|Ziko]] ([[User talk: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. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 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:" [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:20, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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". [[User:Ziko|Ziko]] ([[User talk: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. [[User:Ziko|Ziko]] ([[User talk:Ziko|talk]]) 19:25, 14 July 2014 (UTC)
::[[User:Ziko|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 20:20, 14 July 2014 (UTC)
:Hm. "Last change made X days ago"? [[User:Ziko|Ziko]] ([[User talk: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 [[User:Racso|Racso]] ([[User talk: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. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 05:09, 15 July 2014 (UTC)

== <li> 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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk:Magnus Manske|talk]]) 18:19, 15 July 2014 (UTC)
:[[User:Magnus Manske|Magnus Manske]]: Oooh, pretty. The style of the current ones comes right out of enwiki's Common.css, which explains a lot. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 18:54, 15 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:32, 15 July 2014 (UTC)
::Yes, I was. That must have been the problem. I'll try again later. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 19:09, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 19:31, 15 July 2014 (UTC)
:[[User:CaptainPedge|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. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 20:42, 15 July 2014 (UTC)
:[[User:Ckoerner|Ckoerner]]: The editor designs in Winter are the current thinking of where both of our editors should be heading. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 05:52, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Ah, that makes sense. You all are doing yeoman’s work! [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 14:24, 16 July 2014 (UTC)

== Screen width ==

http://i.imgur.com/8TkkQLP.png - Need I say more? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:03, 15 July 2014 (UTC)
:[[User:CaptainPedge|CaptainPedge]]: I ''just now'' - like, less than 5 minutes ago - uploaded a fix for that. Shift-refresh and you should see it. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:10, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: Fair enough :)
::What about the whitespace underneath the right hand sidebar? [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:19, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: I'll have to take a look. I'm not seeing it at my current configuration. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:20, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: http://i.imgur.com/hLaaZp0.png [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:40, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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 :) [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 21:47, 15 July 2014 (UTC)
::[[User:CaptainPedge|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:53, 15 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 22:02, 15 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Winter does look a lot better when looking at a specific article, like say [http://unicorn.wmflabs.org/winter/index.html?page=Scotland Scotland] as an example. That right bar doesn't appear as awkward.
::[[User:Jorm (WMF)|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. [[User:Ckoerner|Ckoerner]] ([[User talk:Ckoerner|talk]]) 15:50, 17 July 2014 (UTC)
::[[User:Ckoerner|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. [[User:CaptainPedge|CaptainPedge]] ([[User talk:CaptainPedge|talk]]) 02:45, 24 July 2014 (UTC)
::[[User:CaptainPedge|CaptainPedge]]: Good example! [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|talk]]) 02:03, 16 July 2014 (UTC)
:[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]]: That is not the behavior that should happen. The logo should literally turn only to the wordmark.
:Can I get a screenshot? [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 03:01, 16 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk: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'}) [[User:Magnus Manske|Magnus Manske]] ([[User talk: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/ [[User:Julian Claus|Julian Claus]] ([[User talk:Julian Claus|talk]]) 15:34, 17 July 2014 (UTC)
::[[User:Julian Claus|Julian Claus]]: Pretty much what [[User:Ckoerner|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:19, 17 July 2014 (UTC)
::[[User:Julian Claus|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.
::[[User:Ckoerner|Ckoerner]]: some of those designs turn out to be excellent. Cf. [//en.wikipedia.org/wiki/user%20innovation user innovation] in general and [https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually a certain cool cooler] in particular ;)
::[[User:Jorm (WMF)|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. [[User:Sj|Sj]] ([[User talk: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 [http://simpsons.wikia.com/wiki/The_Homer The Homer]. [[User:Ckoerner|Ckoerner]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:55, 17 July 2014 (UTC)
:Confirmed on Firefox with a 1600x900 display. http://prntscr.com/44x44f [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:31, 21 July 2014 (UTC)
:Thanks! I'll see about getting a fix for this in soonish. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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.wikipedia.org/wiki/And%20Yet%20It%20Moves 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.wikipedia.org/wiki/Template:multiple%20image 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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:22, 21 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[Special:Contributions/62.216.204.25|62.216.204.25]] ([[User talk: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). [[User:Verdy p|Verdy p]] ([[User talk: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]]. [[User:Wolf359borg|Wolf359borg]] ([[User talk:Wolf359borg|talk]]) 22:59, 22 July 2014 (UTC)
:[[User:Wolf359borg|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 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? [[User:Qgil-WMF|Qgil-WMF]] ([[User talk: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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 18:21, 30 July 2014 (UTC)
:[[User:Sven Manguard|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:40, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 19:25, 30 July 2014 (UTC)
::[[User:Jorm (WMF)|Jorm (WMF)]]: My file namespace ideas are at [[:File:Winter file namespace ideas.png]]
::[[File:Winter file namespace ideas.png|300x300px]]
::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. [[User:Sven Manguard|Sven Manguard]] ([[User talk:Sven Manguard|talk]]) 20:54, 30 July 2014 (UTC)

== Is Winter not in BetaFeatures anymore? ==
{{Flow summary|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? ''[[User:Negative24|-24]][[User Talk:Negative24|Talk]]'' 23:04, 4 August 2014 (UTC)
:I would also like to see this in beta features. [[User talk:Gryllida|Gryllida]] 08:03, 10 August 2014 (UTC)
:Thought I already left such request somewhere. Don't see it. [[User talk:Gryllida|Gryllida]] 08:04, 10 August 2014 (UTC)
:I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures. ''[[User:Negative24|-24]][[User Talk:Negative24|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? [[User talk:Gryllida|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 [[:bugzilla:69383|bug 69383]]. about subsections.) [[User talk:Gryllida|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. ''[[User:Negative24|-24]][[User Talk:Negative24|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]]. ''[[User:Negative24|-24]][[User Talk:Negative24|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. [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:43, 12 August 2014 (UTC)
:[[User:JamesDouch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Josve05a|Josve05a]] ([[User talk:Josve05a|talk]]) 02:25, 13 August 2014 (UTC)
:[[User:Josve05a|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk:Mountainhead|talk]]) 19:09, 14 August 2014 (UTC)
::[[User:WOLF LΔMBERT|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:Seconding the monospace font for the edit box. Editing in a proportional font is painful. [[User:Scott5114|Scott5114]] ([[User talk:Scott5114|talk]]) 07:10, 15 August 2014 (UTC)
::[[User:Scott5114|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:42, 27 August 2014 (UTC)
:::[[User:Jorm (WMF)|Jorm (WMF)]]: Interesting. I am only seeing the proportional font on the editor in the Winter prototype, not anywhere else. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Mountainhead|Mountainhead]] ([[User talk: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. [[User:Scott5114|Scott5114]] ([[User talk: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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 05:39, 18 August 2014 (UTC)

== Navboxes and categories ==

Are these being removed? [http://unicorn.wmflabs.org/winter/index.html?page=Michigan_State_Trunkline_Highway_System 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. [[User:Imzadi1979|Imzadi1979]] ([[User talk:Imzadi1979|talk]]) 14:17, 15 August 2014 (UTC)
:[[User:Imzadi1979|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:30, 16 August 2014 (UTC)

== Infoboxes that are longer than the article text ==

In many shorter articles such as [http://unicorn.wmflabs.org/winter/index.html?page=Adams%20County%20Courthouse%20(North%20Dakota) 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. [[User:TheCatalyst31|TheCatalyst31]] ([[User talk:TheCatalyst31|talk]]) 03:07, 16 August 2014 (UTC)
:[[User:TheCatalyst31|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." [[User:Ypna|Ypna]] ([[User talk:Ypna|talk]]) 10:23, 17 August 2014 (UTC)
:[[User:TheCatalyst31|TheCatalyst31]]: I'm just going to echo what [[User:JamesDouch|JamesDouch]] said. It's a prototype-only bug. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Wittylama|Wittylama]] ([[User talk:Wittylama|talk]]) 15:57, 17 August 2014 (UTC)
:[[User:Wittylama|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Lazowik|Lazowik]] ([[User talk: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? [[User:Llywrch|Llywrch]] ([[User talk:Llywrch|talk]]) 17:01, 3 September 2014 (UTC)
:[[User:Llywrch|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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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:

# 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.
# 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.
# 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.
# The searchbar: It is too large for the desktop version.
# The right colum: If you have an article without infobox and Commons-Template (e.g. the [http://unicorn.wmflabs.org/winter/index.html?page=Winter&lang=de 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
# 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.
#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. [[User:Patrick Stützel|Patrick Stützel]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk: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. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 18:30, 8 September 2014 (UTC)
::Yes, I was referring to those buttons. They appear as <s>plain text</s> 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...") [[User:Diego Moya|Diego Moya]] ([[User talk: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. [[User:Soni|Soni]] ([[User talk: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 [[User:Tar Lócesilion|Tar Lócesilion]] ([[User talk: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? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:24, 11 October 2014 (UTC)

Talk:HHVM/About

2014-10-11T20:04:24Z

RandomDSdevel: /* Conflict Between HHVM, Compact Personal Bar, and 'showBackendPerformance()' JavaScript Function */ Added reply

{{flow imported revision}}'''HHVM''' (''also known as the HipHop Virtual Machine'') is a virtual machine for [w:PHP PHP], with an associated just-in-time ([w:Just-in-time_compilation JIT]) compiler. Deploying HHVM on a MediaWiki wiki should lead to performance improvements across the board for most users.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. All languages welcome! You can read more about the feature [[HHVM/About|here]].

''Note: this page is using [[Flow]]; to give feedback on Flow, please use the [[Talk:Flow|'''Flow talk''' page]]''

== Math support under HHVM apparently missing on enWS? ==
{{hatnote|{{Resolved}}}}

:[s:en:wikisource:Scriptorium#Tech_News:_2014-38 Initial report buried here.] Salient details are: when previewing results of modifying a <math> expression on English WikiSource with HHVM enabled, this error is presented:
:<div style="color:red;text-align:center;">Failed to parse (Missing <code>texvc</code> executable. Please see math/README to configure.): \scriptstyle{i=\frac{702\cdot25}{2\times10}=35\cdot11,\quad\mu=1\cdot738} .</div>
:Notes:
:*The second line of the error message is simply informational regarding the input LaTeX string and is not likely pertinent to this report.
:*The error reliably goes away when HHVM is deselected from Beta choices.
:*Reliably returns when both HHVM reenabled and the previewed formula is tweaked to force re-evaluation.
:*There is no problem displaying cached results irrespective of HHVM state.
:*There may be further significance in the fact that <code> does not appear to have been parsed by the error processor.
:*Verified similar results on English WikiPedia. [[User:AuFCL|AuFCL]] ([[User talk:AuFCL|talk]]) 04:25, 24 September 2014 (UTC)
::This bug is tracked at [[bugzilla:71224]]. It was also briefly discussed on IRC, I'll ping the participants from that. (Also, good details! I'll copy your comment to the bugreport, for centralized notes) [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk:Quiddity (WMF)|talk]]) 17:57, 24 September 2014 (UTC)
:A brilliant fix. Please pass on my thanks to those involved. [[User:AuFCL|AuFCL]] ([[User talk:AuFCL|talk]]) 07:40, 3 October 2014 (UTC)

== Translation ==
{{hatnote|{{Resolved}}}}

Can we set this page up for translations? Thanks. [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 13:05, 25 September 2014 (UTC)
:Ok. Done. [[User:Steinsplitter|Steinsplitter]] ([[User talk:Steinsplitter|talk]]) 20:04, 25 September 2014 (UTC)

== HHVM vs. big pages on Wikidata ==
{{hatnote|{{tracked|71486}}
Tracked at [[bugzilla:71486]] ("HHVM http status code 503 on long pages")}}

:With enabled HHVM I am unable to open some reports on wikidata: [Wikidata:Database_reports/Constraint_violations/P301 constraint violations for P301] and [Wikidata:Database_reports/Constraint_violations/P373 P373]. I got 503 response.
:These pages have >400 kb
:When is HHVM disabled, it works. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 19:47, 25 September 2014 (UTC)
::I'm not getting a 503, but it appears that both of those items have been deleted, so it could be an unrelated issue? I just tested with [https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P21#One_of P21] also pretty large, with no issues. Can you link to another wikidata item which you're experiencing issues? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:37, 26 September 2014 (UTC)
:I believe you should move this to [[Talk:HHVM]], it might go unnoticed here. best, [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 20:09, 25 September 2014 (UTC)
::This is the right place for feedback, no worries. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:38, 26 September 2014 (UTC)
:::I see other feedback elsewhere, as long as someone is keeping an eye on all of it, I'm fine :) [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 15:08, 26 September 2014 (UTC)
:But here is target of link from [[Special:Preferences#mw-prefsection-betafeatures]] [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 05:27, 26 September 2014 (UTC)
:Yes, this was mentioned in a mailing list. I think [[User:Legoktm]] meant to point to the main page talk for reports, but I might be wrong. Just wanting to make sure your comment is read! Best, [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 06:36, 26 September 2014 (UTC)
:Not only Wikidata. Same problem with de.wikipedia.org. https://de.wikipedia.org/wiki/Liste_der_Kulturdenkm%C3%A4ler_in_Bremen-Mitte is slow without HHVM but blocks with. [[User:Quarz|Quarz]] ([[User talk:Quarz|talk]]) 16:43, 29 September 2014 (UTC)
::Hi there, do you have problems when reading or when editing that page? It displays just fine for me, and it seems it was never edited by someone with HHVM enabled. [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 17:09, 29 September 2014 (UTC)
:::Hm. I can load that page extremely or very quickly in Chrome, IE and Opera, but Firefox does return a 503 error :/ [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 17:12, 29 September 2014 (UTC)
:::And now it works again there as well. What I did was disabling and enabling the feature again. [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 17:32, 29 September 2014 (UTC)
:::In Chrome/OS X no HHVM load time is 30-40 seconds, with HHVM load time is 3-5 seconds for me. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 20:48, 30 September 2014 (UTC)
:::That is, what I see: 503 error at Firefox. Only with fat pages, the rest works fine - but I need the fat ones. [[User:Quarz|Quarz]] ([[User talk:Quarz|talk]]) 07:31, 1 October 2014 (UTC)
:https://bugzilla.wikimedia.org/show_bug.cgi?id=71385 looks relevant. [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 14:14, 30 September 2014 (UTC)
::That issue looks resolved but I still can't open https://de.wikipedia.org/wiki/Liste_der_Kulturdenkm%C3%A4ler_in_Bremen-Mitte . [[User:NEverett (WMF)|NEverett (WMF)]] ([[User talk:NEverett (WMF)|talk]]) 18:22, 1 October 2014 (UTC)
:Loads instantly for me. There's a bug open for 503 messages anyway, Ori said elsewhere that he's working on it. [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 18:24, 1 October 2014 (UTC)
::Which would be https://bugzilla.wikimedia.org/show_bug.cgi?id=71486 (but hey, duplicating feedback pages is the greatest idea, right?) [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 18:28, 1 October 2014 (UTC)

== Conflict Between HHVM, Compact Personal Bar, and 'showBackendPerformance()' JavaScript Function ==

Hey, has anybody else notice that, if you have both HHVM and the Compact Personal Bar activated in your 'Beta features' preferences and you've also copied the 'showBackendPerformance()' JavaScript function that makes MediaWiki show you both what PHP run-time environment was used to load the current page and how long it took, this script runs both outside and inside the Compact Personal Bar? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:09, 26 September 2014 (UTC)
:While it would be great to fix this, it is a test script that won't be part of the final feature. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 04:29, 29 September 2014 (UTC)
::OK, then; I can always go into Safari's Web Inspector to look at stuff like that anyway. Will there, however, perhaps still be a different way to see aggregate statistics collected from all users of instances of HHVM included as part of installations of MediaWiki in the software's final implementation of its use of HHVM? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 20:04, 11 October 2014 (UTC)

== HHVM breaks most meta pages, breaking page to disable hhvm ==
{{hatnote|{{resolved}} Scribunto_Lua error was fixed}}

The worst problem is that after enabling just hhvm, I can't get to beta to disable it, or to preferences.

Beta preferences error: "[304a41da] 2014-10-01 20:23:36: Fatal exception of type Scribunto_LuaInterpreterNotFoundError"

preferences preferences error: "[6353f258] 2014-10-01 20:24:04: Fatal exception of type Scribunto_LuaInterpreterNotFoundError"

my (blank) wikipedia userpage [09c88c36] 2014-10-01 20:24:36: Fatal exception of type Scribunto_LuaInterpreterNotFoundError

But... for some reason, beta now suddenly works... [[User:TeeTylerToe|TeeTylerToe]] ([[User talk:TeeTylerToe|talk]]) 20:25, 1 October 2014 (UTC)
:Can't reproduce; can you be more specific about the URLs that are breaking for you? [[User:Erik Moeller (WMF)|Erik Moeller (WMF)]] ([[User talk:Erik Moeller (WMF)|talk]]) 23:19, 1 October 2014 (UTC)
:This error was seen at all sites for a few minutes today. AFAIK, it was resolved so quickly that there isn't a bug-ticket. However, thanks for the bug-report, especially for leaving notes even after it cleared up - that's often handy. :) [[User:Quiddity (WMF)|Quiddity (WMF)]] ([[User talk:Quiddity (WMF)|talk]]) 01:21, 2 October 2014 (UTC)

== HHVM and AWB ==
{{hatnote|{{resolved}} Waiting on the API servers to switch over to HHVM.}}

Noticed that when using Auto Wiki Browser on enwiki I am not seeing the HHVM tag on contributions-is this being overridden or just not tagged? [[User:Xaosflux|Xaosflux]] ([[User talk:Xaosflux|talk]]) 04:37, 6 October 2014 (UTC)
:Edits made via the API (which AWB uses) currently don't support using HHVM, so it's still using normal PHP5. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 04:43, 6 October 2014 (UTC)

== browser frozen when editing .css personal page ==
{{hatnote|{{Resolved}} Seems to have been user/machine-specific issue}}

Chrome 37 on Mac OSX 10.9.5 froze when I tried to edit my personal vector.css page (twice, I tried a second time).
I could edit it by temporarily disabling HHVM.
No other misbehaviour detected up to now. Thank you. [[User:Paginazero|Paginazero]] ([[User talk:Paginazero|talk]]) 07:29, 7 October 2014 (UTC)
:Thanks for your feedback. I tested with Chrome on Win 8 and Safari on Mac but couldn't reproduce (although this might mean nothing), and I can't find anything similar among already reported bugs. Let's see if someone has ideas about this issue, otherwise I'll report it on Bugzilla when I can. Best, [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 09:27, 7 October 2014 (UTC)
:Please disregard this note. Whatever the problem was, it seems it was related to my machine. I just tried once again to edit my vector.css page keeping HHVM active, and it worked smoothly (unless you fixed it during the nighttime without giving notice :) ) [[User:Paginazero|Paginazero]] ([[User talk:Paginazero|talk]]) 07:30, 9 October 2014 (UTC)
:Good to know! Not sure if anything was changed in the meantime, hamsters didn't tell me anything - and if they did, well, I do not speak their language (yet). [[User:Elitre (WMF)|Elitre (WMF)]] ([[User talk:Elitre (WMF)|talk]]) 09:21, 9 October 2014 (UTC)

Talk:HHVM/About

2014-09-26T21:09:15Z

RandomDSdevel: /* Conflict Between HHVM, Compact Personal Bar, and 'showBackendPerformance()' JavaScript Function */ New section

HHVM

2014-09-22T19:03:37Z

RandomDSdevel: /* Status */ Cleaned up the text a little.

<onlyinclude>{{Wikimedia engineering project information
| name = HHVM
| description = Support in MediaWiki for HHVM (HipHop Virtual Machine) and deployment to the Wikimedia cluster
| start = March 2014
| end =
| group = [[Wikimedia Platform Engineering|Platform]]
| lead = [[User:Ori.livneh|Ori Livneh]]
| team = [[user:Tim Starling|Tim Starling]], [[User:Aaron Schulz|Aaron Schulz]], [[User:^demon|Chad Horohoe]], [[User:Hashar|Antoine Musso]], [[User:DGarry (WMF)|Dan Garry]], [[User:MaxSem|Max Semenik]]
| previous =
| next =
| projectpage = HHVM
| display = {{{display}}}
}}</onlyinclude>

'''[[w:HHVM|HHVM]]''', sometimes known as HipHop Virtual Machine, is a virtual machine for PHP, with an associated just-in-time compiler (JIT). Deploying HHVM on a MediaWiki wiki should lead to performance improvements across the board for most users.

This page is about Wikimedia-sponsored work on HipHop support in MediaWiki, and its deployment to Wikimedia production wikis.

Historically, the HipHop compiler was a project by Facebook which involved compiling PHP code into C++ for purposes of speeding up the language. Facebook has since abandoned this project, and now their development efforts are focused on HHVM itself instead.

== [[{{FULLPAGENAME}}/status|Status]] ==

{{Wikimedia project status line|{{FULLPAGENAME}}}}

== Roadmap ==
Here is the general plan for deploying HHVM to the production cluster:
* Deployment to Beta Cluster (currently ongoing work, in parallel with other work) {{done}}
* Week of July 21: deployment to a few job runners in production {{done}}
* Deploy to test.wikipedia.org application server {{done}}
* Deploy Varnish module allowing partial deployment to a fraction of application servers{{Done}}
* Limited deployment to small number of application servers{{Done}}
* Ramp up deployment to more application servers until most servers use HHVM
* Deploy to remainder of services
Each step along the way will likely cause discovery of new bugs that need to be fixed before the next step can be completed, so dates are difficult to venture at this time.
== Current work ==
<rss max=10 template="MediaWiki:Rss-item-nodesc">https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=PATCH_TO_REVIEW&bug_status=REOPENED&bug_status=VERIFIED&f1=keywords&list_id=288958&o1=substring&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_based_on=&query_format=advanced&title=Bug%20List&v1=hhvm&ctype=atom</rss>[https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=PATCH_TO_REVIEW&bug_status=REOPENED&bug_status=VERIFIED&f1=keywords&list_id=288958&o1=substring&query_format=advanced&title=Bug%20List&v1=hiphop Additional items]

== Rationale ==
It is a well-studied phenomenon that even small delays in response time (e.g half of a second) can result in sharp declines in web user retention.<ref>[http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html "Bing and Google Agree: Slow Pages Lose Users"] - Brady Forrest - ''O'Reilly Radar''</ref><ref>[http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html Greg Linden's blog: "Marissa Mayer at Web 2.0"] - Marissa Mayer pointed out that a change from 0.4 seconds to 0.9 seconds in response time from Google caused a 20% drop in revenue and traffic.</ref> As a result, popular websites such as Google and Facebook invest heavily in site performance initiatives, and partially as a result, remain popular. Formerly popular sites (such as Friendster) suffered due to lack of attention to these issues<ref>"[http://www.nytimes.com/2006/10/15/business/yourmoney/15friend.html Wallflower at the Web Party]", New York Times, October 15, 2006. Quote: "Kent Lindstrom, now president of Friendster, said the board failed to address technical issues that caused the company’s overwhelmed Web site to become slower."</ref>. Wikipedia and its sister projects must remain usable and responsive in order for the movement to sustain its mission.

Facebook, as a big user of PHP, has recognized this problem, and invested heavily<ref>http://www.wired.com/wiredenterprise/2013/06/facebook-hhvm-saga/</ref> in a solution: [http://hhvm.com HHVM], a virtual machine that compiles PHP bytecode to native instructions at runtime, the same strategy used by Java and C# to achieve their speed advantages. We're quite confident that this will result in big performance improvements on our sites as well.

== What will HipHop do for our end users? ==

MediaWiki is written in PHP, a language that is [[w:Interpreter (computing)|interpreted]] at run-time. The overhead of running this PHP code every time someone views a page necessitates the usage of caching servers, running software such as [[w:Varnish (software)|Varnish]], which cache the HTML generated by running this PHP, so that the PHP does not have to run every time a page is viewed. These caches only serve users that are not logged in<ref>By definition, users that are logged in cannot be served pages from a static cache, as the page served to them must include user-specific HTML such as their username at the top right of the page. This, unfortunately, creates a situation where simply logging in causes a tangible decrease in how well our sites perform for you.</ref>. Actions which are not affected by the cache, and therefore ''are'' affected by the run time of PHP code, include:
*Any page you view while logged in.
*Saving pages that you've edited, whether you are logged in or not.
Therefore, any action we can take to reduce the time it takes for MediaWiki's PHP code will therefore also decrease the loading times of our site for all of our logged in users and anyone who edits anonymously.

HipHop was written to be a faster, more efficient PHP interpreter than our current interpreter ([[:en:Zend Engine|Zend]]). It is our hope that by implementing HipHop as a replacement for Zend, our users will notice a tangible increase in the performance of our sites.

== How does our development work on HipHop affect MediaWiki developers? ==

In our initial sprint of work, due to be finished at the end of March 2014, we hope to make it so that anyone can elect to use HipHop on Beta Labs instead of Zend. This will be on a totally opt-in basis which can be disabled at any time. This will allow the MediaWiki Core team to gauge the performance of HipHop against that of Zend directly using our current test infrastructure, instead of just estimating theoretical performance increases. It will also create a development environment that will help us see how much work is needed to make HipHop compatible with MediaWiki, and as such let us create an estimate for how long it will take us to get HipHop live on production as a full replacement for Zend.

For other MediaWiki developers, the consequence of HipHop being deployed in this manner is that if they are using the Beta Cluster as a test environment, they will find it trivial to test how their patches perform using HipHop instead of Zend if they wish to. However, to minimise the disruption of our work, the opt-in nature of the infrastructure will allow developers will be able to continue to develop totally agnostic of the future HipHop migration if they wish to do so.

== See also ==

* [[HHVM/Vagrant]]: Setting up HHVM in [[MediaWiki-Vagrant]]
* [https://www.youtube.com/watch?v=vgXgDVrb-BU Ori presenting at @Scale about migrating to HHVM]

== References and footnotes ==

<references />

[[Category:Performance development]]

Topic:Rt6aw8wdjn1bszk1

2014-05-21T22:38:46Z

RandomDSdevel (talk | contribs) hid a post on "Text summaries are clipped awkwardly sometimes." (Already discussed below. )

Talk:Page Previews/2014/04

2014-05-21T22:38:46Z

RandomDSdevel: /* Text summaries are clipped awkwardly sometimes. */ Already discussed below.

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

:I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.
:1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.
:2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).
:3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards
:4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?
:5. Disable hovercards in the watchlist.
:6. Disable hovercards on the view history page.
:7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
::[[User:Wolbo|Wolbo]]: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 19:12, 5 May 2014 (UTC)
:::[[User:RandomDSdevel|RandomDSdevel]]: I was thinking exactly that as well. In theory, Hovercards could replace NavPopups entirely, if Hovercards offered an "editor mode" that switched on an equivalent featureset (or at least a sufficiently-complete subset of features that NavPopups users value). The main advantage would be avoiding the "collision" possibility of multiple link-hovering tools, as they can't usefully be used together. I remeber at one point some link-hovering code had been switched on at enwiki (I think it was for note/reference links), and for those of us who had NavPopups enabled the two hovers overlapped unhelpfully. Consolidating the features would avoid forcing users to choose between NavPopups and HoverCard.
:::However, from what I've seen of HoverCard and based on some of what I've read here, I no longer believe that's a good idea. The design of HoverCard clearly follows the recent trend towards minimalist, "clean", low-noise interfaces, absent both clutter and power. That's not merely its current form, but the philosophy of its design and its designers. This is evidenced by the response (somewhere above) that a feature to turn off images in HoverCard isn't workable, because it's somehow bad practice to have "preferences at an element level".
:::NavPopups may be a bit busy and ugly, but there's a lot there. A HoverCard "editor mode" would inevitably discard most of those features, making it a crippled replacement for NavPopups. I'm personally tired of seeing useful tools replaced with less-useful "improvements". [[Special:Contributions/2001:470:1F07:D25:D5D0:5F09:52BB:2A77|2001:470:1F07:D25:D5D0:5F09:52BB:2A77]] ([[User talk:2001:470:1F07:D25:D5D0:5F09:52BB:2A77|talk]]) 16:07, 15 May 2014 (UTC)
:::2001:470:1F07:D25:D5D0:5F09:52BB:2A77: *sigh* I guess I somehow got logged out in the process of editing that post, which I hadn't realized until it posted. Since there doesn't appear to be a way in Flow to "claim" the post as mine, I just wanted to identify myself as the author of the above. [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:13, 15 May 2014 (UTC)
:::[[User:FeRD NYC|FeRD NYC]]: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over to that of Hovercards in a permanent manner, could a Hovercard 'editor mode' copy over at least ''some'' of the functionality that currently exists as part of NavPopups? Why would it be bad to have preferences at an 'element' level? Whose idea was that? I think that sub-feature preferences are great! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:29, 21 May 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)
:As an example of somewhat awkward cropping, mousing over a link to https://en.wikipedia.org/wiki/Bernard_Zakheim gives "Bernard Zakheim, Apr.", presumably because it treats the period as a sentence termination rather than an abbreviation. Not the end of the world but something else to consider while improving this. [[User:LuisVilla|LuisVilla]] ([[User talk:LuisVilla|talk]]) 22:37, 21 May 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)
:Images doesn't render in my browser too.
:Windows 8 and IE11. [[Special:Contributions/89.142.77.230|89.142.77.230]] ([[User talk:89.142.77.230|talk]]) 03:55, 9 May 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Topic:Rt6aw8wdjn1bszk1

2014-05-21T22:38:18Z

RandomDSdevel (talk | contribs) edited a post on "Text summaries are clipped awkwardly sometimes."

Talk:Page Previews/2014/04

2014-05-21T22:38:18Z

RandomDSdevel: /* Text summaries are clipped awkwardly sometimes. */ Edited post

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

:I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.
:1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.
:2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).
:3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards
:4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?
:5. Disable hovercards in the watchlist.
:6. Disable hovercards on the view history page.
:7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
::[[User:Wolbo|Wolbo]]: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 19:12, 5 May 2014 (UTC)
:::[[User:RandomDSdevel|RandomDSdevel]]: I was thinking exactly that as well. In theory, Hovercards could replace NavPopups entirely, if Hovercards offered an "editor mode" that switched on an equivalent featureset (or at least a sufficiently-complete subset of features that NavPopups users value). The main advantage would be avoiding the "collision" possibility of multiple link-hovering tools, as they can't usefully be used together. I remeber at one point some link-hovering code had been switched on at enwiki (I think it was for note/reference links), and for those of us who had NavPopups enabled the two hovers overlapped unhelpfully. Consolidating the features would avoid forcing users to choose between NavPopups and HoverCard.
:::However, from what I've seen of HoverCard and based on some of what I've read here, I no longer believe that's a good idea. The design of HoverCard clearly follows the recent trend towards minimalist, "clean", low-noise interfaces, absent both clutter and power. That's not merely its current form, but the philosophy of its design and its designers. This is evidenced by the response (somewhere above) that a feature to turn off images in HoverCard isn't workable, because it's somehow bad practice to have "preferences at an element level".
:::NavPopups may be a bit busy and ugly, but there's a lot there. A HoverCard "editor mode" would inevitably discard most of those features, making it a crippled replacement for NavPopups. I'm personally tired of seeing useful tools replaced with less-useful "improvements". [[Special:Contributions/2001:470:1F07:D25:D5D0:5F09:52BB:2A77|2001:470:1F07:D25:D5D0:5F09:52BB:2A77]] ([[User talk:2001:470:1F07:D25:D5D0:5F09:52BB:2A77|talk]]) 16:07, 15 May 2014 (UTC)
:::2001:470:1F07:D25:D5D0:5F09:52BB:2A77: *sigh* I guess I somehow got logged out in the process of editing that post, which I hadn't realized until it posted. Since there doesn't appear to be a way in Flow to "claim" the post as mine, I just wanted to identify myself as the author of the above. [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:13, 15 May 2014 (UTC)
:::[[User:FeRD NYC|FeRD NYC]]: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over to that of Hovercards in a permanent manner, could a Hovercard 'editor mode' copy over at least ''some'' of the functionality that currently exists as part of NavPopups? Why would it be bad to have preferences at an 'element' level? Whose idea was that? I think that sub-feature preferences are great! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:29, 21 May 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Maybe coming to a wiki page from a Hovercard could highlight the text that was in the Hovercard that linked to it for a few seconds or something? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:37, 21 May 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)
:As an example of somewhat awkward cropping, mousing over a link to https://en.wikipedia.org/wiki/Bernard_Zakheim gives "Bernard Zakheim, Apr.", presumably because it treats the period as a sentence termination rather than an abbreviation. Not the end of the world but something else to consider while improving this. [[User:LuisVilla|LuisVilla]] ([[User talk:LuisVilla|talk]]) 22:37, 21 May 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)
:Images doesn't render in my browser too.
:Windows 8 and IE11. [[Special:Contributions/89.142.77.230|89.142.77.230]] ([[User talk:89.142.77.230|talk]]) 03:55, 9 May 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Topic:Rt6aw8wdjn1bszk1

2014-05-21T22:37:35Z

RandomDSdevel (talk | contribs) commented on "Text summaries are clipped awkwardly sometimes." (Vibhabamba: Maybe coming to a wiki page from a Hovercard could highlight the text that was in the Hovercard that linked to it for a few s...)

Talk:Page Previews/2014/04

2014-05-21T22:37:35Z

RandomDSdevel: /* Text summaries are clipped awkwardly sometimes. */ Added reply

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

:I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.
:1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.
:2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).
:3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards
:4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?
:5. Disable hovercards in the watchlist.
:6. Disable hovercards on the view history page.
:7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
::[[User:Wolbo|Wolbo]]: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 19:12, 5 May 2014 (UTC)
:::[[User:RandomDSdevel|RandomDSdevel]]: I was thinking exactly that as well. In theory, Hovercards could replace NavPopups entirely, if Hovercards offered an "editor mode" that switched on an equivalent featureset (or at least a sufficiently-complete subset of features that NavPopups users value). The main advantage would be avoiding the "collision" possibility of multiple link-hovering tools, as they can't usefully be used together. I remeber at one point some link-hovering code had been switched on at enwiki (I think it was for note/reference links), and for those of us who had NavPopups enabled the two hovers overlapped unhelpfully. Consolidating the features would avoid forcing users to choose between NavPopups and HoverCard.
:::However, from what I've seen of HoverCard and based on some of what I've read here, I no longer believe that's a good idea. The design of HoverCard clearly follows the recent trend towards minimalist, "clean", low-noise interfaces, absent both clutter and power. That's not merely its current form, but the philosophy of its design and its designers. This is evidenced by the response (somewhere above) that a feature to turn off images in HoverCard isn't workable, because it's somehow bad practice to have "preferences at an element level".
:::NavPopups may be a bit busy and ugly, but there's a lot there. A HoverCard "editor mode" would inevitably discard most of those features, making it a crippled replacement for NavPopups. I'm personally tired of seeing useful tools replaced with less-useful "improvements". [[Special:Contributions/2001:470:1F07:D25:D5D0:5F09:52BB:2A77|2001:470:1F07:D25:D5D0:5F09:52BB:2A77]] ([[User talk:2001:470:1F07:D25:D5D0:5F09:52BB:2A77|talk]]) 16:07, 15 May 2014 (UTC)
:::2001:470:1F07:D25:D5D0:5F09:52BB:2A77: *sigh* I guess I somehow got logged out in the process of editing that post, which I hadn't realized until it posted. Since there doesn't appear to be a way in Flow to "claim" the post as mine, I just wanted to identify myself as the author of the above. [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:13, 15 May 2014 (UTC)
:::[[User:FeRD NYC|FeRD NYC]]: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over to that of Hovercards in a permanent manner, could a Hovercard 'editor mode' copy over at least ''some'' of the functionality that currently exists as part of NavPopups? Why would it be bad to have preferences at an 'element' level? Whose idea was that? I think that sub-feature preferences are great! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:29, 21 May 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Maybe coming to a wiki page from a Hovercard could highlight the text that was in the Hovercard that linked to it for a few seconds or something? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:37, 21 May 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)
:As an example of somewhat awkward cropping, mousing over a link to https://en.wikipedia.org/wiki/Bernard_Zakheim gives "Bernard Zakheim, Apr.", presumably because it treats the period as a sentence termination rather than an abbreviation. Not the end of the world but something else to consider while improving this. [[User:LuisVilla|LuisVilla]] ([[User talk:LuisVilla|talk]]) 22:37, 21 May 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)
:Images doesn't render in my browser too.
:Windows 8 and IE11. [[Special:Contributions/89.142.77.230|89.142.77.230]] ([[User talk:89.142.77.230|talk]]) 03:55, 9 May 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Topic:Rshbkg3eop803wmx

2014-05-21T22:29:34Z

RandomDSdevel (talk | contribs) commented on "Nice feature" (FeRD NYC: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over...)

Talk:Page Previews/2014/04

2014-05-21T22:29:34Z

RandomDSdevel: /* Nice feature */ Added reply

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

:I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.
:1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.
:2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).
:3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards
:4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?
:5. Disable hovercards in the watchlist.
:6. Disable hovercards on the view history page.
:7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
::[[User:Wolbo|Wolbo]]: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 19:12, 5 May 2014 (UTC)
:::[[User:RandomDSdevel|RandomDSdevel]]: I was thinking exactly that as well. In theory, Hovercards could replace NavPopups entirely, if Hovercards offered an "editor mode" that switched on an equivalent featureset (or at least a sufficiently-complete subset of features that NavPopups users value). The main advantage would be avoiding the "collision" possibility of multiple link-hovering tools, as they can't usefully be used together. I remeber at one point some link-hovering code had been switched on at enwiki (I think it was for note/reference links), and for those of us who had NavPopups enabled the two hovers overlapped unhelpfully. Consolidating the features would avoid forcing users to choose between NavPopups and HoverCard.
:::However, from what I've seen of HoverCard and based on some of what I've read here, I no longer believe that's a good idea. The design of HoverCard clearly follows the recent trend towards minimalist, "clean", low-noise interfaces, absent both clutter and power. That's not merely its current form, but the philosophy of its design and its designers. This is evidenced by the response (somewhere above) that a feature to turn off images in HoverCard isn't workable, because it's somehow bad practice to have "preferences at an element level".
:::NavPopups may be a bit busy and ugly, but there's a lot there. A HoverCard "editor mode" would inevitably discard most of those features, making it a crippled replacement for NavPopups. I'm personally tired of seeing useful tools replaced with less-useful "improvements". [[Special:Contributions/2001:470:1F07:D25:D5D0:5F09:52BB:2A77|2001:470:1F07:D25:D5D0:5F09:52BB:2A77]] ([[User talk:2001:470:1F07:D25:D5D0:5F09:52BB:2A77|talk]]) 16:07, 15 May 2014 (UTC)
:::2001:470:1F07:D25:D5D0:5F09:52BB:2A77: *sigh* I guess I somehow got logged out in the process of editing that post, which I hadn't realized until it posted. Since there doesn't appear to be a way in Flow to "claim" the post as mine, I just wanted to identify myself as the author of the above. [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:13, 15 May 2014 (UTC)
:::[[User:FeRD NYC|FeRD NYC]]: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over to that of Hovercards in a permanent manner, could a Hovercard 'editor mode' copy over at least ''some'' of the functionality that currently exists as part of NavPopups? Why would it be bad to have preferences at an 'element' level? Whose idea was that? I think that sub-feature preferences are great! [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 22:29, 21 May 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)
:Images doesn't render in my browser too.
:Windows 8 and IE11. [[Special:Contributions/89.142.77.230|89.142.77.230]] ([[User talk:89.142.77.230|talk]]) 03:55, 9 May 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Topic:Rshbkg3eop803wmx

2014-05-05T19:12:19Z

RandomDSdevel (talk | contribs) commented on "Nice feature" (Wolbo: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor...)

Talk:Page Previews/2014/04

2014-05-05T19:12:19Z

RandomDSdevel: /* Nice feature */ Added reply

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

:I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.
:1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.
:2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).
:3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards
:4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?
:5. Disable hovercards in the watchlist.
:6. Disable hovercards on the view history page.
:7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
::[[User:Wolbo|Wolbo]]: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 19:12, 5 May 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Topic:Rstdorfpv3kuvuj5

2014-05-04T17:53:33Z

RandomDSdevel (talk | contribs) commented on "Thanks" (Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards?)

Talk:Page Previews/2014/04

2014-05-04T17:53:33Z

RandomDSdevel: /* Thanks */ Added reply

{{flow imported revision}}
'''Hovercards''' provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this [[Beta Features| beta feature]] so we can change and improve it. You can read more about the feature [[Beta Features/Hovercards|here]].

 Archived discussion for this page are available at [[Talk:Beta Features/Hovercards/Archive 1|/Archive 1]] ''Note: this page is using [[Flow]], to give feedback on Flow please use the [[Talk:Flow|'''Flow talk''' page]]''

== Location of hovercard ==

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 17:48, 1 April 2014 (UTC)
:[[User:קיפודנחש|קיפודנחש]]: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in [[bugzilla:62970|bug 62970]]. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as [[bugzilla:63159|bug 63159]]. We've also got [[bugzilla:62971|bug 62971]] for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?
:Thanks very much for the report! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 20:55, 1 April 2014 (UTC)
::[[User:DGarry (WMF)|DGarry (WMF)]]:
::i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.
::as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.
::this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).
::(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).
::i added a comment to [[bugzilla:62971]].
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 14:23, 2 April 2014 (UTC)

== Interference from existing preference ==

:There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 18:49, 1 April 2014 (UTC)
::[[User:Wikitiki89|Wikitiki89]]: That's tracked at [[bugzilla:62952]]. Thanks :) –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 19:30, 1 April 2014 (UTC)
:Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 23:59, 5 April 2014 (UTC)

== Typo : Double coma and no italics ==

Hi, when you have footnotes markers in a text, separated with <nowiki>[[http://fr.wikipedia.org/wiki/Modèle:,]]</nowiki>, and then a normal coma, Hovercads displays two successive normal comas. (eg. Try ''Atherurus macrourus'' on [http://fr.wikipedia.org/wiki/Ath%C3%A9rure fr:Athérure] page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 21:36, 1 April 2014 (UTC)
:Can you please include a screenshot of what you are seeing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:11, 4 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 10:22, 4 April 2014 (UTC)

== Image sometimes missing ==
{{Archive top|result={{Resolved}} via https://bugzilla.wikimedia.org/show_bug.cgi?id=63207|status=resolved}}

:Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 23:58, 1 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: We've got a patch in for review on this issue: bug [[bugzilla:63207|63207]]. Thanks! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 21:15, 2 April 2014 (UTC)
:It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. [[User:Salix|Salix]] ([[User talk:Salix|talk]]) 08:33, 2 April 2014 (UTC)
{{Archive bottom}}

== Hovercards showing up when scrolling ==
{{Archive top|result={{Resolved}}|status=resolved}}

:I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.
:An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 00:04, 2 April 2014 (UTC)
::[[User:Juliusz Gonera|Juliusz Gonera]]: Seems reasonable, want to submit a patch? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:01, 3 April 2014 (UTC)
:::[[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]]: Done (https://gerrit.wikimedia.org/r/123790) [[User:Juliusz Gonera|Juliusz Gonera]] ([[User talk:Juliusz Gonera|talk]]) 21:56, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]] Awesome cc:[[User:Prtksxna|Prtksxna]] [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 23:08, 3 April 2014 (UTC)
:::[[User:Juliusz Gonera|Juliusz Gonera]]: Thanks for the patch! I'll merge it as soon a possible. [[User:Prtksxna|Prtksxna]] ([[User talk:Prtksxna|talk]]) 10:13, 4 April 2014 (UTC)
:My thoughts exactly, thank you. [[User:Eman235|Eman235]] ([[User talk:Eman235|talk]]) 00:13, 4 April 2014 (UTC)
:Thank you very much for preparing this patch. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:10, 4 April 2014 (UTC)
{{Archive bottom}}

== Difficult to select and copy the text of a link ==

The popups makes the selection of [[#|the text of a link]] more difficult. [[User:He7d3r|Helder]] 15:49, 2 April 2014 (UTC)
:The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 08:00, 3 April 2014 (UTC)
:It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. [[User:He7d3r|Helder]] 18:54, 3 April 2014 (UTC)
:Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)
:I remember these common cases for now:
:* To copy the user name of someone, to insert in a <nowiki>{{U|...}}</nowiki> template;
:* To copy the title of a page to explain something about it
:* To quote something another user said in a link
:* To copy a comment I just wrote in a discussion from the preview to the summary [[User:He7d3r|Helder]] 14:59, 4 April 2014 (UTC)

== Error: Cannot read property ==
{{Archive top|result=Hovercards are now limited to Article namespace this should be resolved now|status=resolved}}

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 03:15, 3 April 2014 (UTC)
:And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. [[User:Frozen-mikan|Frozen-mikan]] ([[User talk:Frozen-mikan|talk]]) 06:22, 4 April 2014 (UTC)
{{Archive bottom}}

== Окон нет ==

И что? Где эти окна?? Их нет! [[User:Angeil Rogozina|Angeil Rogozina]] ([[User talk:Angeil Rogozina|talk]]) 05:16, 3 April 2014 (UTC)
:[[User:Angeil Rogozina|Angeil Rogozina]] are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.
:From google translate—
:вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. [[User:Jaredzimmerman (WMF)|Jaredzimmerman (WMF)]] ([[User talk:Jaredzimmerman (WMF)|talk]]) 07:57, 3 April 2014 (UTC)

== Nice feature but has many problems ==

Can you please explain the issues you are experiencing? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 04:09, 4 April 2014 (UTC)

== overlaps with the gadget 'Navigation popups' ==

:with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?
:after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.
:another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. [[User:Alveolate|Alveolate]] ([[User talk:Alveolate|talk]]) 19:37, 4 April 2014 (UTC)
::[[User:Alveolate|Alveolate]]: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). [[User:OmgItsTheSmartGuy|OmgItsTheSmartGuy]] ([[User talk:OmgItsTheSmartGuy|talk]]) 17:30, 5 April 2014 (UTC)
:I much prefer the navigation popups.
:1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)
:2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.
:The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. [[Special:Contributions/108.44.44.121|108.44.44.121]] ([[User talk:108.44.44.121|talk]]) 13:50, 5 April 2014 (UTC)
::Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. [[User:Ellsass|Ellsass]] ([[User talk:Ellsass|talk]]) 13:51, 5 April 2014 (UTC)

== Font size on hovercards are very small when using the Monobook skin ==
{{Archive top|result=We're unable to do fixes for non-default skins at this time due to resourcing, however if community developers would like to submit fixes it would be appreciated.|status=resolved}}

This problem does not appear when using the Vector skin. [[User:Lennieii|Lennieii]] ([[User talk:Lennieii|talk]]) 04:39, 5 April 2014 (UTC)
:Also happening in Modern skin.
:Cologne Blue shows legible fonts, but notably smaller than Vector.
:Maybe this issue is affecting many other skins. [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 04:01, 6 April 2014 (UTC)
:As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:48, 8 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.
::There is problem with unrecognisable diacritic marks žščřáéíóů [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:50, 22 April 2014 (UTC)
{{Archive bottom}}

== Needs more features ==

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard [[User:Kangaroopower|'''Kangaroo''']][[User Talk:Kangaroopower|'''powah''']] 05:18, 5 April 2014 (UTC)
:[[User:Kangaroopower|Kangaroopower]]: true [[User:Daughterofathena101|Daughterofathena101]] ([[User talk:Daughterofathena101|talk]]) 06:27, 5 April 2014 (UTC)

== Lacks useful features of old hoverboxes ==

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. [[Help:Navigation#Sidebar]]) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on [http://en.wiktionary.org/wiki/Main%20Page Wiktionary] because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. [http://en.wiktionary.org/wiki/a#French a#French]). [[User:Wikitiki89|Wikitiki89]] ([[User talk:Wikitiki89|talk]]) 00:09, 6 April 2014 (UTC)
:Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. [[User:Imagine Wizard|Imagine Wizard]] ([[User talk:Imagine Wizard|talk]]) 22:24, 16 April 2014 (UTC)

== IPA Tooltip ==

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh"
- /ɑː/ like the "a" in "father"
- "w" as in "wind"
- /ɑː/ like the "a" in "father"
- "t" as in "tie"
- /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) [[User:NBMATT|NBMATT]] ([[User talk:NBMATT|talk]]) 00:45, 6 April 2014 (UTC)

== Parametr $1 translation message not found ==

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where he? [[User:Arystanbek|Arystanbek]] ([[User talk:Arystanbek|talk]]) 05:44, 7 April 2014 (UTC)
:Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:42, 8 April 2014 (UTC)
:This string can’t be translated on Translatewiki.net: the Hovercards extension includes the [http://momentjs.com/ Moment.js] library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization [https://github.com/moment/moment on GitHub], but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to [[MediaZilla:63873|update their copy of Moment.js]]. [[User:Mxn|Minh Nguyễn]] [[User talk:Mxn|💬]] 07:29, 13 April 2014 (UTC)

== nice but have some problems with it - pics, none relevant text appearance, empty area ==

* the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
* in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
* sometimes it opens with an empty area - i assume, an absent image. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 03:39, 8 April 2014 (UTC)
:Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:02, 8 April 2014 (UTC)
:yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add: 
:4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. [[User:Dalilonim|Dalilonim]] ([[User talk:Dalilonim|talk]]) 06:17, 9 April 2014 (UTC)

== Add a option show one preference interwiki ==

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by [http://zh.wikipedia.org/wiki/User:%E5%96%B5 zh:User:喵].

:window.popupHomeLanguage = "en";
:importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');
:importScript('User:喵/fork/MediaWiki:Gadget-popups.js');
:importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); [[User:乌拉跨氪|乌拉跨氪]] ([[User talk:乌拉跨氪|talk]]) 11:59, 8 April 2014 (UTC)

== Nice feature ==

I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.

1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.

2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).

3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards

4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?

5. Disable hovercards in the watchlist.

6. Disable hovercards on the view history page.

7. Disable hovercards on WikiProject pages [[User:Wolbo|Wolbo]] ([[User talk:Wolbo|talk]]) 12:33, 8 April 2014 (UTC)
:Thank you for all the feedback.
:There is a bug out for item 3 & one for items 5, 6, 7.
:Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:53, 8 April 2014 (UTC)

== It's really nice, but... ==

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? [[User:בנימין|בנימין]] ([[User talk:בנימין|talk]]) 05:29, 11 April 2014 (UTC)
:Thanks for the comment, Binyamin.
:A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation ''hatnote'', such as [http://en.wikipedia.org/wiki/Template:About en:Template:About]. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. [[User:Amire80|Amir E. Aharoni]] {{[[Global templates|🌎🌍🌏]]}} 13:28, 18 April 2014 (UTC)

== Thanks ==

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) [[User:Vis M|Vis M]] ([[User talk:Vis M|talk]]) 22:28, 13 April 2014 (UTC)
:Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 17:53, 4 May 2014 (UTC)

== Save space in redirect cards? ==

Instead of having "redirects to" taking up extra space in the card, why not just add the [https://commons.wikimedia.org/wiki/File:Redirectltr.png redirect arrow] next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 22:25, 17 April 2014 (UTC)
:Great idea! We are eliminating the 'redirect' labels. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:18, 21 April 2014 (UTC)

== Translation to Hungarian ==
{{Archive top|result={{Resolved}}|status=resolved}}

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 17:28, 18 April 2014 (UTC)
:Thank you for pointing this out, I'm checking and will get back to you. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:17, 21 April 2014 (UTC)
:I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:45, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: Thank you! Found it and translated all texts. [[User:Xia|Xia]] ([[User talk:Xia|talk]]) 13:53, 24 April 2014 (UTC)
{{Archive bottom}}

== Actions from the original navigation popups gadget ==

:We are trying to better understand the usage of the original gadget. Specifically -
:1. Investigate which actions from the original gadget are useful
:2. How do editors use the navigation popup - Do they read the extract and the statistics?
:If you used the original gadget, please add your comments with explanation here. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 23:01, 18 April 2014 (UTC)
::The actions I use most are
::*Diffs (from watchlist, history, contribs, etc; including from other popups)
::*History
::*User contribs (including from history popups)
::*Multi-level popups (article popups from other article popups
::I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 18:02, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: first and foremost, diffs.
::for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).
::second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.
::this works for real links in the article, and also the link of "→ <nowiki><section>" in history, watchlist and recent changes pages etc.</nowiki>
::peace. [[User:קיפודנחש|קיפודנחש]] ([[User talk:קיפודנחש|talk]]) 22:52, 19 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. [[User:Chris troutman|Chris Troutman]] ([[User talk:Chris troutman|talk]]) 11:01, 22 April 2014 (UTC)
:::[[User:Chris troutman|Chris troutman]]:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:30, 23 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. <code style="font-size:small;white-space:nowrap">-- [[[[User:Edokter|User:Edokter]]]] {{[[User talk:Edokter|talk]]}}</code> 11:03, 22 April 2014 (UTC)
:::[[User:Edokter|Edokter]]: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 20:40, 23 April 2014 (UTC)
::For all pages:
::* Read Preview (recursive)
::* Watch/Unwatch
::* View History (recursive)
::* Open Talkpage in new tab
::* Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day
::For Users:
::* View Contributions (recursive) - to check specific contribs, and to check recent activity levels
::* Open Talkpage in new tab
::* "Space" - Search Subpages (Special:Prefixindex)
::* User stats (groups, editcount, first join date)
::** I wish it included a "last edited" time.
::* I wish it included a link to [[Special:CentralAuth]] or [https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php SUL Info]
::Custom-additions:
::* popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
::* popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left [[Talk:Beta_Features/Hovercards/Archive_1#Ideal_timings_for_show_and_hide|notes on timing at the archived page]] which I think warrants research.)
::Note: There are already a few layout options for Navpopups, [http://en.wikipedia.org/wiki/Wikipedia:Popups/Structure%20examples en:Wikipedia:Popups/Structure examples], though I'm not sure how widely these are used.
::I'd suggest asking the Research dept to put together stats on how much each of those, and the other [http://en.wikipedia.org/wiki/Wikipedia:NAVPOP#Options en:Wikipedia:NAVPOP#Options] are used, if possible. That options list is ''well'' worth reading, to get a sense of its power/complexity. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 20:59, 22 April 2014 (UTC)
:# Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
:# Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
:# Fixing links (redirects, disambiguations).
:# Viewing diffs —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 18:56, 19 April 2014 (UTC)
:How can I invite more community members to participate in this audit? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 21:04, 21 April 2014 (UTC)
::[[User:Vibhabamba|Vibhabamba]]: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. [[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 21:45, 21 April 2014 (UTC)
:Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:20, 21 April 2014 (UTC)
:Personally, for articles I've only ever used:
:* View history
:* Most recent edit
:* Talk
:and for Users:
:* Contributions
:* Talk
:I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 23:52, 21 April 2014 (UTC)
:Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.
:Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. [[User:Barte1|Barte1]] ([[User talk:Barte1|talk]]) 15:17, 24 April 2014 (UTC)

== Text summaries are clipped awkwardly sometimes. ==

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the [http://www.psychwiki.com/wiki/Zeigarnik_Effect zeigarnik effect]. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered [http://blog.assaflavie.com/wikipedia/#thealternative here].)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! [[User:Connor Krammer|Connor Krammer]] ([[User talk:Connor Krammer|talk]]) 17:42, 19 April 2014 (UTC)
:Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.
:Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 22:00, 21 April 2014 (UTC)
:I believe we have some language engineering folks who can help figure this out. Pau Giner? [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 18:42, 23 April 2014 (UTC)
:Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.
:It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.
:An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).
:Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. [[User:Pginer-WMF|Pginer-WMF]] ([[User talk:Pginer-WMF|talk]]) 21:06, 23 April 2014 (UTC)
:Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 04:19, 27 April 2014 (UTC)
::[[User:Santhosh.thottingal|Santhosh.thottingal]]: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:32, 28 April 2014 (UTC)
:::[[User:TheDJ|TheDJ]]: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. [[User:Santhosh.thottingal|Santhosh.thottingal]] ([[User talk:Santhosh.thottingal|talk]]) 11:53, 28 April 2014 (UTC)

== Longer delay in categories ==

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. [[User:JAn Dudík|JAn Dudík]] ([[User talk:JAn Dudík|talk]]) 10:47, 22 April 2014 (UTC)
:I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. [[User:Wrh2|Ryan]] • ([[User talk:Wrh2|talk]]) • 18:36, 2 May 2014 (UTC)

== Include an opt-out for images? ==

:I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).
:Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.
:Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.
:I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.
:Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) [[User:AmericanLemming|AmericanLemming]] ([[User talk:AmericanLemming|talk]]) 16:18, 22 April 2014 (UTC)
::[[User:AmericanLemming|AmericanLemming]]: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.
::To me, it doesn't matter whether the image renders well or not. It just takes up too much space.
::So, I suggest an '''''opt-in''''' for images. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 01:09, 24 April 2014 (UTC)
:Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.
:As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). [[User:Malcolmj1|Malcolmj1]] ([[User talk:Malcolmj1|talk]]) 21:03, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:19, 28 April 2014 (UTC)

== Feedback ==

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. [[User:Aschmidt|Aschmidt]] ([[User talk:Aschmidt|talk]]) 00:09, 23 April 2014 (UTC)
:Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.
:I hope that helps you understand our decision to not include actions. Thanks for your feedback! [[User:Deskana (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:Deskana (WMF)|talk]]) 17:48, 28 April 2014 (UTC)

== Opt-In ==

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. [[User:Anythingyouwant|Anythingyouwant]] ([[User talk:Anythingyouwant|talk]]) 16:58, 24 April 2014 (UTC)
:I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 03:18, 27 April 2014 (UTC)
:I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 02:20, 28 April 2014 (UTC)
:Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —[[User:TheDJ|TheDJ (Not WMF)]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 10:16, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The difference between top/side is image-dimensions: landscape vs portrait.
::I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and [https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rtcutc9t2ih32v25 Include an opt-out for images?] below. –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 21:01, 28 April 2014 (UTC)
::[[User:TheDJ|TheDJ]]: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. [[User:Vibhabamba|Vibhabamba]] ([[User talk:Vibhabamba|talk]]) 07:08, 29 April 2014 (UTC)

Requests for comment/Phabricator

2014-04-27T21:50:43Z

RandomDSdevel: /* In favor of Phabricator */ Fixed thread indentation.

<big>'''''Participate in the [[Talk:Requests for comment/Phabricator#Format and schedule of the RfC|first round of feedback]] by April 27'''''</big>
{{RFC
| component = 
| created = 2014-03-28 
| authors = [[User:AKlapper (WMF)|Andre Klapper]], [[User:guillom|Guillaume Paumier]]
| draft = final draft
| implementation = not started
}}
== Problem ==

The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and, all in all, the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome for both current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state of affairs and wish to consolidate the development toolchain.

See the [http://lists.wikimedia.org/pipermail/teampractices/2013-December/000205.html full email thread] for more background.

== Background ==
{{Project management tools review}}
This is what has been done so far:
* People have [[mw:Talk:Project management tools/Review|shared their needs]] and workflows.
* Andre and Guillaume have [[mw:Project management tools/Review/Requirements|summarized all of that]] into consolidated requirements.
* Andre and Guillaume have set up a [[mw:Project management tools/Review/Options|list of options]] to solve our problem, based on what was mentioned during preliminary discussions.
* People have [[mw:Talk:Project_management_tools/Review/Options|discussed the options]] and eliminated some of them in preparation for the RfC.
* Besides the wiki, communication has happened mainly on the [http://lists.wikimedia.org/pipermail/teampractices/ teampractices] list, with updates also sent to [http://lists.wikimedia.org/pipermail/wikitech-l/ wikitech-l].
* We're now drafting this RfC and welcoming edits on both the form and the content.
The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other.

{{clear}}
<div style="border:1px solid #AAA; background:#f9f9f9; width:25%; margin:1em; padding:1em; float:right;">
{{:Requests for comment/Phabricator/FAQ}}
</div>

== Proposal: Move to Phabricator ==

This proposal consists of replacing several of our tools with one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. This means you'll only need one account for everything, and all tasks / bugs / commits / screenshots will be cross-referenced automatically. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.

You can [http://fab.wmflabs.org/ test Phabricator] in Labs. This is an actual test instance, so don't be afraid to break things.

If this proposal fails to gather agreement, we will keep the status quo. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year. We may want to consider consolidating our project management tools later into [https://scrumbu.gs/ Scrumbugz] (a tool that works on top of Bugzilla) but that will be a separate discussion.

You're welcome to contribute to the [[Requests for comment/Phabricator/FAQ|developing FAQ]] and browse the [http://fab.wmflabs.org/project/board/14/ Wikimedia Phabricator] project in our test instance, which we're using to identify missing features and plan the possible migration.

=== In favor of Phabricator ===

* But migration of existing content (including closed bugs, etc.) is critical. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk:Jdforrester (WMF)|talk]]) 00:24, 15 April 2014 (UTC)
* --[[User:JEissfeldt (WMF)|JEissfeldt (WMF)]] ([[User talk:JEissfeldt (WMF)|talk]]) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James
* +1 to what James said. BZ data must be migrated. ^[[User:^demon|demon]][[User_talk:^demon|[omg plz]]] 16:40, 15 April 2014 (UTC)
* Support as long as teams can still user third party tools like Trello as necessary [[User:Tfinc|Tfinc]] ([[User talk:Tfinc|talk]]) 00:20, 17 April 2014 (UTC)
* The idea of having developers, designers, product managers, and just any volunteer using one tool with their Wikimedia credentials is worth fighting for. The migration will be complex, [http://fab.wmflabs.org/T37 but we are planning for it]. Phabricator is coded in PHP, a language that MediaWiki developers are familiar with, and the upstream project takes feedback and patches.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:50, 17 April 2014 (UTC)
* I imagine there will be a lot of "ZOMG my favorite feature of X isn't here" but I think having issues and code review and planning all in one pile would be worth the pain of learning a new set of tools. [[User:BDavis (WMF)|BDavis (WMF)]] ([[User talk:BDavis (WMF)|talk]]) 17:12, 17 April 2014 (UTC)
* I think it will be worth the effort. [[User:Grunny|'''Grunny''']] ([[User talk:Grunny|talk]]) 18:03, 17 April 2014 (UTC)
* While I feel the current tools meet the needs (AFAIK), Phabricator's oneness seems to be much better with one account for every service as opposed to every account for every service. What James said it pretty much critical with this. [[User:John F. Lewis|John F. Lewis]] ([[User talk:John F. Lewis|talk]]) 17:33, 18 April 2014 (UTC)
* I like the fast diff-view in Phabricator (diffs of huge files are almost impossible to view in gerrit for me and I do not want to view them in a custom diff viewer every time; with Opera, I struggle in gerrit anyway), the fact that it is all-in-one and most important to me that it is possible to create profiles so I can hopefully see to whom I am talking. I think it's worth migrating, although the terminology is fundamentally different. -- [[User:Rillke|Rillke]] ([[User talk:Rillke|talk]]) 11:25, 20 April 2014 (UTC)
* per others. --[[User:Zhuyifei1999|Zhuyifei1999]] ([[User talk:Zhuyifei1999|talk]]) 12:16, 20 April 2014 (UTC)
* For volunteers like me, who spend only a few hours during their spare time on Mediawiki development, it takes a lot of time to get along with all the tools. Furthermore it's sometimes strange that some information like RT or ORTS is hidden. (How do I sign with VE?)--[[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 12:45, 20 April 2014 (UTC)
* Strongly in favor. Phabricator is a pleasure to use. It strikes me as having been designed and architected with awareness of the pain-points of collaborative software development. The interface has a way of nudging you towards positive, constructive interactions. Its command-line tool, arc, is superb. The documentation is excellent. Upstream is very responsive. Features like [https://secure.phabricator.com/book/phabricator/article/herald/ Herald] are innovative and useful. Let's do it. --[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 19:51, 20 April 2014 (UTC)
* In favour. This would be a nice change, and has much better functionality than the antiquated bugzilla. [[User:Ajraddatz|Ajraddatz]] ([[User Talk:Ajraddatz|Talk]]) 21:56, 20 April 2014 (UTC)
* Strongly in favour of this. Both Bugzilla and Gerrit aren't the best platform in my opinion, and Phabricator looks much better. I especially like Phabricator being based on PHP, since Bugzilla's Perl code was something I never liked. --[[User:GeorgeBarnick|GeorgeBarnick]] ([[User talk:GeorgeBarnick|talk]]) 21:59, 20 April 2014 (UTC)
* I want ''one place'', not three or four, to go document and discuss patches and the issues related to them. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:17, 21 April 2014 (UTC)
* I will favor anything that lets me edit code online, instead of having to install specialized software, keeping a local copy of the code and hand-crafting patches. (I asume some form of local-repository development will remain possible.) — [[User:Edokter|Edokter]] ([[User talk:Edokter|talk]]) — 11:26, 21 April 2014 (UTC)
* I honestly do not care all that much for Phabricator's current UI, but I expect that it can be tweaked as we gain expertise with it (or that it can be ''made'' to be tweakable). The point for me is that the status quo is not tenable: having to use at least six disjoint tools that barely interface with each other just to do day-to-day work is a guaranteed recipe to have things fall between the cracks. It also means that even if we ''do'' end up having to hammer our workflow into the code, there is just the one tool to fiddle with. — [[User:MPelletier (WMF)|MPelletier (WMF)]] ([[User talk:MPelletier (WMF)|talk]]) 12:52, 21 April 2014 (UTC)
* '''Strong support''' per Ori and Steven. [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 17:01, 21 April 2014 (UTC)
* Folks commenting in the "No" column should recognize that tools like Trello and Mingle haven't made it into the WMF workflow for whimsical reasons; Bugzilla simply lacks an adequate project management workflow. In the absence of better PM tools, we'll have a fragmentation of information flows which leads to its own inefficiencies. Tools like Scrumbugz seek to address this, but it's in the context of an aging, rigid codebase. Phabricator is built to support modern development practices and looks very promising from everything I've seen so far (proliferation of silly proper noun names for different functions notwithstanding). I think an incremental migration with checkpoints on real-world issues is the way to go.--[[User:Eloquence|Eloquence]] ([[User talk:Eloquence|talk]]) 17:10, 21 April 2014 (UTC)
* Well I'm hugely biases since I was advocating Phabricator when it was a decision between that and Gerrit. (Having said that, the reasons others gave for not switching were very viable at the time only to be mitigated by Phabricator's continued upward trajectory.) I caution people during the migration for an expectation of a feature-for-feature parity improvement is not in the cards, but on balance the rewards outweigh the loses, and this has been the case for many PHP-based software endeavors both closed and open-source as evidenced at how low the churn has been away from using Phabricator. [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:31, 21 April 2014 (UTC)
*: (Wanted to put this below, but I couldn't figure a good place in the other options to put it). I have concerns about the logistics of this migration. I think it might be easiest to transfer via Gerrit, then PM tools (Trello, Mingle, etc), then Bugzilla. The first requires just alignment on developers and actually removes some unnecessary overhead. The second should be staggered on a project-by-project basis over a longer duration as the positives outweigh the negatives (as the teams would have to migrate their existing entries or had specific reasons/features that caused them to use a certain tool). The third probably last as it involves the largest institutional inertia and affected people, however the full benefit won't be seen until Bugzilla is integrated. Not sure if it can be staggered or what the transition looks like, but I do thing while it should be handled right, some compromise on the loss of a couple of data fields should be acceptable (a lot of metadata in Bugzilla is useless/archaeic). [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:32, 21 April 2014 (UTC)
* Strong support for everything in one place. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 21:38, 21 April 2014 (UTC)
* Support for the unification of development in a single place, as someone who has primarily used these tools for looking at what's in development and for reporting bugs. Right now it's a huge pain to navigate Bugzilla and submit things, and the disconnect between Bugzilla and Gerrit is fairly annoying. --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 21:43, 21 April 2014 (UTC)
**Cannot. Agree. More. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 23:30, 21 April 2014 (UTC)
* Support - Phabricator has come a long way in the past couple of years. What looks awfully promising about it is that they seem to have a coherent vision for providing tools that make development teams productive, and a focus on important things that most tools in this space neglect (user interface, performance, and a sense of humor). From all outward indications, the upstream will be a joy to work with, and the tool is in a programming langauge (PHP) that we have a lot of familiarity with. The migration promises to be a miserable experience (all migrations of this scale are...no matter how great the tool), but this is the first toolset I've seen that looks likely to be worth the pain. -- [[User:RobLa-WMF|RobLa-WMF]] ([[User talk:RobLa-WMF|talk]]) 00:25, 22 April 2014 (UTC)
** Speaking of the 'sense of humor,' maybe we could somehow import those funny quotes that users can optionally make Bugzilla put at the top of every page of that tool's search results while we're importing it whether we do this importing manually or automatically? — [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:45, 27 April 2014 (UTC)
*This would be awesome. The current mess of tools (especially bugzilla vs trello vs mingle) is quite frustrating for finding whether something is already noted, and has made me not want to enter bugs for myself (especially in Bugzilla with its irritating login requirements). SUL integration would be great if possible. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 01:27, 22 April 2014 (UTC)
* Strong support: per others, it's always a good idea to have one place for all tasks. [[User:Chmarkine|Chmarkine]] ([[User talk:Chmarkine|talk]]) 03:44, 22 April 2014 (UTC)
* Support - I haven't used dev tools yet, it would be easier to have 1 place to go and start [[User:Aprillion|Aprillion]] ([[User talk:Aprillion|talk]]) 12:17, 22 April 2014 (UTC)
** '''Support''': Me neither, really; I've filed bugs in Bugzilla, but it's a 'bit' of a ''pain'' to use since it's interface is so archaic. Phabricator sounds like a great tool to move all of our development stuff to, and I might just start helping out some once all of the dust settles (or maybe even ''before'' then; it all depends on whether I'm available or not due to the facts that I plan to start learning [[en:wp:C++|en:wp:C++]] pretty soon and that this might take up a lot of my time.) — [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:49, 27 April 2014 (UTC)
* Support - having all tools in one place can only be a good thing. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:29, 22 April 2014 (UTC)
* Support - Based on what I know so far, I support moving to Phabricator. The top practical problem I face with the current solution is going back and forth between Trello and Bugzilla, but see below for secondary issues. However, we do need to ''ensure'' we're not just adding another tool without replacing/removing anything. This means at least turning off/redirecting/marking read-only Bugzilla and Gerrit. The most realistic way to accomplish that is to do a complete migration of ''at least'' Bugzilla, ideally other issue tracking tools like Trello, Mingle, etc., and possibly others like Gerrit. I've already seen some cool features in Phabricator (e.g. updateable mocks, drag-and-drop file uploading, simple embedding and linking and CCing (oddly, Trello does not allow you to CC other users). It also should allow much tighter integration between Gerrit and Bugzilla (no more getting two Bugzilla emails after you upload a patch to Gerrit, and perhaps auto-fixing bugs based on a commit message tag). Being written in PHP is definitely helpful. It will not magically mean every MediaWiki PHP dev works on Phabricator, but it will hopefully encourage creating a critical mass of collaboration with upstream. I also strongly support using open source infrastructure, so this is a step in the right direction on that front. There will definitely be switching costs and issues, but so far it looks like it will be worth it. [[User:Superm401|Superm401]] - [[User_talk:Superm401|Talk]] 21:38, 22 April 2014 (UTC)
* '''Strong Support''' - There are issues with Phabricator, like any single tool that would be an option (there is no unicorn that covers all use-cases efficiently), but I think it's biggest strength is Evan P and the Phabricator community. His responses to our suggestions/requests have been amazing. And it isn't just us. Other organizations that have migrated to Phabricator have had similar experiences; someone reports an issue that Phab has with their internal work flow, a week later Even P comes back with a fix, before the org (devianArt in this case) could even start working on it. Evan P and the rest of the Phab community is awesome and are an upstream that I want to work with more than pretty much any other. And in the long term, the relationship you have with your upstream is tantamount to pretty much anything else. [[User:Greg (WMF)|Greg (WMF)]] ([[User talk:Greg (WMF)|talk]]) 16:04, 23 April 2014 (UTC)
* Support, even though I have not used other tools (yet) than Bugzilla, but it's always better to have everything at the same place (if possible). --[[User:Stryn|Stryn]] ([[User talk:Stryn|talk]]) 17:58, 23 April 2014 (UTC)
* I have been playing with it for a while and I say '''Let's go get this thing deployed on our servers''' [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 07:36, 24 April 2014 (UTC)
* Support - Yes please -[[User:Fastily|<big>F</big>ASTILY]] [[User talk:Fastily|(TALK)]] 00:13, 25 April 2014 (UTC)
* '''Support''' the pain is real! Copying issues between bugzilla and {team's Project Management tool}, the disjointed concurrent discussion in bugzilla|gerrit|{team's Project Management tool}, the mindless busywork of keeping the state of an issue up-to-date in all three tools, the redundant notifications that this busywork generates, ... A ''fourth'' area that Phabricator integrates is design mockups, an area where the MediaWiki community has never had a good tool. You can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people can comment on it, see http://fab.wmflabs.org/M1/1/ . -- [[User:S Page (WMF)|S Page (WMF)]] ([[User talk:S Page (WMF)|talk]]) 19:36, 25 April 2014 (UTC)
* Support - As someone considering getting into extension development/generally helping out in the next few months, learning to use one tool is much less intimidating than trying to figure out a workflow across five different sites. Phabricator, from my exploration of it, looks nice and intuitve for all the basics.-[[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 19:41, 25 April 2014 (UTC)
* Yes. However, It should be possible to use Wikimedia/Wikitech account to log in to Phabricator, rather than having an independence system (currently you need to create a new account to Bugzilla). (In the future, I hope Wikitech can be added to [https://noc.wikimedia.org/conf/highlight.php?file=all.dblist all.dblist], so that users can use SUL account to log in WMFlabs, rather then create a new account: current account in Wikitech would be merged to SUL ones.)--[[User:GZWDer|GZWDer]] ([[User talk:GZWDer|talk]]) 12:21, 26 April 2014 (UTC)
* Support - Moving to one integrated toolset seems like a dream come true. --[[User:Lydia Pintscher (WMDE)|Lydia Pintscher (WMDE)]] ([[User talk:Lydia Pintscher (WMDE)|talk]]) 17:41, 27 April 2014 (UTC)
* I believe that a single integrated system is absolutely a good idea. The sheer number of tools being used simultaneously at present is bewildering (RT is involved somewhere as well?!). However the comments on display here lead me to feel that Phabricator appears to require a little more work before it's quite ready. I have two other concerns: firstly, there needs to be an assurance that after the change Bugzilla will be maintained in read-only mode forever; it has a decade's worth of incoming links that shouldn't be broken. Secondly, when Bugzilla bugs are imported, will their entire comment history be imported as well? I think that it should. The discussions associated with bugs are by far the most important aspect of the whole thing. If dealing with a bug in the new system requires having to scoot back to Bugzilla to pick up on all the context and/or previous decisions, that messes up the point of only having a single bugtracker. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 13:14, 27 April 2014 (UTC)
** Yes {{u|Scott}}, [http://fab.wmflabs.org/T55 RT is part of the plan]. [http://fab.wmflabs.org/T65 Redirects of Bugzilla URls to Phabricator] are also planned and, yes, we are talking about importing all reports including the comments. There should be no need to keep the Bugzilla instance available forever, but we can allow ourselves as much time as needed. You can check and discuss the details at [http://fab.wmflabs.org/T39 http://fab.wmflabs.org/T39]. "Phabricator appears to require a little more work before it's quite ready", maybe, you can help defining exactly what needs to be done before the migration, see [http://fab.wmflabs.org/T43 Define what features existing in our current tools are really missing in Phabricator] and dependent tasks.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:29, 27 April 2014 (UTC)
*** I only have experience using WMF's Bugzilla but I'll certainly contribute anything I notice about Phabricator - obviously I've not had much time to investigate it. Thanks for the links. That's good news about the import, too - in which case I guess then just so long as URL redirects are set up for old Bugzilla URLs there'll be no need to keep the old system around. So given all that, I've moved this to the support area. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:34, 27 April 2014 (UTC)
**** After just a few minutes of playing with Phabricator - ''boy howdy!'' Bugzilla feels like the stone age compared to this thing. I have no doubt that any features people consider missing can be added upstream. Consider me sold. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 21:27, 27 April 2014 (UTC)
* Support per above - it's better to have everything centralized in just one place. [[User:LlamaAl|LlamaAl]] ([[User talk:LlamaAl|talk]]) 19:08, 27 April 2014 (UTC)

=== In favor of keeping our current tools ===

* I would like to see a rough roadmap of the migration and what task force is going to be allocated to it. I looked a bit around and could not find how we are going to handle the transition. I dont mind changing tools, but I wish we handle it as a proper project or we risk spending a couple years doing the migration on a best effort basis. So until we have a migration plan, I will remain suspicious. [[User:Hashar|Antoine "hashar" Musso]] ([[User talk:Hashar|talk]]) 21:08, 17 April 2014 (UTC)
*: [http://fab.wmflabs.org/project/view/14/ Everything is being tracked] in our test instance itself: [http://fab.wmflabs.org/T37 how to migrate everything], [http://fab.wmflabs.org/T43 what features are currently missing], [http://fab.wmflabs.org/T59 how to configure it] for our needs, even the [http://fab.wmflabs.org/T41 resource planning]. Is this what you were looking for? It's still incomplete, but resources for a migration task force won't be allocated unless this RFC shows explicit support from the technical community. [[user:guillom|guillom]] 14:01, 18 April 2014 (UTC)
* Meh, I hate changing systems which (apparently) work. Though, I don't feel strongly on this issue. [[User:Vogone|Vogone]] [[User talk:Vogone|'''talk''']] 17:37, 18 April 2014 (UTC)
* "The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists" so you want to add one more? But if you show me the way how to force all people to move to the new system I may support. (And no it's not disabling old tools which would just mean loosing usefull stuff of users who would not give up (or wont know how to move) even under such conditions as it's with TS -> Labs move in some way happened) --[[User:Base|Base]] ([[User talk:Base|talk]]) 14:04, 19 April 2014 (UTC)
*: It's not "adding one more" as we are after ''replacing'' systems. Old systems become read-only or disabled, if that's how you interpret "forcing". --[[User:AKlapper (WMF)|AKlapper (WMF)]] ([[User talk:AKlapper (WMF)|talk]]) 07:07, 20 April 2014 (UTC)
*: There is some precedent for "replacing" over "adding" that might mitigate some of the pessism: In 2012, Subversion was replaced with Git/Gerrit. On a per-project level, many teams have migrated between multiple project management tools—bulletin board, Wiki, Bugzilla, Trello. Mingle, and Google Doc—never using more than one concurrently for more than 2 weeks during a transition. Also, the major pain point in PM tools cited is poor integration of those tools with Git and Bugzilla (or general crumminess of management capabilities in the case of Bugzilla), this is especially bad for those who have to navigate multiple tools in the course of their work (notably tech leads, scrum master, and product managers). The multiplicity/redundancy is also the source of much friction because of the lack of responsiveness due people not being on a tool (for instance the devs working from Gerrit, while the bug was in Bugzilla) [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:40, 21 April 2014 (UTC)
*It's probably worth integrating MediaWiki with Bugzilla more. Bugzilla has an API. If WMF could also work on making Bugzilla more mobile-friendly and "user-friendly", I'm sure everyone would appreciate it. [[User:Gryllida|Gryllida]] 07:22, 20 April 2014 (UTC)
** We don't use MediaWiki for a project management and issue-tracker, because that's not what it is for. For years, we did code review on-wiki (see [[Special:Code/MediaWiki/status/resolved|examples]]) and it was a nightmare to work with. A wiki is a great tool for documenting things. It's not a code review tool or issue tracker. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:23, 21 April 2014 (UTC)
* 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. [[User:Hym411|—]] [[User talk:Hym411|Revicomplaint?]] 07:28, 20 April 2014 (UTC)
*I don't think any change is required at the moment. Bugzilla, Gerrit, etc. are quite adequate for our current needs. I have never had any problems or concerns with them. The integration between the tools may be a bit hackish at times, but to me, the fact that the current systems are in widespread use and perhaps already familiar to newly-arriving developers is more important. What's more, I don't like Phabricator. It's a rather intimidating web app which looks like it could have a steep learning curve, and could undo some of the good work of people like Quim in attracting new developers to the WMF's projects. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 09:58, 20 April 2014 (UTC)
**For what is worth, one of the reasons why I support Phabricator is to offer to new contributors a single tool with Wikimedia SUL that fits in the expectations of regular GitHub users. Currently it is painful to send newcomers to Bugzilla and Gerrit in addition to mediawiki.org, while having teams more and more invested in Trello/Mingle (because Bugzilla won't handle the PM work) is a pain for everybody, newcomers included.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:50, 21 April 2014 (UTC)
**Personally, I find having to create accounts for multiple different services with different workflows and having to try to figure out how to use every single one separately is far more difficult than if we were to introduce them to a single service which contains all the development work and bug reports in a single location. That, plus the interface is far better looking ''and'' easier to use than Bugzilla (keep in mind that you're used to Bugzilla, so if you can navigate it easily that's probably why). --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 01:50, 22 April 2014 (UTC)
*I'm only commenting on Bugzilla (and slightly RT) here, As i've had limited to no use with the other tools, I don't think think moving will solve any of the "real" issues we currently have, The issue with multiple tools is more due to staffing and cultural issues allowing it to be come so spread out, Whilst some of these tools do have their uses, Some should also be dropped or restricted to very specific use cases, For example RT was introduced because of the security & permissions point of view when needing to deal with outside individuals and a few other small cases it has since basically evolved into a private ops bugtracker with a lot of information that could probably already be in BZ. Also another issue is the maturity and team backing Phab, For example when gerrit was chosen compared to custom writing something like we did with SVN (E:CodeReview) it was decided against because we would land with the same issues about having to maintain the code. [[User:Peachey88|Peachey88]] ([[User talk:Peachey88|talk]]) 08:52, 21 April 2014 (UTC)
** {{u|Peachey88}}, can you explain your last comment? Phabricator is a young project, but they have a significant community and user base that keep gaining momentum, see [https://www.ohloh.net/p/compare?project_0=Bugzilla&project_1=Gerrit+Code+Review&project_2=Phabricator an Ohloh comparison with Bugzilla and Gerrit], and [[w:Phabricator#Users]].--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:40, 22 April 2014 (UTC)
*I think the overhead of migrating and learning the new interface is not worth the effort. Bugzilla works fine for most of what we do. The interface also looks a bit scary to me, although Bugzilla's interface is not completely obvious either. Bugzilla is also used for more free software projects and thus has been proven to work in practice. Basically echoing Revi and TTO's concerns as well. As Multichill mentioned, we don't want to add [https://xkcd.com/927/ another competing standard] for teams to choose from (Trello, Mingle, ...) [[User:PiRSquared17|πr2]] ([[User talk:PiRSquared17|''t'']] • [[Special:Contributions/PiRSquared17|''c'']]) 21:43, 22 April 2014 (UTC)
** This isn't just about replacing Bugzilla. Phabricator lets us consolidate a host of disparate tools (Bugzilla, Gerrit, git.wikimedia.org, others) in to one view of work on MediaWiki. What's more: Bugzilla is clearly not working for Wikimedia Foundation developers, who are doing a large bulk of the work that is tracked in Bugzilla. This is obviously the case when you consider that nearly all teams are using a secondary project management tool on top of Bugzilla, and may even disregard Bugzilla as the canonical list of bugs/issues with a component, because it's such a mess. This doesn't even begin to touch how unfriendly Bugzilla is to non-developers who we want to report issues... [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 21:09, 23 April 2014 (UTC)
* As long as we do not force people to switch to only Phabricator (and forcing would be bad), we'll not reach the desired consolidation of tools, but just add another tool to the set of tools the different teams use. For me, bugzilla and gerrit both have their issues, but they get the job done sufficiently well. Of the many open bugs in our Phabricator, Phabricator's requirement to use "arc" instead of plain git to fetch/push commits bothers me the most. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 22:52, 23 April 2014 (UTC)
** {{u|QChris}}, reply from maintainer epriestley at #phabricator: ''"everything works fine without arc | you get more features and stuff with it, people mostly seem pretty happy about them | but it's absolutely not required | If some of the documentation was misleading in that respect, let me know and I'll fix it."''--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 21:41, 24 April 2014 (UTC)
*** {{u|Qgil}}, I followed up with epriestly. Without arc, you're expected to 'git diff' and copy/paste that in the web UI. That's not a "works fine" for me :-) First, it's really, really inconvenient. And then you'll loose commit metadata that way. Like committer, author, and most important: parent of a commit. But Phabricator does not value this kind of metadata much anyways. For example "arc patch/land" does not honor them either (see upstream ticket [https://secure.phabricator.com/T4333 T4333]). Also, merging a patch is not possible nicely without arc. You have to merge in your repo locally, and then push directly to the branch to bypass review. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 00:04, 25 April 2014 (UTC)

=== Basically neutral ===
* Personally, with the current test installation (microscopic fonts, functions [http://fab.wmflabs.org/T119 hidden behind unlabeled icons], other icons not clickable, tendency to feature bloat, some features like [http://fab.wmflabs.org/T150 voting missing], other features like Gerrit and GitHub integration not testable at the moment) I can't decide if it's worth my time. It could be the greatest thing on earth or turn into a bottomless pit. A project that starts with ''"We can't manage 12 tools! We need to do something!"'' could also end with ''"Now we have 13 tools."'' --[[User:Thiemo Mättig (WMDE)|Thiemo Mättig (WMDE)]] 14:14, 17 April 2014 (UTC)
* I am in favor of trying out Phabricator for a few select projects so we get a better idea of what moving over all projects would mean --[[User:Jeroen De Dauw|Jeroen De Dauw]] ([[User talk:Jeroen De Dauw|talk]]) 19:09, 17 April 2014 (UTC)
* I gave it a try, very stressful so far (I hope not to touch it for a few weeks now, I'll need some discipline). Will need huge amounts of help to figure out, if we really want to kill bugzilla: I expect at least a couple hundreds more bugs need to be filed and triaged, please help with testing. My results so far are visible at [http://fab.wmflabs.org/p/Nemo_bis/] (only partly and only after login, try the [http://fab.wmflabs.org/search/query/advanced/ search]). --[[User:Nemo_bis|Nemo]] 19:10, 19 April 2014 (UTC)
* I'm not convinced that the time invested in changing our code review tool (again) is worth the expected benefits. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 07:40, 20 April 2014 (UTC)
* IM kinda HO we gotta change default avatar on our demo, it's unacceptable for me to use [[w:Psyduck|an NFC image]] as it... --[[User:Liuxinyu970226|Liuxinyu970226]] ([[User talk:Liuxinyu970226|talk]]) 10:15, 20 April 2014 (UTC)
* I share Legoktm's and Thiemo's concerns, but I also see the problem with our current (overwhelmingly) large tool stack. The most important thing over here is to really make the cut on the n tools we have atm and to not have n+1 tools after. - [[User:Hoo man|Hoo man]] ([[User talk:Hoo man|talk]]) 11:45, 20 April 2014 (UTC)
* I'm basically neutral but I couldn't agree more with Antoine: If we're going to change, it should be done with a proper project. When I talk about a project, I'm talking about a project as defined [[:en:PRINCE2|here]]. Clear goal, clear time path, clear budget etc. I'm a bit afraid [https://xkcd.com/927/ this] is going to happen. [[User:Multichill|Multichill]] ([[User talk:Multichill|talk]]) 15:23, 20 April 2014 (UTC)
* I dont mind, I am not a developer. If you think you need it. Do it. But do it once. It take us some time, to get in touch with bugzilla. So we will need some time to get in touch with the new sw. ('''errr, where I have a singnature button in Visual Editor?) '''[[user:Juandev|Juandev]]
* A new system could be nice, I don't really care either way. But we want to make sure users will not be suddenly surprised by this.--[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:18, 21 April 2014 (UTC)
* I largely agree with Multichill, et al. Some specific team (whether that's a Wikimedia Foundation team or a Wikimedia chapter team or a coalition of volunteers) has to take charge of this and properly migrate the current suite of tools to Phabricator. This will be tedious and long and annoying.As long as whatever new tool is implemented has IRC feeds, I'm pretty neutral on the topic. I will say that in my limited interaction with Phabricator, it seems to go out of its way to be gimmicky and obnoxious. I'm wondering if that's a configurable mode. It might be nice to enable rotating cutesy submit buttons and "stickers" in a year or two, but for now, the transition will be difficult enough without Phabricator constantly dressed in a clown costume. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 00:31, 21 April 2014 (UTC)
**The silly names have been turned off already - it's now in "serious business" mode (instead of "fun mode"). Discussion at http://fab.wmflabs.org/T119 –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 22:22, 21 April 2014 (UTC)
*On the one hand, Phabricator is one unified system which will therefore likely reduce the work we need to keep so many separate systems going. On the other hand, it's unclear to me what cost the migration will have, and how much time it will take learning a new system. Without having more data to figure out whether the pluses overcome the minuses, I am basically neutral. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 15:44, 21 April 2014 (UTC)
* I now support this proposal, here is my former opinion: This discussion would be far more simple if we point out the biggest improvements and potential bigest issues that migration would do, so please fill up this list with that is in your mind. I am not really againsted Phabricator, but I really do like bugzilla, as that is one of best open source bug trackers and saying just "let's have 1 tool for everything" is not much of argument to me :) For this reason I created new section with pros cons. [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:48, 21 April 2014 (UTC)
*:Which tools are we actually talking about is it just bugzilla and gerrit that would be unified or is there more of them? [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:51, 21 April 2014 (UTC)
*::The other dimension is project management tools. This includes Mingle and Trello which are actively in use in the WMF, which would also be replaced by Phabricator. People at the WMF have written scripts to actively copy Bugzilla bugs into Mingle and Trello, but these scripts occasionally need maintenance. So, Bugzilla and Gerrit are the big ones most people know about, but there are others. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 17:19, 21 April 2014 (UTC)
*:Most impressive part I found is that it allows regular users to create own repositories. This however needs to be enabled. Would this be enabled on production version of phabricator? I am not using our gerrit only because I have to wait weeks or months for repositories to be created and that suck. Primary reason I stick with github is this feature (being able to create new repo in 10 seconds) [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 09:20, 22 April 2014 (UTC)
* I'm neutral to the debate of using Phabricator over Bugzilla and Gerrit. However for the management of Features (user stories) and their workflows using Agile Scrum methodology, I prefer Trello. It is possible to adapt a Phabricator Workboard to suit product management, however I recommend creating a separate project for product Features so your Workboard does not get overrun with the sight of new bugs and subtasks. One more reason I prefer Trello over Phabricator is this issue: http://fab.wmflabs.org/T195 {{unsigned|KLeduc (WMF)|15:52, 22 April 2014‎ (UTC)}}
**Being Trello a proprietary service, and requiring users to register in a 3rd party server to participate, there is no way Trello (and Mingle) will fit in the Wikimedia context in the long term. They are ok-ish short term solutions because our teams didn't find better tools. T195 can be fixed customizing the CSS; community division and WMF teams planning elsewhere are much bigger problems.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 18:43, 22 April 2014 (UTC)
* As an occasional tech, I am happy with Bugzilla, I don’t use Trello/Mingle/RT, and I "invested" time to learn Gerrit (and Git) more than one year after Gerrit was installed in production because I had no time before, so a bit sad if these leave. On the other side, I understand WMF developers want a more integrated tool for easier project management. Anyway, if Phabricator (or another tool) is used, please use it at least 5 years to let time to community members to learn it and become accustomed to. ~ [[User:Seb35|Seb35]] [[User talk:Seb35|[^_^]]] 23:17, 22 April 2014 (UTC)
* As someone that has dealt numerous times with Mingle SoS cards linked to a Bugzilla forwarded to an RT ticket, I'm excited about the prospect of a unified bugtracker, even in the case where I'd have to sacrifice useful functionality that each of these tools provides to me. I'd be hugely in favor of this, but: I'm a lot more worried about Phabricator's code review system and git integration, especially in regards with traditional git workflows (Gerrit is pretty bad in this aspect, but the arc workflow seems even worse, see e.g. the commits messages in Phabricator's own repository). It seems to me that the evaluation so far has been mostly on the issue tracker functionality; it might make sense as a first step, but now we're being asked for our opinion on a proposal to replace our code review system as well, and I don't feel sufficiently informed about that. [[User:Faidon Liambotis (WMF)|Faidon Liambotis (WMF)]] ([[User talk:Faidon Liambotis (WMF)|talk]]) 00:37, 25 April 2014 (UTC)
** {{u|Faidon Liambotis (WMF)}}, {{u|QChris}} is testing the area of code contributions and reviews, and he creating tasks under [http://fab.wmflabs.org/T47 Identify features Gerrit users would miss in Phabricator]. The attention of other users with experience in Git/Gerrit is welcome. Phabricator brings indeed a different paradigm that seems to be working for some organizations, but would it work for us? If not, is it a matter of features missing or is there something deeper? I agree that this needs further investigation and discussion.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:35, 27 April 2014 (UTC)
* Jeroen De Dauw could be my spokeperson. — [[User:Danny B.|Danny B.]] 15:40, 27 April 2014 (UTC)

== Pros / Cons ==
''For a specific comparison with Bugzilla, see [[Requests for comment/Phabricator/versus Bugzilla]]''
=== Pros (improvements) ===
* '''Everything would be in one place'''
** Single login for everything (''Can we integrate Phabricator and SUL?'' That would be cool. See [http://fab.wmflabs.org/T40 Pick an authentication provider].)
** Better integration of subsystems like bug tracker, git etc
** Single interface with no need to switch between differently looking, possibly confusing other interfaces of other instruments (like buzilla, gerrit etc).
** Integrates design and designers. Phabricator organizes design mockups and feedback in the same tool as code; you can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people [http://fab.wmflabs.org/M1/1 can comment on it].
** Responsivity and communication will be improved (currently a lot of issues brought up in one tool are missed in the other. i.e. a bug in Bugzilla is not addressed because the PM is working on a management tool, even after addressed the bug is not closed after the patch is reviewed and committed in Gerrit, there is no evidence that work is being done in Bugzilla even though there may be a lot of activity in Git or the management tool regarding that specific bug).
** Integrations between tools (e.g. Bugzilla to Mingle) is done ad-hoc and usually on a per-project basis because there is no return to scale to do this across others as they use different tools for certain key parts.
** Prioritization in bugzilla has no roadmap burn-down to why it is or isn't being worked on by those involved in a project (ScrumBugz into Bugzilla would solve it, but only if projects move to it).
* '''Faster reviewing of code''' (especially large diffs), and '''improved commit/review procedures'''
** Multi-commit single-branch review support instead of the approach in gerrit where each change is a single commit that is amended for each new patch set
* Support for '''code auditing''', with automatic notification based on rules and conditions
* '''Written in PHP''', so it's more '''easily extensible'''
** Already a deep knowledge on PHP due to it being the language of MediaWiki expertise
** Gerrit is in Java, Bugzilla is in Perl, most PM tools are closed-source and hosted on commercial sites with integration being their own unique APIs, neither has a large developer footprint in the community
** Deep integration between Phabricator (issue tracking, project/task management, and commits) and Wiki becomes a real possibility again (something we lost when we moved away from CodeReview).
* '''Mobile-friendly'''. Login from any mobile device and see what you can read and do. Now, open Bugzilla and Gerrit...
* Tasks can be assigned to more than one project. Projects can be easily as if they were keywords. No more discussions about products / components taxonomy, no more fights to decide where a bug should be filed. See [http://fab.wmflabs.org/T68 How to organize projects].
* '''Respects privacy more'''. Bugzilla and Gerrit expose your email address. Phabricator does not.
* '''Better developer tools''', specifically [https://secure.phabricator.com/book/phabricator/article/arcanist/ Arc], the command line interface to Phabricator. This means we would no longer we dependent on git-review or [http://www.gossamer-threads.com/lists/wiki/wikitech/419135 hacking together] our own tools.
* Possibility to let users create their own repositories. See [http://fab.wmflabs.org/T196 Enabling creation of repositories by regular users?]

=== Cons (potential issues) ===
* There will be a '''learning curve''' in switching to new software
* See [http://fab.wmflabs.org/T46 features Bugzilla users would miss in Phabricator]
* See [http://fab.wmflabs.org/T45 features Trello users would miss in Phabricator]
* [[:w:SPOF|'''SPOF''']] - if Phabricator breaks, everything breaks. Bug trackers should be highly available. How would you report a ticket that there is a problem with Phabricator when it is a bug tracker on its own? There will be maintenance of Phabricator and they will shut down everything. So impact of every maintenance / outage will be significantly higher than now.
* Have all the issues with [[Git/Gerrit evaluation|our previous evaluation with Git/Gerrit]] been addressed?
* No dedicated mobile application, only accessible via web. Therefore no push notifications, etc. Mobile support is better than Gerrit and Bugzilla, but not Trello (which has its own app).

Requests for comment/Phabricator

2014-04-27T21:49:55Z

RandomDSdevel: /* In favor of Phabricator */ Replied to thread

<big>'''''Participate in the [[Talk:Requests for comment/Phabricator#Format and schedule of the RfC|first round of feedback]] by April 27'''''</big>
{{RFC
| component = 
| created = 2014-03-28 
| authors = [[User:AKlapper (WMF)|Andre Klapper]], [[User:guillom|Guillaume Paumier]]
| draft = final draft
| implementation = not started
}}
== Problem ==

The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and, all in all, the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome for both current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state of affairs and wish to consolidate the development toolchain.

See the [http://lists.wikimedia.org/pipermail/teampractices/2013-December/000205.html full email thread] for more background.

== Background ==
{{Project management tools review}}
This is what has been done so far:
* People have [[mw:Talk:Project management tools/Review|shared their needs]] and workflows.
* Andre and Guillaume have [[mw:Project management tools/Review/Requirements|summarized all of that]] into consolidated requirements.
* Andre and Guillaume have set up a [[mw:Project management tools/Review/Options|list of options]] to solve our problem, based on what was mentioned during preliminary discussions.
* People have [[mw:Talk:Project_management_tools/Review/Options|discussed the options]] and eliminated some of them in preparation for the RfC.
* Besides the wiki, communication has happened mainly on the [http://lists.wikimedia.org/pipermail/teampractices/ teampractices] list, with updates also sent to [http://lists.wikimedia.org/pipermail/wikitech-l/ wikitech-l].
* We're now drafting this RfC and welcoming edits on both the form and the content.
The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other.

{{clear}}
<div style="border:1px solid #AAA; background:#f9f9f9; width:25%; margin:1em; padding:1em; float:right;">
{{:Requests for comment/Phabricator/FAQ}}
</div>

== Proposal: Move to Phabricator ==

This proposal consists of replacing several of our tools with one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. This means you'll only need one account for everything, and all tasks / bugs / commits / screenshots will be cross-referenced automatically. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.

You can [http://fab.wmflabs.org/ test Phabricator] in Labs. This is an actual test instance, so don't be afraid to break things.

If this proposal fails to gather agreement, we will keep the status quo. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year. We may want to consider consolidating our project management tools later into [https://scrumbu.gs/ Scrumbugz] (a tool that works on top of Bugzilla) but that will be a separate discussion.

You're welcome to contribute to the [[Requests for comment/Phabricator/FAQ|developing FAQ]] and browse the [http://fab.wmflabs.org/project/board/14/ Wikimedia Phabricator] project in our test instance, which we're using to identify missing features and plan the possible migration.

=== In favor of Phabricator ===

* But migration of existing content (including closed bugs, etc.) is critical. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk:Jdforrester (WMF)|talk]]) 00:24, 15 April 2014 (UTC)
* --[[User:JEissfeldt (WMF)|JEissfeldt (WMF)]] ([[User talk:JEissfeldt (WMF)|talk]]) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James
* +1 to what James said. BZ data must be migrated. ^[[User:^demon|demon]][[User_talk:^demon|[omg plz]]] 16:40, 15 April 2014 (UTC)
* Support as long as teams can still user third party tools like Trello as necessary [[User:Tfinc|Tfinc]] ([[User talk:Tfinc|talk]]) 00:20, 17 April 2014 (UTC)
* The idea of having developers, designers, product managers, and just any volunteer using one tool with their Wikimedia credentials is worth fighting for. The migration will be complex, [http://fab.wmflabs.org/T37 but we are planning for it]. Phabricator is coded in PHP, a language that MediaWiki developers are familiar with, and the upstream project takes feedback and patches.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:50, 17 April 2014 (UTC)
* I imagine there will be a lot of "ZOMG my favorite feature of X isn't here" but I think having issues and code review and planning all in one pile would be worth the pain of learning a new set of tools. [[User:BDavis (WMF)|BDavis (WMF)]] ([[User talk:BDavis (WMF)|talk]]) 17:12, 17 April 2014 (UTC)
* I think it will be worth the effort. [[User:Grunny|'''Grunny''']] ([[User talk:Grunny|talk]]) 18:03, 17 April 2014 (UTC)
* While I feel the current tools meet the needs (AFAIK), Phabricator's oneness seems to be much better with one account for every service as opposed to every account for every service. What James said it pretty much critical with this. [[User:John F. Lewis|John F. Lewis]] ([[User talk:John F. Lewis|talk]]) 17:33, 18 April 2014 (UTC)
* I like the fast diff-view in Phabricator (diffs of huge files are almost impossible to view in gerrit for me and I do not want to view them in a custom diff viewer every time; with Opera, I struggle in gerrit anyway), the fact that it is all-in-one and most important to me that it is possible to create profiles so I can hopefully see to whom I am talking. I think it's worth migrating, although the terminology is fundamentally different. -- [[User:Rillke|Rillke]] ([[User talk:Rillke|talk]]) 11:25, 20 April 2014 (UTC)
* per others. --[[User:Zhuyifei1999|Zhuyifei1999]] ([[User talk:Zhuyifei1999|talk]]) 12:16, 20 April 2014 (UTC)
* For volunteers like me, who spend only a few hours during their spare time on Mediawiki development, it takes a lot of time to get along with all the tools. Furthermore it's sometimes strange that some information like RT or ORTS is hidden. (How do I sign with VE?)--[[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 12:45, 20 April 2014 (UTC)
* Strongly in favor. Phabricator is a pleasure to use. It strikes me as having been designed and architected with awareness of the pain-points of collaborative software development. The interface has a way of nudging you towards positive, constructive interactions. Its command-line tool, arc, is superb. The documentation is excellent. Upstream is very responsive. Features like [https://secure.phabricator.com/book/phabricator/article/herald/ Herald] are innovative and useful. Let's do it. --[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 19:51, 20 April 2014 (UTC)
* In favour. This would be a nice change, and has much better functionality than the antiquated bugzilla. [[User:Ajraddatz|Ajraddatz]] ([[User Talk:Ajraddatz|Talk]]) 21:56, 20 April 2014 (UTC)
* Strongly in favour of this. Both Bugzilla and Gerrit aren't the best platform in my opinion, and Phabricator looks much better. I especially like Phabricator being based on PHP, since Bugzilla's Perl code was something I never liked. --[[User:GeorgeBarnick|GeorgeBarnick]] ([[User talk:GeorgeBarnick|talk]]) 21:59, 20 April 2014 (UTC)
* I want ''one place'', not three or four, to go document and discuss patches and the issues related to them. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:17, 21 April 2014 (UTC)
* I will favor anything that lets me edit code online, instead of having to install specialized software, keeping a local copy of the code and hand-crafting patches. (I asume some form of local-repository development will remain possible.) — [[User:Edokter|Edokter]] ([[User talk:Edokter|talk]]) — 11:26, 21 April 2014 (UTC)
* I honestly do not care all that much for Phabricator's current UI, but I expect that it can be tweaked as we gain expertise with it (or that it can be ''made'' to be tweakable). The point for me is that the status quo is not tenable: having to use at least six disjoint tools that barely interface with each other just to do day-to-day work is a guaranteed recipe to have things fall between the cracks. It also means that even if we ''do'' end up having to hammer our workflow into the code, there is just the one tool to fiddle with. — [[User:MPelletier (WMF)|MPelletier (WMF)]] ([[User talk:MPelletier (WMF)|talk]]) 12:52, 21 April 2014 (UTC)
* '''Strong support''' per Ori and Steven. [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 17:01, 21 April 2014 (UTC)
* Folks commenting in the "No" column should recognize that tools like Trello and Mingle haven't made it into the WMF workflow for whimsical reasons; Bugzilla simply lacks an adequate project management workflow. In the absence of better PM tools, we'll have a fragmentation of information flows which leads to its own inefficiencies. Tools like Scrumbugz seek to address this, but it's in the context of an aging, rigid codebase. Phabricator is built to support modern development practices and looks very promising from everything I've seen so far (proliferation of silly proper noun names for different functions notwithstanding). I think an incremental migration with checkpoints on real-world issues is the way to go.--[[User:Eloquence|Eloquence]] ([[User talk:Eloquence|talk]]) 17:10, 21 April 2014 (UTC)
* Well I'm hugely biases since I was advocating Phabricator when it was a decision between that and Gerrit. (Having said that, the reasons others gave for not switching were very viable at the time only to be mitigated by Phabricator's continued upward trajectory.) I caution people during the migration for an expectation of a feature-for-feature parity improvement is not in the cards, but on balance the rewards outweigh the loses, and this has been the case for many PHP-based software endeavors both closed and open-source as evidenced at how low the churn has been away from using Phabricator. [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:31, 21 April 2014 (UTC)
*: (Wanted to put this below, but I couldn't figure a good place in the other options to put it). I have concerns about the logistics of this migration. I think it might be easiest to transfer via Gerrit, then PM tools (Trello, Mingle, etc), then Bugzilla. The first requires just alignment on developers and actually removes some unnecessary overhead. The second should be staggered on a project-by-project basis over a longer duration as the positives outweigh the negatives (as the teams would have to migrate their existing entries or had specific reasons/features that caused them to use a certain tool). The third probably last as it involves the largest institutional inertia and affected people, however the full benefit won't be seen until Bugzilla is integrated. Not sure if it can be staggered or what the transition looks like, but I do thing while it should be handled right, some compromise on the loss of a couple of data fields should be acceptable (a lot of metadata in Bugzilla is useless/archaeic). [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:32, 21 April 2014 (UTC)
* Strong support for everything in one place. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 21:38, 21 April 2014 (UTC)
* Support for the unification of development in a single place, as someone who has primarily used these tools for looking at what's in development and for reporting bugs. Right now it's a huge pain to navigate Bugzilla and submit things, and the disconnect between Bugzilla and Gerrit is fairly annoying. --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 21:43, 21 April 2014 (UTC)
**Cannot. Agree. More. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 23:30, 21 April 2014 (UTC)
* Support - Phabricator has come a long way in the past couple of years. What looks awfully promising about it is that they seem to have a coherent vision for providing tools that make development teams productive, and a focus on important things that most tools in this space neglect (user interface, performance, and a sense of humor). From all outward indications, the upstream will be a joy to work with, and the tool is in a programming langauge (PHP) that we have a lot of familiarity with. The migration promises to be a miserable experience (all migrations of this scale are...no matter how great the tool), but this is the first toolset I've seen that looks likely to be worth the pain. -- [[User:RobLa-WMF|RobLa-WMF]] ([[User talk:RobLa-WMF|talk]]) 00:25, 22 April 2014 (UTC)
** Speaking of the 'sense of humor,' maybe we could somehow import those funny quotes that users can optionally make Bugzilla put at the top of every page of that tool's search results while we're importing it whether we do this importing manually or automatically? — [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:45, 27 April 2014 (UTC)
*This would be awesome. The current mess of tools (especially bugzilla vs trello vs mingle) is quite frustrating for finding whether something is already noted, and has made me not want to enter bugs for myself (especially in Bugzilla with its irritating login requirements). SUL integration would be great if possible. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 01:27, 22 April 2014 (UTC)
* Strong support: per others, it's always a good idea to have one place for all tasks. [[User:Chmarkine|Chmarkine]] ([[User talk:Chmarkine|talk]]) 03:44, 22 April 2014 (UTC)
* Support - I haven't used dev tools yet, it would be easier to have 1 place to go and start [[User:Aprillion|Aprillion]] ([[User talk:Aprillion|talk]]) 12:17, 22 April 2014 (UTC)
* '''Support''': Me neither, really; I've filed bugs in Bugzilla, but it's a 'bit' of a ''pain'' to use since it's interface is so archaic. Phabricator sounds like a great tool to move all of our development stuff to, and I might just start helping out some once all of the dust settles (or maybe even ''before'' then; it all depends on whether I'm available or not due to the facts that I plan to start learning [[en:wp:C++|C++]] pretty soon and that this might take up a lot of my time.) — [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:49, 27 April 2014 (UTC)
* Support - having all tools in one place can only be a good thing. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:29, 22 April 2014 (UTC)
* Support - Based on what I know so far, I support moving to Phabricator. The top practical problem I face with the current solution is going back and forth between Trello and Bugzilla, but see below for secondary issues. However, we do need to ''ensure'' we're not just adding another tool without replacing/removing anything. This means at least turning off/redirecting/marking read-only Bugzilla and Gerrit. The most realistic way to accomplish that is to do a complete migration of ''at least'' Bugzilla, ideally other issue tracking tools like Trello, Mingle, etc., and possibly others like Gerrit. I've already seen some cool features in Phabricator (e.g. updateable mocks, drag-and-drop file uploading, simple embedding and linking and CCing (oddly, Trello does not allow you to CC other users). It also should allow much tighter integration between Gerrit and Bugzilla (no more getting two Bugzilla emails after you upload a patch to Gerrit, and perhaps auto-fixing bugs based on a commit message tag). Being written in PHP is definitely helpful. It will not magically mean every MediaWiki PHP dev works on Phabricator, but it will hopefully encourage creating a critical mass of collaboration with upstream. I also strongly support using open source infrastructure, so this is a step in the right direction on that front. There will definitely be switching costs and issues, but so far it looks like it will be worth it. [[User:Superm401|Superm401]] - [[User_talk:Superm401|Talk]] 21:38, 22 April 2014 (UTC)
* '''Strong Support''' - There are issues with Phabricator, like any single tool that would be an option (there is no unicorn that covers all use-cases efficiently), but I think it's biggest strength is Evan P and the Phabricator community. His responses to our suggestions/requests have been amazing. And it isn't just us. Other organizations that have migrated to Phabricator have had similar experiences; someone reports an issue that Phab has with their internal work flow, a week later Even P comes back with a fix, before the org (devianArt in this case) could even start working on it. Evan P and the rest of the Phab community is awesome and are an upstream that I want to work with more than pretty much any other. And in the long term, the relationship you have with your upstream is tantamount to pretty much anything else. [[User:Greg (WMF)|Greg (WMF)]] ([[User talk:Greg (WMF)|talk]]) 16:04, 23 April 2014 (UTC)
* Support, even though I have not used other tools (yet) than Bugzilla, but it's always better to have everything at the same place (if possible). --[[User:Stryn|Stryn]] ([[User talk:Stryn|talk]]) 17:58, 23 April 2014 (UTC)
* I have been playing with it for a while and I say '''Let's go get this thing deployed on our servers''' [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 07:36, 24 April 2014 (UTC)
* Support - Yes please -[[User:Fastily|<big>F</big>ASTILY]] [[User talk:Fastily|(TALK)]] 00:13, 25 April 2014 (UTC)
* '''Support''' the pain is real! Copying issues between bugzilla and {team's Project Management tool}, the disjointed concurrent discussion in bugzilla|gerrit|{team's Project Management tool}, the mindless busywork of keeping the state of an issue up-to-date in all three tools, the redundant notifications that this busywork generates, ... A ''fourth'' area that Phabricator integrates is design mockups, an area where the MediaWiki community has never had a good tool. You can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people can comment on it, see http://fab.wmflabs.org/M1/1/ . -- [[User:S Page (WMF)|S Page (WMF)]] ([[User talk:S Page (WMF)|talk]]) 19:36, 25 April 2014 (UTC)
* Support - As someone considering getting into extension development/generally helping out in the next few months, learning to use one tool is much less intimidating than trying to figure out a workflow across five different sites. Phabricator, from my exploration of it, looks nice and intuitve for all the basics.-[[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 19:41, 25 April 2014 (UTC)
* Yes. However, It should be possible to use Wikimedia/Wikitech account to log in to Phabricator, rather than having an independence system (currently you need to create a new account to Bugzilla). (In the future, I hope Wikitech can be added to [https://noc.wikimedia.org/conf/highlight.php?file=all.dblist all.dblist], so that users can use SUL account to log in WMFlabs, rather then create a new account: current account in Wikitech would be merged to SUL ones.)--[[User:GZWDer|GZWDer]] ([[User talk:GZWDer|talk]]) 12:21, 26 April 2014 (UTC)
* Support - Moving to one integrated toolset seems like a dream come true. --[[User:Lydia Pintscher (WMDE)|Lydia Pintscher (WMDE)]] ([[User talk:Lydia Pintscher (WMDE)|talk]]) 17:41, 27 April 2014 (UTC)
* I believe that a single integrated system is absolutely a good idea. The sheer number of tools being used simultaneously at present is bewildering (RT is involved somewhere as well?!). However the comments on display here lead me to feel that Phabricator appears to require a little more work before it's quite ready. I have two other concerns: firstly, there needs to be an assurance that after the change Bugzilla will be maintained in read-only mode forever; it has a decade's worth of incoming links that shouldn't be broken. Secondly, when Bugzilla bugs are imported, will their entire comment history be imported as well? I think that it should. The discussions associated with bugs are by far the most important aspect of the whole thing. If dealing with a bug in the new system requires having to scoot back to Bugzilla to pick up on all the context and/or previous decisions, that messes up the point of only having a single bugtracker. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 13:14, 27 April 2014 (UTC)
** Yes {{u|Scott}}, [http://fab.wmflabs.org/T55 RT is part of the plan]. [http://fab.wmflabs.org/T65 Redirects of Bugzilla URls to Phabricator] are also planned and, yes, we are talking about importing all reports including the comments. There should be no need to keep the Bugzilla instance available forever, but we can allow ourselves as much time as needed. You can check and discuss the details at [http://fab.wmflabs.org/T39 http://fab.wmflabs.org/T39]. "Phabricator appears to require a little more work before it's quite ready", maybe, you can help defining exactly what needs to be done before the migration, see [http://fab.wmflabs.org/T43 Define what features existing in our current tools are really missing in Phabricator] and dependent tasks.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:29, 27 April 2014 (UTC)
*** I only have experience using WMF's Bugzilla but I'll certainly contribute anything I notice about Phabricator - obviously I've not had much time to investigate it. Thanks for the links. That's good news about the import, too - in which case I guess then just so long as URL redirects are set up for old Bugzilla URLs there'll be no need to keep the old system around. So given all that, I've moved this to the support area. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:34, 27 April 2014 (UTC)
**** After just a few minutes of playing with Phabricator - ''boy howdy!'' Bugzilla feels like the stone age compared to this thing. I have no doubt that any features people consider missing can be added upstream. Consider me sold. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 21:27, 27 April 2014 (UTC)
* Support per above - it's better to have everything centralized in just one place. [[User:LlamaAl|LlamaAl]] ([[User talk:LlamaAl|talk]]) 19:08, 27 April 2014 (UTC)

=== In favor of keeping our current tools ===

* I would like to see a rough roadmap of the migration and what task force is going to be allocated to it. I looked a bit around and could not find how we are going to handle the transition. I dont mind changing tools, but I wish we handle it as a proper project or we risk spending a couple years doing the migration on a best effort basis. So until we have a migration plan, I will remain suspicious. [[User:Hashar|Antoine "hashar" Musso]] ([[User talk:Hashar|talk]]) 21:08, 17 April 2014 (UTC)
*: [http://fab.wmflabs.org/project/view/14/ Everything is being tracked] in our test instance itself: [http://fab.wmflabs.org/T37 how to migrate everything], [http://fab.wmflabs.org/T43 what features are currently missing], [http://fab.wmflabs.org/T59 how to configure it] for our needs, even the [http://fab.wmflabs.org/T41 resource planning]. Is this what you were looking for? It's still incomplete, but resources for a migration task force won't be allocated unless this RFC shows explicit support from the technical community. [[user:guillom|guillom]] 14:01, 18 April 2014 (UTC)
* Meh, I hate changing systems which (apparently) work. Though, I don't feel strongly on this issue. [[User:Vogone|Vogone]] [[User talk:Vogone|'''talk''']] 17:37, 18 April 2014 (UTC)
* "The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists" so you want to add one more? But if you show me the way how to force all people to move to the new system I may support. (And no it's not disabling old tools which would just mean loosing usefull stuff of users who would not give up (or wont know how to move) even under such conditions as it's with TS -> Labs move in some way happened) --[[User:Base|Base]] ([[User talk:Base|talk]]) 14:04, 19 April 2014 (UTC)
*: It's not "adding one more" as we are after ''replacing'' systems. Old systems become read-only or disabled, if that's how you interpret "forcing". --[[User:AKlapper (WMF)|AKlapper (WMF)]] ([[User talk:AKlapper (WMF)|talk]]) 07:07, 20 April 2014 (UTC)
*: There is some precedent for "replacing" over "adding" that might mitigate some of the pessism: In 2012, Subversion was replaced with Git/Gerrit. On a per-project level, many teams have migrated between multiple project management tools—bulletin board, Wiki, Bugzilla, Trello. Mingle, and Google Doc—never using more than one concurrently for more than 2 weeks during a transition. Also, the major pain point in PM tools cited is poor integration of those tools with Git and Bugzilla (or general crumminess of management capabilities in the case of Bugzilla), this is especially bad for those who have to navigate multiple tools in the course of their work (notably tech leads, scrum master, and product managers). The multiplicity/redundancy is also the source of much friction because of the lack of responsiveness due people not being on a tool (for instance the devs working from Gerrit, while the bug was in Bugzilla) [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:40, 21 April 2014 (UTC)
*It's probably worth integrating MediaWiki with Bugzilla more. Bugzilla has an API. If WMF could also work on making Bugzilla more mobile-friendly and "user-friendly", I'm sure everyone would appreciate it. [[User:Gryllida|Gryllida]] 07:22, 20 April 2014 (UTC)
** We don't use MediaWiki for a project management and issue-tracker, because that's not what it is for. For years, we did code review on-wiki (see [[Special:Code/MediaWiki/status/resolved|examples]]) and it was a nightmare to work with. A wiki is a great tool for documenting things. It's not a code review tool or issue tracker. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:23, 21 April 2014 (UTC)
* 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. [[User:Hym411|—]] [[User talk:Hym411|Revicomplaint?]] 07:28, 20 April 2014 (UTC)
*I don't think any change is required at the moment. Bugzilla, Gerrit, etc. are quite adequate for our current needs. I have never had any problems or concerns with them. The integration between the tools may be a bit hackish at times, but to me, the fact that the current systems are in widespread use and perhaps already familiar to newly-arriving developers is more important. What's more, I don't like Phabricator. It's a rather intimidating web app which looks like it could have a steep learning curve, and could undo some of the good work of people like Quim in attracting new developers to the WMF's projects. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 09:58, 20 April 2014 (UTC)
**For what is worth, one of the reasons why I support Phabricator is to offer to new contributors a single tool with Wikimedia SUL that fits in the expectations of regular GitHub users. Currently it is painful to send newcomers to Bugzilla and Gerrit in addition to mediawiki.org, while having teams more and more invested in Trello/Mingle (because Bugzilla won't handle the PM work) is a pain for everybody, newcomers included.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:50, 21 April 2014 (UTC)
**Personally, I find having to create accounts for multiple different services with different workflows and having to try to figure out how to use every single one separately is far more difficult than if we were to introduce them to a single service which contains all the development work and bug reports in a single location. That, plus the interface is far better looking ''and'' easier to use than Bugzilla (keep in mind that you're used to Bugzilla, so if you can navigate it easily that's probably why). --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 01:50, 22 April 2014 (UTC)
*I'm only commenting on Bugzilla (and slightly RT) here, As i've had limited to no use with the other tools, I don't think think moving will solve any of the "real" issues we currently have, The issue with multiple tools is more due to staffing and cultural issues allowing it to be come so spread out, Whilst some of these tools do have their uses, Some should also be dropped or restricted to very specific use cases, For example RT was introduced because of the security & permissions point of view when needing to deal with outside individuals and a few other small cases it has since basically evolved into a private ops bugtracker with a lot of information that could probably already be in BZ. Also another issue is the maturity and team backing Phab, For example when gerrit was chosen compared to custom writing something like we did with SVN (E:CodeReview) it was decided against because we would land with the same issues about having to maintain the code. [[User:Peachey88|Peachey88]] ([[User talk:Peachey88|talk]]) 08:52, 21 April 2014 (UTC)
** {{u|Peachey88}}, can you explain your last comment? Phabricator is a young project, but they have a significant community and user base that keep gaining momentum, see [https://www.ohloh.net/p/compare?project_0=Bugzilla&project_1=Gerrit+Code+Review&project_2=Phabricator an Ohloh comparison with Bugzilla and Gerrit], and [[w:Phabricator#Users]].--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:40, 22 April 2014 (UTC)
*I think the overhead of migrating and learning the new interface is not worth the effort. Bugzilla works fine for most of what we do. The interface also looks a bit scary to me, although Bugzilla's interface is not completely obvious either. Bugzilla is also used for more free software projects and thus has been proven to work in practice. Basically echoing Revi and TTO's concerns as well. As Multichill mentioned, we don't want to add [https://xkcd.com/927/ another competing standard] for teams to choose from (Trello, Mingle, ...) [[User:PiRSquared17|πr2]] ([[User talk:PiRSquared17|''t'']] • [[Special:Contributions/PiRSquared17|''c'']]) 21:43, 22 April 2014 (UTC)
** This isn't just about replacing Bugzilla. Phabricator lets us consolidate a host of disparate tools (Bugzilla, Gerrit, git.wikimedia.org, others) in to one view of work on MediaWiki. What's more: Bugzilla is clearly not working for Wikimedia Foundation developers, who are doing a large bulk of the work that is tracked in Bugzilla. This is obviously the case when you consider that nearly all teams are using a secondary project management tool on top of Bugzilla, and may even disregard Bugzilla as the canonical list of bugs/issues with a component, because it's such a mess. This doesn't even begin to touch how unfriendly Bugzilla is to non-developers who we want to report issues... [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 21:09, 23 April 2014 (UTC)
* As long as we do not force people to switch to only Phabricator (and forcing would be bad), we'll not reach the desired consolidation of tools, but just add another tool to the set of tools the different teams use. For me, bugzilla and gerrit both have their issues, but they get the job done sufficiently well. Of the many open bugs in our Phabricator, Phabricator's requirement to use "arc" instead of plain git to fetch/push commits bothers me the most. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 22:52, 23 April 2014 (UTC)
** {{u|QChris}}, reply from maintainer epriestley at #phabricator: ''"everything works fine without arc | you get more features and stuff with it, people mostly seem pretty happy about them | but it's absolutely not required | If some of the documentation was misleading in that respect, let me know and I'll fix it."''--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 21:41, 24 April 2014 (UTC)
*** {{u|Qgil}}, I followed up with epriestly. Without arc, you're expected to 'git diff' and copy/paste that in the web UI. That's not a "works fine" for me :-) First, it's really, really inconvenient. And then you'll loose commit metadata that way. Like committer, author, and most important: parent of a commit. But Phabricator does not value this kind of metadata much anyways. For example "arc patch/land" does not honor them either (see upstream ticket [https://secure.phabricator.com/T4333 T4333]). Also, merging a patch is not possible nicely without arc. You have to merge in your repo locally, and then push directly to the branch to bypass review. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 00:04, 25 April 2014 (UTC)

=== Basically neutral ===
* Personally, with the current test installation (microscopic fonts, functions [http://fab.wmflabs.org/T119 hidden behind unlabeled icons], other icons not clickable, tendency to feature bloat, some features like [http://fab.wmflabs.org/T150 voting missing], other features like Gerrit and GitHub integration not testable at the moment) I can't decide if it's worth my time. It could be the greatest thing on earth or turn into a bottomless pit. A project that starts with ''"We can't manage 12 tools! We need to do something!"'' could also end with ''"Now we have 13 tools."'' --[[User:Thiemo Mättig (WMDE)|Thiemo Mättig (WMDE)]] 14:14, 17 April 2014 (UTC)
* I am in favor of trying out Phabricator for a few select projects so we get a better idea of what moving over all projects would mean --[[User:Jeroen De Dauw|Jeroen De Dauw]] ([[User talk:Jeroen De Dauw|talk]]) 19:09, 17 April 2014 (UTC)
* I gave it a try, very stressful so far (I hope not to touch it for a few weeks now, I'll need some discipline). Will need huge amounts of help to figure out, if we really want to kill bugzilla: I expect at least a couple hundreds more bugs need to be filed and triaged, please help with testing. My results so far are visible at [http://fab.wmflabs.org/p/Nemo_bis/] (only partly and only after login, try the [http://fab.wmflabs.org/search/query/advanced/ search]). --[[User:Nemo_bis|Nemo]] 19:10, 19 April 2014 (UTC)
* I'm not convinced that the time invested in changing our code review tool (again) is worth the expected benefits. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 07:40, 20 April 2014 (UTC)
* IM kinda HO we gotta change default avatar on our demo, it's unacceptable for me to use [[w:Psyduck|an NFC image]] as it... --[[User:Liuxinyu970226|Liuxinyu970226]] ([[User talk:Liuxinyu970226|talk]]) 10:15, 20 April 2014 (UTC)
* I share Legoktm's and Thiemo's concerns, but I also see the problem with our current (overwhelmingly) large tool stack. The most important thing over here is to really make the cut on the n tools we have atm and to not have n+1 tools after. - [[User:Hoo man|Hoo man]] ([[User talk:Hoo man|talk]]) 11:45, 20 April 2014 (UTC)
* I'm basically neutral but I couldn't agree more with Antoine: If we're going to change, it should be done with a proper project. When I talk about a project, I'm talking about a project as defined [[:en:PRINCE2|here]]. Clear goal, clear time path, clear budget etc. I'm a bit afraid [https://xkcd.com/927/ this] is going to happen. [[User:Multichill|Multichill]] ([[User talk:Multichill|talk]]) 15:23, 20 April 2014 (UTC)
* I dont mind, I am not a developer. If you think you need it. Do it. But do it once. It take us some time, to get in touch with bugzilla. So we will need some time to get in touch with the new sw. ('''errr, where I have a singnature button in Visual Editor?) '''[[user:Juandev|Juandev]]
* A new system could be nice, I don't really care either way. But we want to make sure users will not be suddenly surprised by this.--[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:18, 21 April 2014 (UTC)
* I largely agree with Multichill, et al. Some specific team (whether that's a Wikimedia Foundation team or a Wikimedia chapter team or a coalition of volunteers) has to take charge of this and properly migrate the current suite of tools to Phabricator. This will be tedious and long and annoying.As long as whatever new tool is implemented has IRC feeds, I'm pretty neutral on the topic. I will say that in my limited interaction with Phabricator, it seems to go out of its way to be gimmicky and obnoxious. I'm wondering if that's a configurable mode. It might be nice to enable rotating cutesy submit buttons and "stickers" in a year or two, but for now, the transition will be difficult enough without Phabricator constantly dressed in a clown costume. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 00:31, 21 April 2014 (UTC)
**The silly names have been turned off already - it's now in "serious business" mode (instead of "fun mode"). Discussion at http://fab.wmflabs.org/T119 –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 22:22, 21 April 2014 (UTC)
*On the one hand, Phabricator is one unified system which will therefore likely reduce the work we need to keep so many separate systems going. On the other hand, it's unclear to me what cost the migration will have, and how much time it will take learning a new system. Without having more data to figure out whether the pluses overcome the minuses, I am basically neutral. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 15:44, 21 April 2014 (UTC)
* I now support this proposal, here is my former opinion: This discussion would be far more simple if we point out the biggest improvements and potential bigest issues that migration would do, so please fill up this list with that is in your mind. I am not really againsted Phabricator, but I really do like bugzilla, as that is one of best open source bug trackers and saying just "let's have 1 tool for everything" is not much of argument to me :) For this reason I created new section with pros cons. [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:48, 21 April 2014 (UTC)
*:Which tools are we actually talking about is it just bugzilla and gerrit that would be unified or is there more of them? [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:51, 21 April 2014 (UTC)
*::The other dimension is project management tools. This includes Mingle and Trello which are actively in use in the WMF, which would also be replaced by Phabricator. People at the WMF have written scripts to actively copy Bugzilla bugs into Mingle and Trello, but these scripts occasionally need maintenance. So, Bugzilla and Gerrit are the big ones most people know about, but there are others. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 17:19, 21 April 2014 (UTC)
*:Most impressive part I found is that it allows regular users to create own repositories. This however needs to be enabled. Would this be enabled on production version of phabricator? I am not using our gerrit only because I have to wait weeks or months for repositories to be created and that suck. Primary reason I stick with github is this feature (being able to create new repo in 10 seconds) [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 09:20, 22 April 2014 (UTC)
* I'm neutral to the debate of using Phabricator over Bugzilla and Gerrit. However for the management of Features (user stories) and their workflows using Agile Scrum methodology, I prefer Trello. It is possible to adapt a Phabricator Workboard to suit product management, however I recommend creating a separate project for product Features so your Workboard does not get overrun with the sight of new bugs and subtasks. One more reason I prefer Trello over Phabricator is this issue: http://fab.wmflabs.org/T195 {{unsigned|KLeduc (WMF)|15:52, 22 April 2014‎ (UTC)}}
**Being Trello a proprietary service, and requiring users to register in a 3rd party server to participate, there is no way Trello (and Mingle) will fit in the Wikimedia context in the long term. They are ok-ish short term solutions because our teams didn't find better tools. T195 can be fixed customizing the CSS; community division and WMF teams planning elsewhere are much bigger problems.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 18:43, 22 April 2014 (UTC)
* As an occasional tech, I am happy with Bugzilla, I don’t use Trello/Mingle/RT, and I "invested" time to learn Gerrit (and Git) more than one year after Gerrit was installed in production because I had no time before, so a bit sad if these leave. On the other side, I understand WMF developers want a more integrated tool for easier project management. Anyway, if Phabricator (or another tool) is used, please use it at least 5 years to let time to community members to learn it and become accustomed to. ~ [[User:Seb35|Seb35]] [[User talk:Seb35|[^_^]]] 23:17, 22 April 2014 (UTC)
* As someone that has dealt numerous times with Mingle SoS cards linked to a Bugzilla forwarded to an RT ticket, I'm excited about the prospect of a unified bugtracker, even in the case where I'd have to sacrifice useful functionality that each of these tools provides to me. I'd be hugely in favor of this, but: I'm a lot more worried about Phabricator's code review system and git integration, especially in regards with traditional git workflows (Gerrit is pretty bad in this aspect, but the arc workflow seems even worse, see e.g. the commits messages in Phabricator's own repository). It seems to me that the evaluation so far has been mostly on the issue tracker functionality; it might make sense as a first step, but now we're being asked for our opinion on a proposal to replace our code review system as well, and I don't feel sufficiently informed about that. [[User:Faidon Liambotis (WMF)|Faidon Liambotis (WMF)]] ([[User talk:Faidon Liambotis (WMF)|talk]]) 00:37, 25 April 2014 (UTC)
** {{u|Faidon Liambotis (WMF)}}, {{u|QChris}} is testing the area of code contributions and reviews, and he creating tasks under [http://fab.wmflabs.org/T47 Identify features Gerrit users would miss in Phabricator]. The attention of other users with experience in Git/Gerrit is welcome. Phabricator brings indeed a different paradigm that seems to be working for some organizations, but would it work for us? If not, is it a matter of features missing or is there something deeper? I agree that this needs further investigation and discussion.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:35, 27 April 2014 (UTC)
* Jeroen De Dauw could be my spokeperson. — [[User:Danny B.|Danny B.]] 15:40, 27 April 2014 (UTC)

== Pros / Cons ==
''For a specific comparison with Bugzilla, see [[Requests for comment/Phabricator/versus Bugzilla]]''
=== Pros (improvements) ===
* '''Everything would be in one place'''
** Single login for everything (''Can we integrate Phabricator and SUL?'' That would be cool. See [http://fab.wmflabs.org/T40 Pick an authentication provider].)
** Better integration of subsystems like bug tracker, git etc
** Single interface with no need to switch between differently looking, possibly confusing other interfaces of other instruments (like buzilla, gerrit etc).
** Integrates design and designers. Phabricator organizes design mockups and feedback in the same tool as code; you can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people [http://fab.wmflabs.org/M1/1 can comment on it].
** Responsivity and communication will be improved (currently a lot of issues brought up in one tool are missed in the other. i.e. a bug in Bugzilla is not addressed because the PM is working on a management tool, even after addressed the bug is not closed after the patch is reviewed and committed in Gerrit, there is no evidence that work is being done in Bugzilla even though there may be a lot of activity in Git or the management tool regarding that specific bug).
** Integrations between tools (e.g. Bugzilla to Mingle) is done ad-hoc and usually on a per-project basis because there is no return to scale to do this across others as they use different tools for certain key parts.
** Prioritization in bugzilla has no roadmap burn-down to why it is or isn't being worked on by those involved in a project (ScrumBugz into Bugzilla would solve it, but only if projects move to it).
* '''Faster reviewing of code''' (especially large diffs), and '''improved commit/review procedures'''
** Multi-commit single-branch review support instead of the approach in gerrit where each change is a single commit that is amended for each new patch set
* Support for '''code auditing''', with automatic notification based on rules and conditions
* '''Written in PHP''', so it's more '''easily extensible'''
** Already a deep knowledge on PHP due to it being the language of MediaWiki expertise
** Gerrit is in Java, Bugzilla is in Perl, most PM tools are closed-source and hosted on commercial sites with integration being their own unique APIs, neither has a large developer footprint in the community
** Deep integration between Phabricator (issue tracking, project/task management, and commits) and Wiki becomes a real possibility again (something we lost when we moved away from CodeReview).
* '''Mobile-friendly'''. Login from any mobile device and see what you can read and do. Now, open Bugzilla and Gerrit...
* Tasks can be assigned to more than one project. Projects can be easily as if they were keywords. No more discussions about products / components taxonomy, no more fights to decide where a bug should be filed. See [http://fab.wmflabs.org/T68 How to organize projects].
* '''Respects privacy more'''. Bugzilla and Gerrit expose your email address. Phabricator does not.
* '''Better developer tools''', specifically [https://secure.phabricator.com/book/phabricator/article/arcanist/ Arc], the command line interface to Phabricator. This means we would no longer we dependent on git-review or [http://www.gossamer-threads.com/lists/wiki/wikitech/419135 hacking together] our own tools.
* Possibility to let users create their own repositories. See [http://fab.wmflabs.org/T196 Enabling creation of repositories by regular users?]

=== Cons (potential issues) ===
* There will be a '''learning curve''' in switching to new software
* See [http://fab.wmflabs.org/T46 features Bugzilla users would miss in Phabricator]
* See [http://fab.wmflabs.org/T45 features Trello users would miss in Phabricator]
* [[:w:SPOF|'''SPOF''']] - if Phabricator breaks, everything breaks. Bug trackers should be highly available. How would you report a ticket that there is a problem with Phabricator when it is a bug tracker on its own? There will be maintenance of Phabricator and they will shut down everything. So impact of every maintenance / outage will be significantly higher than now.
* Have all the issues with [[Git/Gerrit evaluation|our previous evaluation with Git/Gerrit]] been addressed?
* No dedicated mobile application, only accessible via web. Therefore no push notifications, etc. Mobile support is better than Gerrit and Bugzilla, but not Trello (which has its own app).

Requests for comment/Phabricator

2014-04-27T21:45:17Z

RandomDSdevel: /* Support */ Replied to thread

<big>'''''Participate in the [[Talk:Requests for comment/Phabricator#Format and schedule of the RfC|first round of feedback]] by April 27'''''</big>
{{RFC
| component = 
| created = 2014-03-28 
| authors = [[User:AKlapper (WMF)|Andre Klapper]], [[User:guillom|Guillaume Paumier]]
| draft = final draft
| implementation = not started
}}
== Problem ==

The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and, all in all, the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome for both current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state of affairs and wish to consolidate the development toolchain.

See the [http://lists.wikimedia.org/pipermail/teampractices/2013-December/000205.html full email thread] for more background.

== Background ==
{{Project management tools review}}
This is what has been done so far:
* People have [[mw:Talk:Project management tools/Review|shared their needs]] and workflows.
* Andre and Guillaume have [[mw:Project management tools/Review/Requirements|summarized all of that]] into consolidated requirements.
* Andre and Guillaume have set up a [[mw:Project management tools/Review/Options|list of options]] to solve our problem, based on what was mentioned during preliminary discussions.
* People have [[mw:Talk:Project_management_tools/Review/Options|discussed the options]] and eliminated some of them in preparation for the RfC.
* Besides the wiki, communication has happened mainly on the [http://lists.wikimedia.org/pipermail/teampractices/ teampractices] list, with updates also sent to [http://lists.wikimedia.org/pipermail/wikitech-l/ wikitech-l].
* We're now drafting this RfC and welcoming edits on both the form and the content.
The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other.

{{clear}}
<div style="border:1px solid #AAA; background:#f9f9f9; width:25%; margin:1em; padding:1em; float:right;">
{{:Requests for comment/Phabricator/FAQ}}
</div>

== Proposal: Move to Phabricator ==

This proposal consists of replacing several of our tools with one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. This means you'll only need one account for everything, and all tasks / bugs / commits / screenshots will be cross-referenced automatically. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.

You can [http://fab.wmflabs.org/ test Phabricator] in Labs. This is an actual test instance, so don't be afraid to break things.

If this proposal fails to gather agreement, we will keep the status quo. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year. We may want to consider consolidating our project management tools later into [https://scrumbu.gs/ Scrumbugz] (a tool that works on top of Bugzilla) but that will be a separate discussion.

You're welcome to contribute to the [[Requests for comment/Phabricator/FAQ|developing FAQ]] and browse the [http://fab.wmflabs.org/project/board/14/ Wikimedia Phabricator] project in our test instance, which we're using to identify missing features and plan the possible migration.

=== In favor of Phabricator ===

* But migration of existing content (including closed bugs, etc.) is critical. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk:Jdforrester (WMF)|talk]]) 00:24, 15 April 2014 (UTC)
* --[[User:JEissfeldt (WMF)|JEissfeldt (WMF)]] ([[User talk:JEissfeldt (WMF)|talk]]) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James
* +1 to what James said. BZ data must be migrated. ^[[User:^demon|demon]][[User_talk:^demon|[omg plz]]] 16:40, 15 April 2014 (UTC)
* Support as long as teams can still user third party tools like Trello as necessary [[User:Tfinc|Tfinc]] ([[User talk:Tfinc|talk]]) 00:20, 17 April 2014 (UTC)
* The idea of having developers, designers, product managers, and just any volunteer using one tool with their Wikimedia credentials is worth fighting for. The migration will be complex, [http://fab.wmflabs.org/T37 but we are planning for it]. Phabricator is coded in PHP, a language that MediaWiki developers are familiar with, and the upstream project takes feedback and patches.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:50, 17 April 2014 (UTC)
* I imagine there will be a lot of "ZOMG my favorite feature of X isn't here" but I think having issues and code review and planning all in one pile would be worth the pain of learning a new set of tools. [[User:BDavis (WMF)|BDavis (WMF)]] ([[User talk:BDavis (WMF)|talk]]) 17:12, 17 April 2014 (UTC)
* I think it will be worth the effort. [[User:Grunny|'''Grunny''']] ([[User talk:Grunny|talk]]) 18:03, 17 April 2014 (UTC)
* While I feel the current tools meet the needs (AFAIK), Phabricator's oneness seems to be much better with one account for every service as opposed to every account for every service. What James said it pretty much critical with this. [[User:John F. Lewis|John F. Lewis]] ([[User talk:John F. Lewis|talk]]) 17:33, 18 April 2014 (UTC)
* I like the fast diff-view in Phabricator (diffs of huge files are almost impossible to view in gerrit for me and I do not want to view them in a custom diff viewer every time; with Opera, I struggle in gerrit anyway), the fact that it is all-in-one and most important to me that it is possible to create profiles so I can hopefully see to whom I am talking. I think it's worth migrating, although the terminology is fundamentally different. -- [[User:Rillke|Rillke]] ([[User talk:Rillke|talk]]) 11:25, 20 April 2014 (UTC)
* per others. --[[User:Zhuyifei1999|Zhuyifei1999]] ([[User talk:Zhuyifei1999|talk]]) 12:16, 20 April 2014 (UTC)
* For volunteers like me, who spend only a few hours during their spare time on Mediawiki development, it takes a lot of time to get along with all the tools. Furthermore it's sometimes strange that some information like RT or ORTS is hidden. (How do I sign with VE?)--[[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 12:45, 20 April 2014 (UTC)
* Strongly in favor. Phabricator is a pleasure to use. It strikes me as having been designed and architected with awareness of the pain-points of collaborative software development. The interface has a way of nudging you towards positive, constructive interactions. Its command-line tool, arc, is superb. The documentation is excellent. Upstream is very responsive. Features like [https://secure.phabricator.com/book/phabricator/article/herald/ Herald] are innovative and useful. Let's do it. --[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 19:51, 20 April 2014 (UTC)
* In favour. This would be a nice change, and has much better functionality than the antiquated bugzilla. [[User:Ajraddatz|Ajraddatz]] ([[User Talk:Ajraddatz|Talk]]) 21:56, 20 April 2014 (UTC)
* Strongly in favour of this. Both Bugzilla and Gerrit aren't the best platform in my opinion, and Phabricator looks much better. I especially like Phabricator being based on PHP, since Bugzilla's Perl code was something I never liked. --[[User:GeorgeBarnick|GeorgeBarnick]] ([[User talk:GeorgeBarnick|talk]]) 21:59, 20 April 2014 (UTC)
* I want ''one place'', not three or four, to go document and discuss patches and the issues related to them. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:17, 21 April 2014 (UTC)
* I will favor anything that lets me edit code online, instead of having to install specialized software, keeping a local copy of the code and hand-crafting patches. (I asume some form of local-repository development will remain possible.) — [[User:Edokter|Edokter]] ([[User talk:Edokter|talk]]) — 11:26, 21 April 2014 (UTC)
* I honestly do not care all that much for Phabricator's current UI, but I expect that it can be tweaked as we gain expertise with it (or that it can be ''made'' to be tweakable). The point for me is that the status quo is not tenable: having to use at least six disjoint tools that barely interface with each other just to do day-to-day work is a guaranteed recipe to have things fall between the cracks. It also means that even if we ''do'' end up having to hammer our workflow into the code, there is just the one tool to fiddle with. — [[User:MPelletier (WMF)|MPelletier (WMF)]] ([[User talk:MPelletier (WMF)|talk]]) 12:52, 21 April 2014 (UTC)
* '''Strong support''' per Ori and Steven. [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 17:01, 21 April 2014 (UTC)
* Folks commenting in the "No" column should recognize that tools like Trello and Mingle haven't made it into the WMF workflow for whimsical reasons; Bugzilla simply lacks an adequate project management workflow. In the absence of better PM tools, we'll have a fragmentation of information flows which leads to its own inefficiencies. Tools like Scrumbugz seek to address this, but it's in the context of an aging, rigid codebase. Phabricator is built to support modern development practices and looks very promising from everything I've seen so far (proliferation of silly proper noun names for different functions notwithstanding). I think an incremental migration with checkpoints on real-world issues is the way to go.--[[User:Eloquence|Eloquence]] ([[User talk:Eloquence|talk]]) 17:10, 21 April 2014 (UTC)
* Well I'm hugely biases since I was advocating Phabricator when it was a decision between that and Gerrit. (Having said that, the reasons others gave for not switching were very viable at the time only to be mitigated by Phabricator's continued upward trajectory.) I caution people during the migration for an expectation of a feature-for-feature parity improvement is not in the cards, but on balance the rewards outweigh the loses, and this has been the case for many PHP-based software endeavors both closed and open-source as evidenced at how low the churn has been away from using Phabricator. [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:31, 21 April 2014 (UTC)
*: (Wanted to put this below, but I couldn't figure a good place in the other options to put it). I have concerns about the logistics of this migration. I think it might be easiest to transfer via Gerrit, then PM tools (Trello, Mingle, etc), then Bugzilla. The first requires just alignment on developers and actually removes some unnecessary overhead. The second should be staggered on a project-by-project basis over a longer duration as the positives outweigh the negatives (as the teams would have to migrate their existing entries or had specific reasons/features that caused them to use a certain tool). The third probably last as it involves the largest institutional inertia and affected people, however the full benefit won't be seen until Bugzilla is integrated. Not sure if it can be staggered or what the transition looks like, but I do thing while it should be handled right, some compromise on the loss of a couple of data fields should be acceptable (a lot of metadata in Bugzilla is useless/archaeic). [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:32, 21 April 2014 (UTC)
* Strong support for everything in one place. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 21:38, 21 April 2014 (UTC)
* Support for the unification of development in a single place, as someone who has primarily used these tools for looking at what's in development and for reporting bugs. Right now it's a huge pain to navigate Bugzilla and submit things, and the disconnect between Bugzilla and Gerrit is fairly annoying. --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 21:43, 21 April 2014 (UTC)
**Cannot. Agree. More. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 23:30, 21 April 2014 (UTC)
* Support - Phabricator has come a long way in the past couple of years. What looks awfully promising about it is that they seem to have a coherent vision for providing tools that make development teams productive, and a focus on important things that most tools in this space neglect (user interface, performance, and a sense of humor). From all outward indications, the upstream will be a joy to work with, and the tool is in a programming langauge (PHP) that we have a lot of familiarity with. The migration promises to be a miserable experience (all migrations of this scale are...no matter how great the tool), but this is the first toolset I've seen that looks likely to be worth the pain. -- [[User:RobLa-WMF|RobLa-WMF]] ([[User talk:RobLa-WMF|talk]]) 00:25, 22 April 2014 (UTC)
** Speaking of the 'sense of humor,' maybe we could somehow import those funny quotes that users can optionally make Bugzilla put at the top of every page of that tool's search results while we're importing it whether we do this importing manually or automatically? — [[User:RandomDSdevel|RandomDSdevel]] ([[User talk:RandomDSdevel|talk]]) 21:45, 27 April 2014 (UTC)
*This would be awesome. The current mess of tools (especially bugzilla vs trello vs mingle) is quite frustrating for finding whether something is already noted, and has made me not want to enter bugs for myself (especially in Bugzilla with its irritating login requirements). SUL integration would be great if possible. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 01:27, 22 April 2014 (UTC)
* Strong support: per others, it's always a good idea to have one place for all tasks. [[User:Chmarkine|Chmarkine]] ([[User talk:Chmarkine|talk]]) 03:44, 22 April 2014 (UTC)
* Support - I haven't used dev tools yet, it would be easier to have 1 place to go and start [[User:Aprillion|Aprillion]] ([[User talk:Aprillion|talk]]) 12:17, 22 April 2014 (UTC)
* Support - having all tools in one place can only be a good thing. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:29, 22 April 2014 (UTC)
* Support - Based on what I know so far, I support moving to Phabricator. The top practical problem I face with the current solution is going back and forth between Trello and Bugzilla, but see below for secondary issues. However, we do need to ''ensure'' we're not just adding another tool without replacing/removing anything. This means at least turning off/redirecting/marking read-only Bugzilla and Gerrit. The most realistic way to accomplish that is to do a complete migration of ''at least'' Bugzilla, ideally other issue tracking tools like Trello, Mingle, etc., and possibly others like Gerrit. I've already seen some cool features in Phabricator (e.g. updateable mocks, drag-and-drop file uploading, simple embedding and linking and CCing (oddly, Trello does not allow you to CC other users). It also should allow much tighter integration between Gerrit and Bugzilla (no more getting two Bugzilla emails after you upload a patch to Gerrit, and perhaps auto-fixing bugs based on a commit message tag). Being written in PHP is definitely helpful. It will not magically mean every MediaWiki PHP dev works on Phabricator, but it will hopefully encourage creating a critical mass of collaboration with upstream. I also strongly support using open source infrastructure, so this is a step in the right direction on that front. There will definitely be switching costs and issues, but so far it looks like it will be worth it. [[User:Superm401|Superm401]] - [[User_talk:Superm401|Talk]] 21:38, 22 April 2014 (UTC)
* '''Strong Support''' - There are issues with Phabricator, like any single tool that would be an option (there is no unicorn that covers all use-cases efficiently), but I think it's biggest strength is Evan P and the Phabricator community. His responses to our suggestions/requests have been amazing. And it isn't just us. Other organizations that have migrated to Phabricator have had similar experiences; someone reports an issue that Phab has with their internal work flow, a week later Even P comes back with a fix, before the org (devianArt in this case) could even start working on it. Evan P and the rest of the Phab community is awesome and are an upstream that I want to work with more than pretty much any other. And in the long term, the relationship you have with your upstream is tantamount to pretty much anything else. [[User:Greg (WMF)|Greg (WMF)]] ([[User talk:Greg (WMF)|talk]]) 16:04, 23 April 2014 (UTC)
* Support, even though I have not used other tools (yet) than Bugzilla, but it's always better to have everything at the same place (if possible). --[[User:Stryn|Stryn]] ([[User talk:Stryn|talk]]) 17:58, 23 April 2014 (UTC)
* I have been playing with it for a while and I say '''Let's go get this thing deployed on our servers''' [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 07:36, 24 April 2014 (UTC)
* Support - Yes please -[[User:Fastily|<big>F</big>ASTILY]] [[User talk:Fastily|(TALK)]] 00:13, 25 April 2014 (UTC)
* '''Support''' the pain is real! Copying issues between bugzilla and {team's Project Management tool}, the disjointed concurrent discussion in bugzilla|gerrit|{team's Project Management tool}, the mindless busywork of keeping the state of an issue up-to-date in all three tools, the redundant notifications that this busywork generates, ... A ''fourth'' area that Phabricator integrates is design mockups, an area where the MediaWiki community has never had a good tool. You can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people can comment on it, see http://fab.wmflabs.org/M1/1/ . -- [[User:S Page (WMF)|S Page (WMF)]] ([[User talk:S Page (WMF)|talk]]) 19:36, 25 April 2014 (UTC)
* Support - As someone considering getting into extension development/generally helping out in the next few months, learning to use one tool is much less intimidating than trying to figure out a workflow across five different sites. Phabricator, from my exploration of it, looks nice and intuitve for all the basics.-[[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 19:41, 25 April 2014 (UTC)
* Yes. However, It should be possible to use Wikimedia/Wikitech account to log in to Phabricator, rather than having an independence system (currently you need to create a new account to Bugzilla). (In the future, I hope Wikitech can be added to [https://noc.wikimedia.org/conf/highlight.php?file=all.dblist all.dblist], so that users can use SUL account to log in WMFlabs, rather then create a new account: current account in Wikitech would be merged to SUL ones.)--[[User:GZWDer|GZWDer]] ([[User talk:GZWDer|talk]]) 12:21, 26 April 2014 (UTC)
* Support - Moving to one integrated toolset seems like a dream come true. --[[User:Lydia Pintscher (WMDE)|Lydia Pintscher (WMDE)]] ([[User talk:Lydia Pintscher (WMDE)|talk]]) 17:41, 27 April 2014 (UTC)
* I believe that a single integrated system is absolutely a good idea. The sheer number of tools being used simultaneously at present is bewildering (RT is involved somewhere as well?!). However the comments on display here lead me to feel that Phabricator appears to require a little more work before it's quite ready. I have two other concerns: firstly, there needs to be an assurance that after the change Bugzilla will be maintained in read-only mode forever; it has a decade's worth of incoming links that shouldn't be broken. Secondly, when Bugzilla bugs are imported, will their entire comment history be imported as well? I think that it should. The discussions associated with bugs are by far the most important aspect of the whole thing. If dealing with a bug in the new system requires having to scoot back to Bugzilla to pick up on all the context and/or previous decisions, that messes up the point of only having a single bugtracker. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 13:14, 27 April 2014 (UTC)
** Yes {{u|Scott}}, [http://fab.wmflabs.org/T55 RT is part of the plan]. [http://fab.wmflabs.org/T65 Redirects of Bugzilla URls to Phabricator] are also planned and, yes, we are talking about importing all reports including the comments. There should be no need to keep the Bugzilla instance available forever, but we can allow ourselves as much time as needed. You can check and discuss the details at [http://fab.wmflabs.org/T39 http://fab.wmflabs.org/T39]. "Phabricator appears to require a little more work before it's quite ready", maybe, you can help defining exactly what needs to be done before the migration, see [http://fab.wmflabs.org/T43 Define what features existing in our current tools are really missing in Phabricator] and dependent tasks.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:29, 27 April 2014 (UTC)
*** I only have experience using WMF's Bugzilla but I'll certainly contribute anything I notice about Phabricator - obviously I've not had much time to investigate it. Thanks for the links. That's good news about the import, too - in which case I guess then just so long as URL redirects are set up for old Bugzilla URLs there'll be no need to keep the old system around. So given all that, I've moved this to the support area. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 18:34, 27 April 2014 (UTC)
**** After just a few minutes of playing with Phabricator - ''boy howdy!'' Bugzilla feels like the stone age compared to this thing. I have no doubt that any features people consider missing can be added upstream. Consider me sold. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 21:27, 27 April 2014 (UTC)
* Support per above - it's better to have everything centralized in just one place. [[User:LlamaAl|LlamaAl]] ([[User talk:LlamaAl|talk]]) 19:08, 27 April 2014 (UTC)

=== In favor of keeping our current tools ===

* I would like to see a rough roadmap of the migration and what task force is going to be allocated to it. I looked a bit around and could not find how we are going to handle the transition. I dont mind changing tools, but I wish we handle it as a proper project or we risk spending a couple years doing the migration on a best effort basis. So until we have a migration plan, I will remain suspicious. [[User:Hashar|Antoine "hashar" Musso]] ([[User talk:Hashar|talk]]) 21:08, 17 April 2014 (UTC)
*: [http://fab.wmflabs.org/project/view/14/ Everything is being tracked] in our test instance itself: [http://fab.wmflabs.org/T37 how to migrate everything], [http://fab.wmflabs.org/T43 what features are currently missing], [http://fab.wmflabs.org/T59 how to configure it] for our needs, even the [http://fab.wmflabs.org/T41 resource planning]. Is this what you were looking for? It's still incomplete, but resources for a migration task force won't be allocated unless this RFC shows explicit support from the technical community. [[user:guillom|guillom]] 14:01, 18 April 2014 (UTC)
* Meh, I hate changing systems which (apparently) work. Though, I don't feel strongly on this issue. [[User:Vogone|Vogone]] [[User talk:Vogone|'''talk''']] 17:37, 18 April 2014 (UTC)
* "The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists" so you want to add one more? But if you show me the way how to force all people to move to the new system I may support. (And no it's not disabling old tools which would just mean loosing usefull stuff of users who would not give up (or wont know how to move) even under such conditions as it's with TS -> Labs move in some way happened) --[[User:Base|Base]] ([[User talk:Base|talk]]) 14:04, 19 April 2014 (UTC)
*: It's not "adding one more" as we are after ''replacing'' systems. Old systems become read-only or disabled, if that's how you interpret "forcing". --[[User:AKlapper (WMF)|AKlapper (WMF)]] ([[User talk:AKlapper (WMF)|talk]]) 07:07, 20 April 2014 (UTC)
*: There is some precedent for "replacing" over "adding" that might mitigate some of the pessism: In 2012, Subversion was replaced with Git/Gerrit. On a per-project level, many teams have migrated between multiple project management tools—bulletin board, Wiki, Bugzilla, Trello. Mingle, and Google Doc—never using more than one concurrently for more than 2 weeks during a transition. Also, the major pain point in PM tools cited is poor integration of those tools with Git and Bugzilla (or general crumminess of management capabilities in the case of Bugzilla), this is especially bad for those who have to navigate multiple tools in the course of their work (notably tech leads, scrum master, and product managers). The multiplicity/redundancy is also the source of much friction because of the lack of responsiveness due people not being on a tool (for instance the devs working from Gerrit, while the bug was in Bugzilla) [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:40, 21 April 2014 (UTC)
*It's probably worth integrating MediaWiki with Bugzilla more. Bugzilla has an API. If WMF could also work on making Bugzilla more mobile-friendly and "user-friendly", I'm sure everyone would appreciate it. [[User:Gryllida|Gryllida]] 07:22, 20 April 2014 (UTC)
** We don't use MediaWiki for a project management and issue-tracker, because that's not what it is for. For years, we did code review on-wiki (see [[Special:Code/MediaWiki/status/resolved|examples]]) and it was a nightmare to work with. A wiki is a great tool for documenting things. It's not a code review tool or issue tracker. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:23, 21 April 2014 (UTC)
* 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. [[User:Hym411|—]] [[User talk:Hym411|Revicomplaint?]] 07:28, 20 April 2014 (UTC)
*I don't think any change is required at the moment. Bugzilla, Gerrit, etc. are quite adequate for our current needs. I have never had any problems or concerns with them. The integration between the tools may be a bit hackish at times, but to me, the fact that the current systems are in widespread use and perhaps already familiar to newly-arriving developers is more important. What's more, I don't like Phabricator. It's a rather intimidating web app which looks like it could have a steep learning curve, and could undo some of the good work of people like Quim in attracting new developers to the WMF's projects. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 09:58, 20 April 2014 (UTC)
**For what is worth, one of the reasons why I support Phabricator is to offer to new contributors a single tool with Wikimedia SUL that fits in the expectations of regular GitHub users. Currently it is painful to send newcomers to Bugzilla and Gerrit in addition to mediawiki.org, while having teams more and more invested in Trello/Mingle (because Bugzilla won't handle the PM work) is a pain for everybody, newcomers included.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:50, 21 April 2014 (UTC)
**Personally, I find having to create accounts for multiple different services with different workflows and having to try to figure out how to use every single one separately is far more difficult than if we were to introduce them to a single service which contains all the development work and bug reports in a single location. That, plus the interface is far better looking ''and'' easier to use than Bugzilla (keep in mind that you're used to Bugzilla, so if you can navigate it easily that's probably why). --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 01:50, 22 April 2014 (UTC)
*I'm only commenting on Bugzilla (and slightly RT) here, As i've had limited to no use with the other tools, I don't think think moving will solve any of the "real" issues we currently have, The issue with multiple tools is more due to staffing and cultural issues allowing it to be come so spread out, Whilst some of these tools do have their uses, Some should also be dropped or restricted to very specific use cases, For example RT was introduced because of the security & permissions point of view when needing to deal with outside individuals and a few other small cases it has since basically evolved into a private ops bugtracker with a lot of information that could probably already be in BZ. Also another issue is the maturity and team backing Phab, For example when gerrit was chosen compared to custom writing something like we did with SVN (E:CodeReview) it was decided against because we would land with the same issues about having to maintain the code. [[User:Peachey88|Peachey88]] ([[User talk:Peachey88|talk]]) 08:52, 21 April 2014 (UTC)
** {{u|Peachey88}}, can you explain your last comment? Phabricator is a young project, but they have a significant community and user base that keep gaining momentum, see [https://www.ohloh.net/p/compare?project_0=Bugzilla&project_1=Gerrit+Code+Review&project_2=Phabricator an Ohloh comparison with Bugzilla and Gerrit], and [[w:Phabricator#Users]].--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:40, 22 April 2014 (UTC)
*I think the overhead of migrating and learning the new interface is not worth the effort. Bugzilla works fine for most of what we do. The interface also looks a bit scary to me, although Bugzilla's interface is not completely obvious either. Bugzilla is also used for more free software projects and thus has been proven to work in practice. Basically echoing Revi and TTO's concerns as well. As Multichill mentioned, we don't want to add [https://xkcd.com/927/ another competing standard] for teams to choose from (Trello, Mingle, ...) [[User:PiRSquared17|πr2]] ([[User talk:PiRSquared17|''t'']] • [[Special:Contributions/PiRSquared17|''c'']]) 21:43, 22 April 2014 (UTC)
** This isn't just about replacing Bugzilla. Phabricator lets us consolidate a host of disparate tools (Bugzilla, Gerrit, git.wikimedia.org, others) in to one view of work on MediaWiki. What's more: Bugzilla is clearly not working for Wikimedia Foundation developers, who are doing a large bulk of the work that is tracked in Bugzilla. This is obviously the case when you consider that nearly all teams are using a secondary project management tool on top of Bugzilla, and may even disregard Bugzilla as the canonical list of bugs/issues with a component, because it's such a mess. This doesn't even begin to touch how unfriendly Bugzilla is to non-developers who we want to report issues... [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 21:09, 23 April 2014 (UTC)
* As long as we do not force people to switch to only Phabricator (and forcing would be bad), we'll not reach the desired consolidation of tools, but just add another tool to the set of tools the different teams use. For me, bugzilla and gerrit both have their issues, but they get the job done sufficiently well. Of the many open bugs in our Phabricator, Phabricator's requirement to use "arc" instead of plain git to fetch/push commits bothers me the most. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 22:52, 23 April 2014 (UTC)
** {{u|QChris}}, reply from maintainer epriestley at #phabricator: ''"everything works fine without arc | you get more features and stuff with it, people mostly seem pretty happy about them | but it's absolutely not required | If some of the documentation was misleading in that respect, let me know and I'll fix it."''--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 21:41, 24 April 2014 (UTC)
*** {{u|Qgil}}, I followed up with epriestly. Without arc, you're expected to 'git diff' and copy/paste that in the web UI. That's not a "works fine" for me :-) First, it's really, really inconvenient. And then you'll loose commit metadata that way. Like committer, author, and most important: parent of a commit. But Phabricator does not value this kind of metadata much anyways. For example "arc patch/land" does not honor them either (see upstream ticket [https://secure.phabricator.com/T4333 T4333]). Also, merging a patch is not possible nicely without arc. You have to merge in your repo locally, and then push directly to the branch to bypass review. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 00:04, 25 April 2014 (UTC)

=== Basically neutral ===
* Personally, with the current test installation (microscopic fonts, functions [http://fab.wmflabs.org/T119 hidden behind unlabeled icons], other icons not clickable, tendency to feature bloat, some features like [http://fab.wmflabs.org/T150 voting missing], other features like Gerrit and GitHub integration not testable at the moment) I can't decide if it's worth my time. It could be the greatest thing on earth or turn into a bottomless pit. A project that starts with ''"We can't manage 12 tools! We need to do something!"'' could also end with ''"Now we have 13 tools."'' --[[User:Thiemo Mättig (WMDE)|Thiemo Mättig (WMDE)]] 14:14, 17 April 2014 (UTC)
* I am in favor of trying out Phabricator for a few select projects so we get a better idea of what moving over all projects would mean --[[User:Jeroen De Dauw|Jeroen De Dauw]] ([[User talk:Jeroen De Dauw|talk]]) 19:09, 17 April 2014 (UTC)
* I gave it a try, very stressful so far (I hope not to touch it for a few weeks now, I'll need some discipline). Will need huge amounts of help to figure out, if we really want to kill bugzilla: I expect at least a couple hundreds more bugs need to be filed and triaged, please help with testing. My results so far are visible at [http://fab.wmflabs.org/p/Nemo_bis/] (only partly and only after login, try the [http://fab.wmflabs.org/search/query/advanced/ search]). --[[User:Nemo_bis|Nemo]] 19:10, 19 April 2014 (UTC)
* I'm not convinced that the time invested in changing our code review tool (again) is worth the expected benefits. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 07:40, 20 April 2014 (UTC)
* IM kinda HO we gotta change default avatar on our demo, it's unacceptable for me to use [[w:Psyduck|an NFC image]] as it... --[[User:Liuxinyu970226|Liuxinyu970226]] ([[User talk:Liuxinyu970226|talk]]) 10:15, 20 April 2014 (UTC)
* I share Legoktm's and Thiemo's concerns, but I also see the problem with our current (overwhelmingly) large tool stack. The most important thing over here is to really make the cut on the n tools we have atm and to not have n+1 tools after. - [[User:Hoo man|Hoo man]] ([[User talk:Hoo man|talk]]) 11:45, 20 April 2014 (UTC)
* I'm basically neutral but I couldn't agree more with Antoine: If we're going to change, it should be done with a proper project. When I talk about a project, I'm talking about a project as defined [[:en:PRINCE2|here]]. Clear goal, clear time path, clear budget etc. I'm a bit afraid [https://xkcd.com/927/ this] is going to happen. [[User:Multichill|Multichill]] ([[User talk:Multichill|talk]]) 15:23, 20 April 2014 (UTC)
* I dont mind, I am not a developer. If you think you need it. Do it. But do it once. It take us some time, to get in touch with bugzilla. So we will need some time to get in touch with the new sw. ('''errr, where I have a singnature button in Visual Editor?) '''[[user:Juandev|Juandev]]
* A new system could be nice, I don't really care either way. But we want to make sure users will not be suddenly surprised by this.--[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:18, 21 April 2014 (UTC)
* I largely agree with Multichill, et al. Some specific team (whether that's a Wikimedia Foundation team or a Wikimedia chapter team or a coalition of volunteers) has to take charge of this and properly migrate the current suite of tools to Phabricator. This will be tedious and long and annoying.As long as whatever new tool is implemented has IRC feeds, I'm pretty neutral on the topic. I will say that in my limited interaction with Phabricator, it seems to go out of its way to be gimmicky and obnoxious. I'm wondering if that's a configurable mode. It might be nice to enable rotating cutesy submit buttons and "stickers" in a year or two, but for now, the transition will be difficult enough without Phabricator constantly dressed in a clown costume. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 00:31, 21 April 2014 (UTC)
**The silly names have been turned off already - it's now in "serious business" mode (instead of "fun mode"). Discussion at http://fab.wmflabs.org/T119 –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 22:22, 21 April 2014 (UTC)
*On the one hand, Phabricator is one unified system which will therefore likely reduce the work we need to keep so many separate systems going. On the other hand, it's unclear to me what cost the migration will have, and how much time it will take learning a new system. Without having more data to figure out whether the pluses overcome the minuses, I am basically neutral. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 15:44, 21 April 2014 (UTC)
* I now support this proposal, here is my former opinion: This discussion would be far more simple if we point out the biggest improvements and potential bigest issues that migration would do, so please fill up this list with that is in your mind. I am not really againsted Phabricator, but I really do like bugzilla, as that is one of best open source bug trackers and saying just "let's have 1 tool for everything" is not much of argument to me :) For this reason I created new section with pros cons. [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:48, 21 April 2014 (UTC)
*:Which tools are we actually talking about is it just bugzilla and gerrit that would be unified or is there more of them? [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:51, 21 April 2014 (UTC)
*::The other dimension is project management tools. This includes Mingle and Trello which are actively in use in the WMF, which would also be replaced by Phabricator. People at the WMF have written scripts to actively copy Bugzilla bugs into Mingle and Trello, but these scripts occasionally need maintenance. So, Bugzilla and Gerrit are the big ones most people know about, but there are others. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 17:19, 21 April 2014 (UTC)
*:Most impressive part I found is that it allows regular users to create own repositories. This however needs to be enabled. Would this be enabled on production version of phabricator? I am not using our gerrit only because I have to wait weeks or months for repositories to be created and that suck. Primary reason I stick with github is this feature (being able to create new repo in 10 seconds) [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 09:20, 22 April 2014 (UTC)
* I'm neutral to the debate of using Phabricator over Bugzilla and Gerrit. However for the management of Features (user stories) and their workflows using Agile Scrum methodology, I prefer Trello. It is possible to adapt a Phabricator Workboard to suit product management, however I recommend creating a separate project for product Features so your Workboard does not get overrun with the sight of new bugs and subtasks. One more reason I prefer Trello over Phabricator is this issue: http://fab.wmflabs.org/T195 {{unsigned|KLeduc (WMF)|15:52, 22 April 2014‎ (UTC)}}
**Being Trello a proprietary service, and requiring users to register in a 3rd party server to participate, there is no way Trello (and Mingle) will fit in the Wikimedia context in the long term. They are ok-ish short term solutions because our teams didn't find better tools. T195 can be fixed customizing the CSS; community division and WMF teams planning elsewhere are much bigger problems.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 18:43, 22 April 2014 (UTC)
* As an occasional tech, I am happy with Bugzilla, I don’t use Trello/Mingle/RT, and I "invested" time to learn Gerrit (and Git) more than one year after Gerrit was installed in production because I had no time before, so a bit sad if these leave. On the other side, I understand WMF developers want a more integrated tool for easier project management. Anyway, if Phabricator (or another tool) is used, please use it at least 5 years to let time to community members to learn it and become accustomed to. ~ [[User:Seb35|Seb35]] [[User talk:Seb35|[^_^]]] 23:17, 22 April 2014 (UTC)
* As someone that has dealt numerous times with Mingle SoS cards linked to a Bugzilla forwarded to an RT ticket, I'm excited about the prospect of a unified bugtracker, even in the case where I'd have to sacrifice useful functionality that each of these tools provides to me. I'd be hugely in favor of this, but: I'm a lot more worried about Phabricator's code review system and git integration, especially in regards with traditional git workflows (Gerrit is pretty bad in this aspect, but the arc workflow seems even worse, see e.g. the commits messages in Phabricator's own repository). It seems to me that the evaluation so far has been mostly on the issue tracker functionality; it might make sense as a first step, but now we're being asked for our opinion on a proposal to replace our code review system as well, and I don't feel sufficiently informed about that. [[User:Faidon Liambotis (WMF)|Faidon Liambotis (WMF)]] ([[User talk:Faidon Liambotis (WMF)|talk]]) 00:37, 25 April 2014 (UTC)
** {{u|Faidon Liambotis (WMF)}}, {{u|QChris}} is testing the area of code contributions and reviews, and he creating tasks under [http://fab.wmflabs.org/T47 Identify features Gerrit users would miss in Phabricator]. The attention of other users with experience in Git/Gerrit is welcome. Phabricator brings indeed a different paradigm that seems to be working for some organizations, but would it work for us? If not, is it a matter of features missing or is there something deeper? I agree that this needs further investigation and discussion.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:35, 27 April 2014 (UTC)
* Jeroen De Dauw could be my spokeperson. — [[User:Danny B.|Danny B.]] 15:40, 27 April 2014 (UTC)

== Pros / Cons ==
''For a specific comparison with Bugzilla, see [[Requests for comment/Phabricator/versus Bugzilla]]''
=== Pros (improvements) ===
* '''Everything would be in one place'''
** Single login for everything (''Can we integrate Phabricator and SUL?'' That would be cool. See [http://fab.wmflabs.org/T40 Pick an authentication provider].)
** Better integration of subsystems like bug tracker, git etc
** Single interface with no need to switch between differently looking, possibly confusing other interfaces of other instruments (like buzilla, gerrit etc).
** Integrates design and designers. Phabricator organizes design mockups and feedback in the same tool as code; you can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people [http://fab.wmflabs.org/M1/1 can comment on it].
** Responsivity and communication will be improved (currently a lot of issues brought up in one tool are missed in the other. i.e. a bug in Bugzilla is not addressed because the PM is working on a management tool, even after addressed the bug is not closed after the patch is reviewed and committed in Gerrit, there is no evidence that work is being done in Bugzilla even though there may be a lot of activity in Git or the management tool regarding that specific bug).
** Integrations between tools (e.g. Bugzilla to Mingle) is done ad-hoc and usually on a per-project basis because there is no return to scale to do this across others as they use different tools for certain key parts.
** Prioritization in bugzilla has no roadmap burn-down to why it is or isn't being worked on by those involved in a project (ScrumBugz into Bugzilla would solve it, but only if projects move to it).
* '''Faster reviewing of code''' (especially large diffs), and '''improved commit/review procedures'''
** Multi-commit single-branch review support instead of the approach in gerrit where each change is a single commit that is amended for each new patch set
* Support for '''code auditing''', with automatic notification based on rules and conditions
* '''Written in PHP''', so it's more '''easily extensible'''
** Already a deep knowledge on PHP due to it being the language of MediaWiki expertise
** Gerrit is in Java, Bugzilla is in Perl, most PM tools are closed-source and hosted on commercial sites with integration being their own unique APIs, neither has a large developer footprint in the community
** Deep integration between Phabricator (issue tracking, project/task management, and commits) and Wiki becomes a real possibility again (something we lost when we moved away from CodeReview).
* '''Mobile-friendly'''. Login from any mobile device and see what you can read and do. Now, open Bugzilla and Gerrit...
* Tasks can be assigned to more than one project. Projects can be easily as if they were keywords. No more discussions about products / components taxonomy, no more fights to decide where a bug should be filed. See [http://fab.wmflabs.org/T68 How to organize projects].
* '''Respects privacy more'''. Bugzilla and Gerrit expose your email address. Phabricator does not.
* '''Better developer tools''', specifically [https://secure.phabricator.com/book/phabricator/article/arcanist/ Arc], the command line interface to Phabricator. This means we would no longer we dependent on git-review or [http://www.gossamer-threads.com/lists/wiki/wikitech/419135 hacking together] our own tools.
* Possibility to let users create their own repositories. See [http://fab.wmflabs.org/T196 Enabling creation of repositories by regular users?]

=== Cons (potential issues) ===
* There will be a '''learning curve''' in switching to new software
* See [http://fab.wmflabs.org/T46 features Bugzilla users would miss in Phabricator]
* See [http://fab.wmflabs.org/T45 features Trello users would miss in Phabricator]
* [[:w:SPOF|'''SPOF''']] - if Phabricator breaks, everything breaks. Bug trackers should be highly available. How would you report a ticket that there is a problem with Phabricator when it is a bug tracker on its own? There will be maintenance of Phabricator and they will shut down everything. So impact of every maintenance / outage will be significantly higher than now.
* Have all the issues with [[Git/Gerrit evaluation|our previous evaluation with Git/Gerrit]] been addressed?
* No dedicated mobile application, only accessible via web. Therefore no push notifications, etc. Mobile support is better than Gerrit and Bugzilla, but not Trello (which has its own app).

Requests for comment/Phabricator

2014-04-27T18:32:51Z

RandomDSdevel: /* Proposal: Move to Phabricator */ Split up a run-on compound sentence into a properly comma-delimited one.

<big>'''''Participate in the [[Talk:Requests for comment/Phabricator#Format and schedule of the RfC|first round of feedback]] by April 27'''''</big>
{{RFC
| component = 
| created = 2014-03-28 
| authors = [[User:AKlapper (WMF)|Andre Klapper]], [[User:guillom|Guillaume Paumier]]
| draft = final draft
| implementation = not started
}}
== Problem ==

The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and, all in all, the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome for both current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state of affairs and wish to consolidate the development toolchain.

See the [http://lists.wikimedia.org/pipermail/teampractices/2013-December/000205.html full email thread] for more background.

== Background ==
{{Project management tools review}}
This is what has been done so far:
* People have [[mw:Talk:Project management tools/Review|shared their needs]] and workflows.
* Andre and Guillaume have [[mw:Project management tools/Review/Requirements|summarized all of that]] into consolidated requirements.
* Andre and Guillaume have set up a [[mw:Project management tools/Review/Options|list of options]] to solve our problem, based on what was mentioned during preliminary discussions.
* People have [[mw:Talk:Project_management_tools/Review/Options|discussed the options]] and eliminated some of them in preparation for the RfC.
* Besides the wiki, communication has happened mainly on the [http://lists.wikimedia.org/pipermail/teampractices/ teampractices] list, with updates also sent to [http://lists.wikimedia.org/pipermail/wikitech-l/ wikitech-l].
* We're now drafting this RfC and welcoming edits on both the form and the content.
The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other.

{{clear}}
<div style="border:1px solid #AAA; background:#f9f9f9; width:25%; margin:1em; padding:1em; float:right;">
{{:Requests for comment/Phabricator/FAQ}}
</div>

== Proposal: Move to Phabricator ==

This proposal consists of replacing several of our tools with one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. This means you'll only need one account for everything, and all tasks / bugs / commits / screenshots will be cross-referenced automatically. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.

You can [http://fab.wmflabs.org/ test Phabricator] in Labs. This is an actual test instance, so don't be afraid to break things.

If this proposal fails to gather agreement, we will keep the status quo. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year. We may want to consider consolidating our project management tools later into [https://scrumbu.gs/ Scrumbugz] (a tool that works on top of Bugzilla) but that will be a separate discussion.

You're welcome to contribute to the [[Requests for comment/Phabricator/FAQ|developing FAQ]] and browse the [http://fab.wmflabs.org/project/board/14/ Wikimedia Phabricator] project in our test instance, which we're using to identify missing features and plan the possible migration.

=== In favor of Phabricator ===

* But migration of existing content (including closed bugs, etc.) is critical. [[User:Jdforrester (WMF)|Jdforrester (WMF)]] ([[User talk:Jdforrester (WMF)|talk]]) 00:24, 15 April 2014 (UTC)
* --[[User:JEissfeldt (WMF)|JEissfeldt (WMF)]] ([[User talk:JEissfeldt (WMF)|talk]]) 01:06, 15 April 2014 (UTC) agree both with the proposal and the critical content point made by James
* +1 to what James said. BZ data must be migrated. ^[[User:^demon|demon]][[User_talk:^demon|[omg plz]]] 16:40, 15 April 2014 (UTC)
* Support as long as teams can still user third party tools like Trello as necessary [[User:Tfinc|Tfinc]] ([[User talk:Tfinc|talk]]) 00:20, 17 April 2014 (UTC)
* The idea of having developers, designers, product managers, and just any volunteer using one tool with their Wikimedia credentials is worth fighting for. The migration will be complex, [http://fab.wmflabs.org/T37 but we are planning for it]. Phabricator is coded in PHP, a language that MediaWiki developers are familiar with, and the upstream project takes feedback and patches.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:50, 17 April 2014 (UTC)
* I imagine there will be a lot of "ZOMG my favorite feature of X isn't here" but I think having issues and code review and planning all in one pile would be worth the pain of learning a new set of tools. [[User:BDavis (WMF)|BDavis (WMF)]] ([[User talk:BDavis (WMF)|talk]]) 17:12, 17 April 2014 (UTC)
* I think it will be worth the effort. [[User:Grunny|'''Grunny''']] ([[User talk:Grunny|talk]]) 18:03, 17 April 2014 (UTC)
* While I feel the current tools meet the needs (AFAIK), Phabricator's oneness seems to be much better with one account for every service as opposed to every account for every service. What James said it pretty much critical with this. [[User:John F. Lewis|John F. Lewis]] ([[User talk:John F. Lewis|talk]]) 17:33, 18 April 2014 (UTC)
* I like the fast diff-view in Phabricator (diffs of huge files are almost impossible to view in gerrit for me and I do not want to view them in a custom diff viewer every time; with Opera, I struggle in gerrit anyway), the fact that it is all-in-one and most important to me that it is possible to create profiles so I can hopefully see to whom I am talking. I think it's worth migrating, although the terminology is fundamentally different. -- [[User:Rillke|Rillke]] ([[User talk:Rillke|talk]]) 11:25, 20 April 2014 (UTC)
* per others. --[[User:Zhuyifei1999|Zhuyifei1999]] ([[User talk:Zhuyifei1999|talk]]) 12:16, 20 April 2014 (UTC)
* For volunteers like me, who spend only a few hours during their spare time on Mediawiki development, it takes a lot of time to get along with all the tools. Furthermore it's sometimes strange that some information like RT or ORTS is hidden. (How do I sign with VE?)--[[User:Physikerwelt|Physikerwelt]] ([[User talk:Physikerwelt|talk]]) 12:45, 20 April 2014 (UTC)
* Strongly in favor. Phabricator is a pleasure to use. It strikes me as having been designed and architected with awareness of the pain-points of collaborative software development. The interface has a way of nudging you towards positive, constructive interactions. Its command-line tool, arc, is superb. The documentation is excellent. Upstream is very responsive. Features like [https://secure.phabricator.com/book/phabricator/article/herald/ Herald] are innovative and useful. Let's do it. --[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 19:51, 20 April 2014 (UTC)
* In favour. This would be a nice change, and has much better functionality than the antiquated bugzilla. [[User:Ajraddatz|Ajraddatz]] ([[User Talk:Ajraddatz|Talk]]) 21:56, 20 April 2014 (UTC)
* Strongly in favour of this. Both Bugzilla and Gerrit aren't the best platform in my opinion, and Phabricator looks much better. I especially like Phabricator being based on PHP, since Bugzilla's Perl code was something I never liked. --[[User:GeorgeBarnick|GeorgeBarnick]] ([[User talk:GeorgeBarnick|talk]]) 21:59, 20 April 2014 (UTC)
* I want ''one place'', not three or four, to go document and discuss patches and the issues related to them. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:17, 21 April 2014 (UTC)
* I will favor anything that lets me edit code online, instead of having to install specialized software, keeping a local copy of the code and hand-crafting patches. (I asume some form of local-repository development will remain possible.) — [[User:Edokter|Edokter]] ([[User talk:Edokter|talk]]) — 11:26, 21 April 2014 (UTC)
* I honestly do not care all that much for Phabricator's current UI, but I expect that it can be tweaked as we gain expertise with it (or that it can be ''made'' to be tweakable). The point for me is that the status quo is not tenable: having to use at least six disjoint tools that barely interface with each other just to do day-to-day work is a guaranteed recipe to have things fall between the cracks. It also means that even if we ''do'' end up having to hammer our workflow into the code, there is just the one tool to fiddle with. — [[User:MPelletier (WMF)|MPelletier (WMF)]] ([[User talk:MPelletier (WMF)|talk]]) 12:52, 21 April 2014 (UTC)
* '''Strong support''' per Ori and Steven. [[User:Maryana (WMF)|Maryana (WMF)]] ([[User talk:Maryana (WMF)|talk]]) 17:01, 21 April 2014 (UTC)
* Folks commenting in the "No" column should recognize that tools like Trello and Mingle haven't made it into the WMF workflow for whimsical reasons; Bugzilla simply lacks an adequate project management workflow. In the absence of better PM tools, we'll have a fragmentation of information flows which leads to its own inefficiencies. Tools like Scrumbugz seek to address this, but it's in the context of an aging, rigid codebase. Phabricator is built to support modern development practices and looks very promising from everything I've seen so far (proliferation of silly proper noun names for different functions notwithstanding). I think an incremental migration with checkpoints on real-world issues is the way to go.--[[User:Eloquence|Eloquence]] ([[User talk:Eloquence|talk]]) 17:10, 21 April 2014 (UTC)
* Well I'm hugely biases since I was advocating Phabricator when it was a decision between that and Gerrit. (Having said that, the reasons others gave for not switching were very viable at the time only to be mitigated by Phabricator's continued upward trajectory.) I caution people during the migration for an expectation of a feature-for-feature parity improvement is not in the cards, but on balance the rewards outweigh the loses, and this has been the case for many PHP-based software endeavors both closed and open-source as evidenced at how low the churn has been away from using Phabricator. [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:31, 21 April 2014 (UTC)
*: (Wanted to put this below, but I couldn't figure a good place in the other options to put it). I have concerns about the logistics of this migration. I think it might be easiest to transfer via Gerrit, then PM tools (Trello, Mingle, etc), then Bugzilla. The first requires just alignment on developers and actually removes some unnecessary overhead. The second should be staggered on a project-by-project basis over a longer duration as the positives outweigh the negatives (as the teams would have to migrate their existing entries or had specific reasons/features that caused them to use a certain tool). The third probably last as it involves the largest institutional inertia and affected people, however the full benefit won't be seen until Bugzilla is integrated. Not sure if it can be staggered or what the transition looks like, but I do thing while it should be handled right, some compromise on the loss of a couple of data fields should be acceptable (a lot of metadata in Bugzilla is useless/archaeic). [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:32, 21 April 2014 (UTC)
* Strong support for everything in one place. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 21:38, 21 April 2014 (UTC)
* Support for the unification of development in a single place, as someone who has primarily used these tools for looking at what's in development and for reporting bugs. Right now it's a huge pain to navigate Bugzilla and submit things, and the disconnect between Bugzilla and Gerrit is fairly annoying. --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 21:43, 21 April 2014 (UTC)
**Cannot. Agree. More. [[User:MGalloway (WMF)|MGalloway (WMF)]] ([[User talk:MGalloway (WMF)|talk]]) 23:30, 21 April 2014 (UTC)
* Support - Phabricator has come a long way in the past couple of years. What looks awfully promising about it is that they seem to have a coherent vision for providing tools that make development teams productive, and a focus on important things that most tools in this space neglect (user interface, performance, and a sense of humor). From all outward indications, the upstream will be a joy to work with, and the tool is in a programming langauge (PHP) that we have a lot of familiarity with. The migration promises to be a miserable experience (all migrations of this scale are...no matter how great the tool), but this is the first toolset I've seen that looks likely to be worth the pain. -- [[User:RobLa-WMF|RobLa-WMF]] ([[User talk:RobLa-WMF|talk]]) 00:25, 22 April 2014 (UTC)
*This would be awesome. The current mess of tools (especially bugzilla vs trello vs mingle) is quite frustrating for finding whether something is already noted, and has made me not want to enter bugs for myself (especially in Bugzilla with its irritating login requirements). SUL integration would be great if possible. [[User:Jay8g|Jay8g]] ([[User talk:Jay8g|talk]]) 01:27, 22 April 2014 (UTC)
* Strong support: per others, it's always a good idea to have one place for all tasks. [[User:Chmarkine|Chmarkine]] ([[User talk:Chmarkine|talk]]) 03:44, 22 April 2014 (UTC)
* Support - I haven't used dev tools yet, it would be easier to have 1 place to go and start [[User:Aprillion|Aprillion]] ([[User talk:Aprillion|talk]]) 12:17, 22 April 2014 (UTC)
* Support - having all tools in one place can only be a good thing. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:29, 22 April 2014 (UTC)
* Support - Based on what I know so far, I support moving to Phabricator. The top practical problem I face with the current solution is going back and forth between Trello and Bugzilla, but see below for secondary issues. However, we do need to ''ensure'' we're not just adding another tool without replacing/removing anything. This means at least turning off/redirecting/marking read-only Bugzilla and Gerrit. The most realistic way to accomplish that is to do a complete migration of ''at least'' Bugzilla, ideally other issue tracking tools like Trello, Mingle, etc., and possibly others like Gerrit. I've already seen some cool features in Phabricator (e.g. updateable mocks, drag-and-drop file uploading, simple embedding and linking and CCing (oddly, Trello does not allow you to CC other users). It also should allow much tighter integration between Gerrit and Bugzilla (no more getting two Bugzilla emails after you upload a patch to Gerrit, and perhaps auto-fixing bugs based on a commit message tag). Being written in PHP is definitely helpful. It will not magically mean every MediaWiki PHP dev works on Phabricator, but it will hopefully encourage creating a critical mass of collaboration with upstream. I also strongly support using open source infrastructure, so this is a step in the right direction on that front. There will definitely be switching costs and issues, but so far it looks like it will be worth it. [[User:Superm401|Superm401]] - [[User_talk:Superm401|Talk]] 21:38, 22 April 2014 (UTC)
* '''Strong Support''' - There are issues with Phabricator, like any single tool that would be an option (there is no unicorn that covers all use-cases efficiently), but I think it's biggest strength is Evan P and the Phabricator community. His responses to our suggestions/requests have been amazing. And it isn't just us. Other organizations that have migrated to Phabricator have had similar experiences; someone reports an issue that Phab has with their internal work flow, a week later Even P comes back with a fix, before the org (devianArt in this case) could even start working on it. Evan P and the rest of the Phab community is awesome and are an upstream that I want to work with more than pretty much any other. And in the long term, the relationship you have with your upstream is tantamount to pretty much anything else. [[User:Greg (WMF)|Greg (WMF)]] ([[User talk:Greg (WMF)|talk]]) 16:04, 23 April 2014 (UTC)
* Support, even though I have not used other tools (yet) than Bugzilla, but it's always better to have everything at the same place (if possible). --[[User:Stryn|Stryn]] ([[User talk:Stryn|talk]]) 17:58, 23 April 2014 (UTC)
* I have been playing with it for a while and I say '''Let's go get this thing deployed on our servers''' [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 07:36, 24 April 2014 (UTC)
* Support - Yes please -[[User:Fastily|<big>F</big>ASTILY]] [[User talk:Fastily|(TALK)]] 00:13, 25 April 2014 (UTC)
* '''Support''' the pain is real! Copying issues between bugzilla and {team's Project Management tool}, the disjointed concurrent discussion in bugzilla|gerrit|{team's Project Management tool}, the mindless busywork of keeping the state of an issue up-to-date in all three tools, the redundant notifications that this busywork generates, ... A ''fourth'' area that Phabricator integrates is design mockups, an area where the MediaWiki community has never had a good tool. You can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people can comment on it, see http://fab.wmflabs.org/M1/1/ . -- [[User:S Page (WMF)|S Page (WMF)]] ([[User talk:S Page (WMF)|talk]]) 19:36, 25 April 2014 (UTC)
* Support - As someone considering getting into extension development/generally helping out in the next few months, learning to use one tool is much less intimidating than trying to figure out a workflow across five different sites. Phabricator, from my exploration of it, looks nice and intuitve for all the basics.-[[User:Etesp|etesp]] ([[User talk:Etesp|talk]]) 19:41, 25 April 2014 (UTC)
* Yes. However, It should be possible to use Wikimedia/Wikitech account to log in to Phabricator, rather than having an independence system (currently you need to create a new account to Bugzilla). (In the future, I hope Wikitech can be added to [https://noc.wikimedia.org/conf/highlight.php?file=all.dblist all.dblist], so that users can use SUL account to log in WMFlabs, rather then create a new account: current account in Wikitech would be merged to SUL ones.)--[[User:GZWDer|GZWDer]] ([[User talk:GZWDer|talk]]) 12:21, 26 April 2014 (UTC)
* Support - Moving to one integrated toolset seems like a dream come true. --[[User:Lydia Pintscher (WMDE)|Lydia Pintscher (WMDE)]] ([[User talk:Lydia Pintscher (WMDE)|talk]]) 17:41, 27 April 2014 (UTC)

=== In favor of keeping our current tools ===

* I would like to see a rough roadmap of the migration and what task force is going to be allocated to it. I looked a bit around and could not find how we are going to handle the transition. I dont mind changing tools, but I wish we handle it as a proper project or we risk spending a couple years doing the migration on a best effort basis. So until we have a migration plan, I will remain suspicious. [[User:Hashar|Antoine "hashar" Musso]] ([[User talk:Hashar|talk]]) 21:08, 17 April 2014 (UTC)
*: [http://fab.wmflabs.org/project/view/14/ Everything is being tracked] in our test instance itself: [http://fab.wmflabs.org/T37 how to migrate everything], [http://fab.wmflabs.org/T43 what features are currently missing], [http://fab.wmflabs.org/T59 how to configure it] for our needs, even the [http://fab.wmflabs.org/T41 resource planning]. Is this what you were looking for? It's still incomplete, but resources for a migration task force won't be allocated unless this RFC shows explicit support from the technical community. [[user:guillom|guillom]] 14:01, 18 April 2014 (UTC)
* Meh, I hate changing systems which (apparently) work. Though, I don't feel strongly on this issue. [[User:Vogone|Vogone]] [[User talk:Vogone|'''talk''']] 17:37, 18 April 2014 (UTC)
* "The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists" so you want to add one more? But if you show me the way how to force all people to move to the new system I may support. (And no it's not disabling old tools which would just mean loosing usefull stuff of users who would not give up (or wont know how to move) even under such conditions as it's with TS -> Labs move in some way happened) --[[User:Base|Base]] ([[User talk:Base|talk]]) 14:04, 19 April 2014 (UTC)
*: It's not "adding one more" as we are after ''replacing'' systems. Old systems become read-only or disabled, if that's how you interpret "forcing". --[[User:AKlapper (WMF)|AKlapper (WMF)]] ([[User talk:AKlapper (WMF)|talk]]) 07:07, 20 April 2014 (UTC)
*: There is some precedent for "replacing" over "adding" that might mitigate some of the pessism: In 2012, Subversion was replaced with Git/Gerrit. On a per-project level, many teams have migrated between multiple project management tools—bulletin board, Wiki, Bugzilla, Trello. Mingle, and Google Doc—never using more than one concurrently for more than 2 weeks during a transition. Also, the major pain point in PM tools cited is poor integration of those tools with Git and Bugzilla (or general crumminess of management capabilities in the case of Bugzilla), this is especially bad for those who have to navigate multiple tools in the course of their work (notably tech leads, scrum master, and product managers). The multiplicity/redundancy is also the source of much friction because of the lack of responsiveness due people not being on a tool (for instance the devs working from Gerrit, while the bug was in Bugzilla) [[User:Tychay|Tychay]] ([[User talk:Tychay|talk]]) 20:40, 21 April 2014 (UTC)
*It's probably worth integrating MediaWiki with Bugzilla more. Bugzilla has an API. If WMF could also work on making Bugzilla more mobile-friendly and "user-friendly", I'm sure everyone would appreciate it. [[User:Gryllida|Gryllida]] 07:22, 20 April 2014 (UTC)
** We don't use MediaWiki for a project management and issue-tracker, because that's not what it is for. For years, we did code review on-wiki (see [[Special:Code/MediaWiki/status/resolved|examples]]) and it was a nightmare to work with. A wiki is a great tool for documenting things. It's not a code review tool or issue tracker. [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 05:23, 21 April 2014 (UTC)
* 1) I agree with Base, Gryllida. 2) I think Mingle, Trello should be migrated into Bugzilla, not creating new one. [[User:Hym411|—]] [[User talk:Hym411|Revicomplaint?]] 07:28, 20 April 2014 (UTC)
*I don't think any change is required at the moment. Bugzilla, Gerrit, etc. are quite adequate for our current needs. I have never had any problems or concerns with them. The integration between the tools may be a bit hackish at times, but to me, the fact that the current systems are in widespread use and perhaps already familiar to newly-arriving developers is more important. What's more, I don't like Phabricator. It's a rather intimidating web app which looks like it could have a steep learning curve, and could undo some of the good work of people like Quim in attracting new developers to the WMF's projects. [[User:This, that and the other|This, that and the other]] ([[User talk:This, that and the other|talk]]) 09:58, 20 April 2014 (UTC)
**For what is worth, one of the reasons why I support Phabricator is to offer to new contributors a single tool with Wikimedia SUL that fits in the expectations of regular GitHub users. Currently it is painful to send newcomers to Bugzilla and Gerrit in addition to mediawiki.org, while having teams more and more invested in Trello/Mingle (because Bugzilla won't handle the PM work) is a pain for everybody, newcomers included.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:50, 21 April 2014 (UTC)
**Personally, I find having to create accounts for multiple different services with different workflows and having to try to figure out how to use every single one separately is far more difficult than if we were to introduce them to a single service which contains all the development work and bug reports in a single location. That, plus the interface is far better looking ''and'' easier to use than Bugzilla (keep in mind that you're used to Bugzilla, so if you can navigate it easily that's probably why). --[[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 01:50, 22 April 2014 (UTC)
*I'm only commenting on Bugzilla (and slightly RT) here, As i've had limited to no use with the other tools, I don't think think moving will solve any of the "real" issues we currently have, The issue with multiple tools is more due to staffing and cultural issues allowing it to be come so spread out, Whilst some of these tools do have their uses, Some should also be dropped or restricted to very specific use cases, For example RT was introduced because of the security & permissions point of view when needing to deal with outside individuals and a few other small cases it has since basically evolved into a private ops bugtracker with a lot of information that could probably already be in BZ. Also another issue is the maturity and team backing Phab, For example when gerrit was chosen compared to custom writing something like we did with SVN (E:CodeReview) it was decided against because we would land with the same issues about having to maintain the code. [[User:Peachey88|Peachey88]] ([[User talk:Peachey88|talk]]) 08:52, 21 April 2014 (UTC)
** {{u|Peachey88}}, can you explain your last comment? Phabricator is a young project, but they have a significant community and user base that keep gaining momentum, see [https://www.ohloh.net/p/compare?project_0=Bugzilla&project_1=Gerrit+Code+Review&project_2=Phabricator an Ohloh comparison with Bugzilla and Gerrit], and [[w:Phabricator#Users]].--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 23:40, 22 April 2014 (UTC)
*I think the overhead of migrating and learning the new interface is not worth the effort. Bugzilla works fine for most of what we do. The interface also looks a bit scary to me, although Bugzilla's interface is not completely obvious either. Bugzilla is also used for more free software projects and thus has been proven to work in practice. Basically echoing Revi and TTO's concerns as well. As Multichill mentioned, we don't want to add [https://xkcd.com/927/ another competing standard] for teams to choose from (Trello, Mingle, ...) [[User:PiRSquared17|πr2]] ([[User talk:PiRSquared17|''t'']] • [[Special:Contributions/PiRSquared17|''c'']]) 21:43, 22 April 2014 (UTC)
** This isn't just about replacing Bugzilla. Phabricator lets us consolidate a host of disparate tools (Bugzilla, Gerrit, git.wikimedia.org, others) in to one view of work on MediaWiki. What's more: Bugzilla is clearly not working for Wikimedia Foundation developers, who are doing a large bulk of the work that is tracked in Bugzilla. This is obviously the case when you consider that nearly all teams are using a secondary project management tool on top of Bugzilla, and may even disregard Bugzilla as the canonical list of bugs/issues with a component, because it's such a mess. This doesn't even begin to touch how unfriendly Bugzilla is to non-developers who we want to report issues... [[User:Steven (WMF)|Steven Walling (WMF)]] • [[User talk:Steven (WMF)|talk]] 21:09, 23 April 2014 (UTC)
* As long as we do not force people to switch to only Phabricator (and forcing would be bad), we'll not reach the desired consolidation of tools, but just add another tool to the set of tools the different teams use. For me, bugzilla and gerrit both have their issues, but they get the job done sufficiently well. Of the many open bugs in our Phabricator, Phabricator's requirement to use "arc" instead of plain git to fetch/push commits bothers me the most. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 22:52, 23 April 2014 (UTC)
** {{u|QChris}}, reply from maintainer epriestley at #phabricator: ''"everything works fine without arc | you get more features and stuff with it, people mostly seem pretty happy about them | but it's absolutely not required | If some of the documentation was misleading in that respect, let me know and I'll fix it."''--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 21:41, 24 April 2014 (UTC)
*** {{u|Qgil}}, I followed up with epriestly. Without arc, you're expected to 'git diff' and copy/paste that in the web UI. That's not a "works fine" for me :-) First, it's really, really inconvenient. And then you'll loose commit metadata that way. Like committer, author, and most important: parent of a commit. But Phabricator does not value this kind of metadata much anyways. For example "arc patch/land" does not honor them either (see upstream ticket [https://secure.phabricator.com/T4333 T4333]). Also, merging a patch is not possible nicely without arc. You have to merge in your repo locally, and then push directly to the branch to bypass review. --[[User:QChris|QChris]] ([[User talk:QChris|talk]]) 00:04, 25 April 2014 (UTC)

=== Basically neutral ===
* Personally, with the current test installation (microscopic fonts, functions [http://fab.wmflabs.org/T119 hidden behind unlabeled icons], other icons not clickable, tendency to feature bloat, some features like [http://fab.wmflabs.org/T150 voting missing], other features like Gerrit and GitHub integration not testable at the moment) I can't decide if it's worth my time. It could be the greatest thing on earth or turn into a bottomless pit. A project that starts with ''"We can't manage 12 tools! We need to do something!"'' could also end with ''"Now we have 13 tools."'' --[[User:Thiemo Mättig (WMDE)|Thiemo Mättig (WMDE)]] 14:14, 17 April 2014 (UTC)
* I am in favor of trying out Phabricator for a few select projects so we get a better idea of what moving over all projects would mean --[[User:Jeroen De Dauw|Jeroen De Dauw]] ([[User talk:Jeroen De Dauw|talk]]) 19:09, 17 April 2014 (UTC)
* I gave it a try, very stressful so far (I hope not to touch it for a few weeks now, I'll need some discipline). Will need huge amounts of help to figure out, if we really want to kill bugzilla: I expect at least a couple hundreds more bugs need to be filed and triaged, please help with testing. My results so far are visible at [http://fab.wmflabs.org/p/Nemo_bis/] (only partly and only after login, try the [http://fab.wmflabs.org/search/query/advanced/ search]). --[[User:Nemo_bis|Nemo]] 19:10, 19 April 2014 (UTC)
* I'm not convinced that the time invested in changing our code review tool (again) is worth the expected benefits. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 07:40, 20 April 2014 (UTC)
* IM kinda HO we gotta change default avatar on our demo, it's unacceptable for me to use [[w:Psyduck|an NFC image]] as it... --[[User:Liuxinyu970226|Liuxinyu970226]] ([[User talk:Liuxinyu970226|talk]]) 10:15, 20 April 2014 (UTC)
* I share Legoktm's and Thiemo's concerns, but I also see the problem with our current (overwhelmingly) large tool stack. The most important thing over here is to really make the cut on the n tools we have atm and to not have n+1 tools after. - [[User:Hoo man|Hoo man]] ([[User talk:Hoo man|talk]]) 11:45, 20 April 2014 (UTC)
* I'm basically neutral but I couldn't agree more with Antoine: If we're going to change, it should be done with a proper project. When I talk about a project, I'm talking about a project as defined [[:en:PRINCE2|here]]. Clear goal, clear time path, clear budget etc. I'm a bit afraid [https://xkcd.com/927/ this] is going to happen. [[User:Multichill|Multichill]] ([[User talk:Multichill|talk]]) 15:23, 20 April 2014 (UTC)
* I dont mind, I am not a developer. If you think you need it. Do it. But do it once. It take us some time, to get in touch with bugzilla. So we will need some time to get in touch with the new sw. ('''errr, where I have a singnature button in Visual Editor?) '''[[user:Juandev|Juandev]]
* A new system could be nice, I don't really care either way. But we want to make sure users will not be suddenly surprised by this.--[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:18, 21 April 2014 (UTC)
* I largely agree with Multichill, et al. Some specific team (whether that's a Wikimedia Foundation team or a Wikimedia chapter team or a coalition of volunteers) has to take charge of this and properly migrate the current suite of tools to Phabricator. This will be tedious and long and annoying.As long as whatever new tool is implemented has IRC feeds, I'm pretty neutral on the topic. I will say that in my limited interaction with Phabricator, it seems to go out of its way to be gimmicky and obnoxious. I'm wondering if that's a configurable mode. It might be nice to enable rotating cutesy submit buttons and "stickers" in a year or two, but for now, the transition will be difficult enough without Phabricator constantly dressed in a clown costume. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 00:31, 21 April 2014 (UTC)
**The silly names have been turned off already - it's now in "serious business" mode (instead of "fun mode"). Discussion at http://fab.wmflabs.org/T119 –[[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 22:22, 21 April 2014 (UTC)
*On the one hand, Phabricator is one unified system which will therefore likely reduce the work we need to keep so many separate systems going. On the other hand, it's unclear to me what cost the migration will have, and how much time it will take learning a new system. Without having more data to figure out whether the pluses overcome the minuses, I am basically neutral. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 15:44, 21 April 2014 (UTC)
* I now support this proposal, here is my former opinion: This discussion would be far more simple if we point out the biggest improvements and potential bigest issues that migration would do, so please fill up this list with that is in your mind. I am not really againsted Phabricator, but I really do like bugzilla, as that is one of best open source bug trackers and saying just "let's have 1 tool for everything" is not much of argument to me :) For this reason I created new section with pros cons. [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:48, 21 April 2014 (UTC)
*:Which tools are we actually talking about is it just bugzilla and gerrit that would be unified or is there more of them? [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 16:51, 21 April 2014 (UTC)
*::The other dimension is project management tools. This includes Mingle and Trello which are actively in use in the WMF, which would also be replaced by Phabricator. People at the WMF have written scripts to actively copy Bugzilla bugs into Mingle and Trello, but these scripts occasionally need maintenance. So, Bugzilla and Gerrit are the big ones most people know about, but there are others. --[[User:DGarry (WMF)|Dan Garry, Wikimedia Foundation]] ([[User talk:DGarry (WMF)|talk]]) 17:19, 21 April 2014 (UTC)
*:Most impressive part I found is that it allows regular users to create own repositories. This however needs to be enabled. Would this be enabled on production version of phabricator? I am not using our gerrit only because I have to wait weeks or months for repositories to be created and that suck. Primary reason I stick with github is this feature (being able to create new repo in 10 seconds) [[User:Petrb|Petrb]] ([[User talk:Petrb|talk]]) 09:20, 22 April 2014 (UTC)
* I'm neutral to the debate of using Phabricator over Bugzilla and Gerrit. However for the management of Features (user stories) and their workflows using Agile Scrum methodology, I prefer Trello. It is possible to adapt a Phabricator Workboard to suit product management, however I recommend creating a separate project for product Features so your Workboard does not get overrun with the sight of new bugs and subtasks. One more reason I prefer Trello over Phabricator is this issue: http://fab.wmflabs.org/T195 {{unsigned|KLeduc (WMF)|15:52, 22 April 2014‎ (UTC)}}
**Being Trello a proprietary service, and requiring users to register in a 3rd party server to participate, there is no way Trello (and Mingle) will fit in the Wikimedia context in the long term. They are ok-ish short term solutions because our teams didn't find better tools. T195 can be fixed customizing the CSS; community division and WMF teams planning elsewhere are much bigger problems.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 18:43, 22 April 2014 (UTC)
* As an occasional tech, I am happy with Bugzilla, I don’t use Trello/Mingle/RT, and I "invested" time to learn Gerrit (and Git) more than one year after Gerrit was installed in production because I had no time before, so a bit sad if these leave. On the other side, I understand WMF developers want a more integrated tool for easier project management. Anyway, if Phabricator (or another tool) is used, please use it at least 5 years to let time to community members to learn it and become accustomed to. ~ [[User:Seb35|Seb35]] [[User talk:Seb35|[^_^]]] 23:17, 22 April 2014 (UTC)
* As someone that has dealt numerous times with Mingle SoS cards linked to a Bugzilla forwarded to an RT ticket, I'm excited about the prospect of a unified bugtracker, even in the case where I'd have to sacrifice useful functionality that each of these tools provides to me. I'd be hugely in favor of this, but: I'm a lot more worried about Phabricator's code review system and git integration, especially in regards with traditional git workflows (Gerrit is pretty bad in this aspect, but the arc workflow seems even worse, see e.g. the commits messages in Phabricator's own repository). It seems to me that the evaluation so far has been mostly on the issue tracker functionality; it might make sense as a first step, but now we're being asked for our opinion on a proposal to replace our code review system as well, and I don't feel sufficiently informed about that. [[User:Faidon Liambotis (WMF)|Faidon Liambotis (WMF)]] ([[User talk:Faidon Liambotis (WMF)|talk]]) 00:37, 25 April 2014 (UTC)
** {{u|Faidon Liambotis (WMF)}}, {{u|QChris}} is testing the area of code contributions and reviews, and he creating tasks under [http://fab.wmflabs.org/T47 Identify features Gerrit users would miss in Phabricator]. The attention of other users with experience in Git/Gerrit is welcome. Phabricator brings indeed a different paradigm that seems to be working for some organizations, but would it work for us? If not, is it a matter of features missing or is there something deeper? I agree that this needs further investigation and discussion.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:35, 27 April 2014 (UTC)
* I believe that a single integrated system is absolutely a good idea. The sheer number of tools being used simultaneously at present is bewildering (RT is involved somewhere as well?!). However the comments on display here lead me to feel that Phabricator appears to require a little more work before it's quite ready. I have two other concerns: firstly, there needs to be an assurance that after the change Bugzilla will be maintained in read-only mode forever; it has a decade's worth of incoming links that shouldn't be broken. Secondly, when Bugzilla bugs are imported, will their entire comment history be imported as well? I think that it should. The discussions associated with bugs are by far the most important aspect of the whole thing. If dealing with a bug in the new system requires having to scoot back to Bugzilla to pick up on all the context and/or previous decisions, that messes up the point of only having a single bugtracker. — [[User:Scott|'''Scott''']] • [[User talk:Scott|''talk'']] 13:14, 27 April 2014 (UTC)
** Yes {{u|Scott}}, [http://fab.wmflabs.org/T55 RT is part of the plan]. [http://fab.wmflabs.org/T65 Redirects of Bugzilla URls to Phabricator] are also planned and, yes, we are talking about importing all reports including the comments. There should be no need to keep the Bugzilla instance available forever, but we can allow ourselves as much time as needed. You can check and discuss the details at [http://fab.wmflabs.org/T39 http://fab.wmflabs.org/T39]. "Phabricator appears to require a little more work before it's quite ready", maybe, you can help defining exactly what needs to be done before the migration, see [http://fab.wmflabs.org/T43 Define what features existing in our current tools are really missing in Phabricator] and dependent tasks.--[[User:Qgil|Qgil]] ([[User talk:Qgil|talk]]) 15:29, 27 April 2014 (UTC)
* Jeroen De Dauw could be my spokeperson. — [[User:Danny B.|Danny B.]] 15:40, 27 April 2014 (UTC)

== Pros / Cons ==
''For a specific comparison with Bugzilla, see [[Requests for comment/Phabricator/versus Bugzilla]]''
=== Pros (improvements) ===
* '''Everything would be in one place'''
** Single login for everything (''Can we integrate Phabricator and SUL?'' That would be cool. See [http://fab.wmflabs.org/T40 Pick an authentication provider].)
** Better integration of subsystems like bug tracker, git etc
** Single interface with no need to switch between differently looking, possibly confusing other interfaces of other instruments (like buzilla, gerrit etc).
** Integrates design and designers. Phabricator organizes design mockups and feedback in the same tool as code; you can upload an image into Phabricator's [http://fab.wmflabs.org/pholio/ pholio] system and people [http://fab.wmflabs.org/M1/1 can comment on it].
** Responsivity and communication will be improved (currently a lot of issues brought up in one tool are missed in the other. i.e. a bug in Bugzilla is not addressed because the PM is working on a management tool, even after addressed the bug is not closed after the patch is reviewed and committed in Gerrit, there is no evidence that work is being done in Bugzilla even though there may be a lot of activity in Git or the management tool regarding that specific bug).
** Integrations between tools (e.g. Bugzilla to Mingle) is done ad-hoc and usually on a per-project basis because there is no return to scale to do this across others as they use different tools for certain key parts.
** Prioritization in bugzilla has no roadmap burn-down to why it is or isn't being worked on by those involved in a project (ScrumBugz into Bugzilla would solve it, but only if projects move to it).
* '''Faster reviewing of code''' (especially large diffs), and '''improved commit/review procedures'''
** Multi-commit single-branch review support instead of the approach in gerrit where each change is a single commit that is amended for each new patch set
* Support for '''code auditing''', with automatic notification based on rules and conditions
* '''Written in PHP''', so it's more '''easily extensible'''
** Already a deep knowledge on PHP due to it being the language of MediaWiki expertise
** Gerrit is in Java, Bugzilla is in Perl, most PM tools are closed-source and hosted on commercial sites with integration being their own unique APIs, neither has a large developer footprint in the community
** Deep integration between Phabricator (issue tracking, project/task management, and commits) and Wiki becomes a real possibility again (something we lost when we moved away from CodeReview).
* '''Mobile-friendly'''. Login from any mobile device and see what you can read and do. Now, open Bugzilla and Gerrit...
* Tasks can be assigned to more than one project. Projects can be easily as if they were keywords. No more discussions about products / components taxonomy, no more fights to decide where a bug should be filed. See [http://fab.wmflabs.org/T68 How to organize projects].
* '''Respects privacy more'''. Bugzilla and Gerrit expose your email address. Phabricator does not.
* '''Better developer tools''', specifically [https://secure.phabricator.com/book/phabricator/article/arcanist/ Arc], the command line interface to Phabricator. This means we would no longer we dependent on git-review or [http://www.gossamer-threads.com/lists/wiki/wikitech/419135 hacking together] our own tools.
* Possibility to let users create their own repositories. See [http://fab.wmflabs.org/T196 Enabling creation of repositories by regular users?]

=== Cons (potential issues) ===
* There will be a '''learning curve''' in switching to new software
* See [http://fab.wmflabs.org/T46 features Bugzilla users would miss in Phabricator]
* See [http://fab.wmflabs.org/T45 features Trello users would miss in Phabricator]
* [[:w:SPOF|'''SPOF''']] - if Phabricator breaks, everything breaks. Bug trackers should be highly available. How would you report a ticket that there is a problem with Phabricator when it is a bug tracker on its own? There will be maintenance of Phabricator and they will shut down everything. So impact of every maintenance / outage will be significantly higher than now.
* Have all the issues with [[Git/Gerrit evaluation|our previous evaluation with Git/Gerrit]] been addressed?
* No dedicated mobile application, only accessible via web. Therefore no push notifications, etc. Mobile support is better than Gerrit and Bugzilla, but not Trello (which has its own app).