Talk:Winter

Jump to: navigation, search

Previous discussion is archived at Talk:Winter/Archive 1.

 
Newest topics

Release

Reply • 7 comments •
7
JKDwtalk contribs

Roughly when is Winter expected to be released as a beta feature and as the default skin?

Jdforrester (WMF)talk contribs

I don't know. I don't think there are any current plans for anyone to do that work, sorry.

Quiddity (WMF)talk contribs

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.

JKDwtalk contribs

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.

Quiddity (WMF)talk contribs

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.

Tar Lócesiliontalk contribs

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.

Quiddity (WMF)talk contribs

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.

Reply to "Release"

Large tables

Reply • 2 comments •
2
Zebulon84talk contribs

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 this one or that one.

RandomDSdeveltalk contribs

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.

Reply to "Large tables"

Fixed header on Beta Labs

Reply • 1 comment •
1
Ragesosstalk contribs

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

Reply to "Fixed header on Beta Labs"

Prototype

Reply • 3 comments •
3
PJosepherumtalk contribs

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.

Jorm (WMF)talk contribs

Quim is correct; the prototype is MediaWiki-less. Pure HTML/CSS and JavaScript.

Qgil-WMFtalk contribs

As far as I know, this is a MediaWiki-less prototype, floating on raw HTML/CSS/JS.

Reply to "Prototype"

On the Location of Articles' Tables of Contents

Reply • 1 comment •
1
RandomDSdeveltalk contribs

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?

Reply to "On the Location of Articles' Tables of Contents"

Improved or Different Header Views?

Reply • 1 comment •
1
RandomDSdeveltalk contribs

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…

Reply to "Improved or Different Header Views?"

On the Behavior of Wikipedia's Logo in Winter

Reply • 7 comments •
7
RandomDSdeveltalk contribs

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?

Jdforrester (WMF)talk contribs

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.

RandomDSdeveltalk contribs

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?

Jdforrester (WMF)talk contribs

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.

RandomDSdeveltalk contribs

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…

Jdforrester (WMF)talk contribs

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. :-(

RandomDSdeveltalk contribs

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!

Reply to "On the Behavior of Wikipedia's Logo in Winter"

Weird Sidebar Behavior

Reply • 1 comment •
1
RandomDSdeveltalk contribs

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?

Reply to "Weird Sidebar Behavior"

Have you seen WikiWand?

Reply • 2 comments •
2
Sonitalk contribs

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.

Tar Lócesiliontalk contribs

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

Reply to "Have you seen WikiWand?"

First impressions

Reply • 5 comments •
5
Diego Moyatalk contribs

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.

Diego Moyatalk contribs

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.

Jorm (WMF)talk contribs

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.

Jorm (WMF)talk contribs

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.

Diego Moyatalk contribs

Yes, I was referring to those buttons. They appear as plain text 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...")

Reply to "First impressions"