- 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.
|This page uses the Flow extension, a new piece of discussion and collaboration software. We need your feedback at Talk:Flow or en:WT:Flow (not on this page, please!) over the coming months, to help make it the system we all want to use. Please do random testing at Talk:Sandbox. See the Main FAQ and the Design FAQ for some basic details and answers, and a list of future feature ideas that have been suggested so far.|
Previous discussion is archived at Talk:Winter/Archive 1.
Search bar inconsistent wording
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.
Infoboxes that are longer than the article text
In many shorter articles such as this one, the infobox is longer than the article text. The gray bar at the bottom of the page still appears at the end of the article text, though, so it obscures part of the infobox.
Navboxes and categories
Are these being removed? Michigan State Trunkline Highway System should have a navbox below the items in the bulleted list in the External links section, yet the box is missing.
Also, how are categories going to be displayed since they don't appear at the bottom of the articles.
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.
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.
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.
Seconding the monospace font for the edit box. Editing in a proportional font is painful.
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.
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.
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.
Is Winter not in BetaFeatures anymore?
Winter is apart of VectorBeta and not BetaFeatures.
I just did a copy of BetaFeatures master branch and found out that I couldn't enable Winter by adding $wgVectorBetaWinter = true;. I also noticed that all the documentation about the beta features included in BetaFeatures were removed from Extension:BetaFeatures. When was this changed and what can I do to get back Winter?
I would also like to see this in beta features.
Thought I already left such request somewhere. Don't see it.
I forgot that it wasn't in BetaFeatures. It's in VectorBeta but registers with BetaFeatures.
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?
And can we please stop closing topics aggressively? Topics need to stay open, unless inactive (for instance, for a week).
No past discussion system locked topics like this. It should not even be technically possible.
Most users will be unable to even re-open the topic, the button is not easy to find.
(I would be happy to dedicate a sub-topic to this question, but this system doesn't let me make subsections here with the expected consequences (a separate discussion, etc). Filed bug bug 69383. about subsections.)
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.
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.
The File namespace (formerly "Problems following files with an !")
I went to the page http://unicorn.wmflabs.org/winter/index.html?page=Blanc_de_Hotot and tried to click on the image. Instead of opening up the image in a new page, as clicking on images had done with other images, clicking on that image gave me a 404 error. I think it might be because the ! threw something off. Not sure if this is a Winter error or a Labs error.
Sven Manguard: It's actually the File: namespace. I haven't built in support for handling File:urls. The API is fairly opaque with regards to those.
Jorm (WMF): 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.
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.