Talk:Reading/Web/Desktop Improvements/Repository/First Prototype Feedback Report

Thanks you for keeping us informed. I'm very interested by the other feature ideas too.

I have a few questions regarding the mock-up with the ToC proposal though. Wouldn't it make harder to implement later specific options for media/figures and tables types of Table of Contents?

I also came up with a few suggestions for improving the "permanent" ToC idea:

• OOUI icon for ToC added around the "Title+section" title group, looking like the one used for the Wikipedia app on Android
• Expanded ToC column located at the opposite side of the toolbar (apologies for mistakes in the original post; my pc had a very annoying bug that forced me to publish a draft before a complete reboot)

I was glad to see the idea of adding a night mode in the report. I had looked into hacks to turn wikipedia to something like night mode, but didn't like the results, so I realize setting this up wouldn't be trivial. If it was available I would likely switch to it, though. I would especially like if it was available in the mobile view as well. When I read on my phone at night and then use the right-click lookup for a word, having wikipedia pop up in all its brightness is jarring.

These aging eyes would also like to see a night mode.

You might be interested in the Dark theme I've made this winter.

(This was supposed to be a longer post, but the Flow dingo ate my baby, going to keep this short.)

1. How will proposed language switcher look at the main pages, where there is no first heading? Will the old menu still be available to users without JavaScript enabled (that is interesting to me because I would, in all likelihood, want to disable this interface for myself even when I browse anonymously)?
2. Why are the designers thinking that hiding sidebar behind a button has any possibility of not harming the clickthrough rate of the sidebar items? That contradicts all available research and the basic common sense (since you require more actions to get to those links, it is only natural that less people would take them). If the links featured in sidebars are considered non-essential for any readers, the WMF should just put it bluntly instead of saying that this will be tested with A/B tests.
3. The idea to replace already non-recognisable (for less proficient Internet users) hamburger icon with even less recognisable icons is rather strange. If anything, the knowledge that hamburger icon is non-recognisable should trigger research into how to make existing navigation more helpful without hiding it, not into replacing with even more obscure icons.

I am glad to hear that fixed width was supposed to be for everyone, not just for readers. I also think that that is the most controversial part of the proposal for the regular editors (but not for me).

Also, even after reading the report, I still have to say that all the provided prototypes look worse and more unappealing even than the existing Vector skin, and I hope that this would be mitigated by the time these improvements would start to be developed.

Hey @Stjn, I'd like to dig a bit into the fixed width issue. I'm just collecting feedback to better understand the perspectives of users who are active on different wikis, it's not "officially, in the name of the team" style.

On my both accounts, I've got like 90.000 edits, and I'm kinda a regular editor, and I'm still not sure why fixed width is that much of an issue? Could you please elaborate on this? I mean, ok, main pages, portals, community portals, village pumps, all not-article-like but portal-like pages where the design is of primary importance, that's one thing for sure. What else comes to your mind?

It’s not an issue for me, but I’ve heard sometimes from editors in design-related discussions that they prefer to read articles on their full page widths, probably because of familiarity bias. But I would say that for those people that care about this, the look of articles they have written probably matters a lot more than the look of portal pages and main pages.

When we’ve introduced responsive references in Russian Wikipedia, some people complained about 10 reference limit, even if you explain to them that the old way of doing things (with fixed number of columns) provided issues for users with different screen size. So that kind of resentment, ‘I have made it look beautiful for myself and you ruined it’, might definitely be present when implementing this.

@SGrabarczuk (WMF) The biggest issue with fixed width appears when using high resolution monitors. For example, my usual desktop screen is 1920 pixels wide, so the current proposal to limit the width to 1000 pixels means the content only fills up about half the page. In practice, I find reading ~250 characters per line is preferable on a large screen. The main benefit of long lines is that it significantly reduces scrolling, and makes it easier to find where you are in a page. As the report mentions, this is longer than the current design trends on many websites. However, while such long lines would be very unwelcome applied across the board,(especially for mobile) allowing the flexibility to read at higher widths is a feature of Wikipedia I think is worth preserving.

I still do not understand what the proposed fixed width layout is supposed to help. It does not seem to make sense, at least not for desktop users. If I find a text block too wide or too narrow for comfortable reading, I simply change the width of my browser window. Problem solved. Hence I also do not see a need for a collapsible sidebar except on very small screens, and would much appreciate an option in the user preferences to switch to a permanently visible sidebar with the current "look and feel". Also, in more than 10 years of using Wikipedia I kind of got used to where the links are that I need for navigating and editing, and would find it very inconvenient if I could not access them any more on a single mouse click.

I oppose all the listed changes (with maybe one exception*). They will probably make me leave Wikipedia once and for all. I am not joking.

Fixed-width text in the centre will make my eyes bleed. I cannot read Wikipedia if I hate every second of it.

But my opinion is not welcome, obviously. For one, I cannot understand this very page I am writing on. I do not understand these disgusting pictograms... Now I'm clicking on one, and... you have hidden bold/italic under a button? Seriously? What an utter, horrific disgrace.

This is all disgusting mobile abomination. I have no other words. Is it Material design? Or is it Flow, as another user said? I hope, there will be add-ons/extensions for browsers to fix it like with YouTube or Reddit, otherwise, I will leave this botched surgery.

An unneeded botched surgery, to be exact. https://web.archive.org/web/20050424075922/https://en.wikipedia.org/wiki/Tea It has existed for 18 years in pristine condition], but now you just said, "I guess, I'll die".

I do not understand why you would butcher Wikipedia.

ASTERISK The random page button would be neat, mimics a real book (if it existed already, I never knew, so making it more prominent is a boon).

(Yes, I wanted to place an asterisk, but I cannot because of this god-awful design.)

P.S. When I press ctrl+F, I get even more buttons! Is this a browser game? Do you even know what menus are? They are supposed to stay on screen, not jump around...

Language switching:

• Idea of grouping together the different language options and new location of the button are great. It cuts down on clutter, and makes good design sense.
• I personally prefer the alphabetical list over the languages by region. The grouping is not what I expected (my initial expectation was by continent, so the regions we get are kind of of strange) However, I can see how some might prefer it, so it should be up to which format is more intuitive for people overall.
• The drop down box is far too small. If you've got a large screen, it should take better advantage of the space and fit more languages without scrolling.
• I don't have a strong preference about the button size/style.

Sidebar collapsing:

• A good idea. I think the best thing would be to cut down on the number of items crammed in the sidebar, but I realize that's outside scope here.
• I think the location in the upper left is fine.

Fixed width:

• I think there are some serious problems with setting a fixed width pixel count for higher resolutions, as I've described elsewhere on this page.
• I don't understand why establishing a common reading experience is emphasized. Rather than have editors fine-tune the layout of the page to a fixed standard, I think the best approach is to have the layout generated dynamically. That way the content is easier to adapt to different presentation styles, and less brittle as both the content and people's needs inevitably change.
• In reading through the report a second time, I find that I share some of the concerns that were raised in a previous discussion. Talk:Typography_refresh/Archive_2#max-width:_715px The prototype has improved since that point,(particularly in increasing the fixed width from 715px to ~1000px) but the central concern about too much white-space is still there.

Other ideas:

• Night mode is fine. I don't think this is very important, but it might be fun.
• Table of contents/sticky header. It might be interesting to integrate these two. (i.e. if you click on the header, it allows you to jump to particular sections. Would be interesting to see a prototype here.
• Top bar cleanup. This is a great idea. organizing all the info there helps simplify the layout. I think dark mode might be better placed as an option in preferences, rather than directly in this dropdown.

I've been asked by someone on the Frenchou wikipedia to read the report and give my opinion. So uhh... Here it is. I found some contradictions, within the document itself and my own mini-report. So, may I cross-examine the documents and hurl an "OBJECTION" everytime I find a discrepancy? Gently of course!

Overall report structure

• Lots of feedback apparently. Shou'd give you a good sight of what's to do.
• Things are quite clear and detailed, at least for me. Well, aside from the fixed-width content, but I explain later.
• Should explain what A/B tests are. I know that it's just splitting your users on two project variants and watch reactions, but for most it's probably babelebe... Barbili... Babblering.
• Without the post on my talk page, I would have never gone there. And I can't findy my way there manually too! And sadly, that's not the first time it's happening.

Language switcheroo (dadidoo)

• OBJECTION, your honor (:p)! I did have issues finding the language switcher button in the first place. My experience is somewhat contradictory with the report. Somewhat because you say that it is in "overall".
• OBJECTION! You show 4 types of language switcher buttons, sorted from most visible (left) to least visible (right). However, I find the second, blue one less visible than the third or fourth one. Blue has less contrast than black on white!
• Also, going for the visibility options, don't overlook your standards in color and imagey options. If I was to choose based on these, I would take the buttony one (the left-most). Others are whether not clickable or links.
• I seem angry about the language switcher, but I'm not :p. It's just I say too much "objections".
• I prefer 2 clean and clever clicks than one click in a big mess in a mess hall. It reduces the side-bar size, so it can only be better. I guess.

Side bar gone sideways

• I will join the team "Do not collapse by default for logged-out users" for about the same reasons explained. I did had issues with the fact it's not collapsed by default, but because it was a burger-like icon, not because it wasn't collapsed.
• On the report there's two alternate views. In the current state, choose the right one, where the text don't move. because the text doesn't move.
  • First, moving and resizing the article zone may causey issues with text/image location.
  • Second, and as I told in my feedbacks, it really gives motion sickness. Just look at the gif for 15s, you will feel on a boat during a hurricane.
  • Then, it's simpler if it doesn't move.
• A useless bulletpoint to shoot some interest back into you, reader! Keep going!

The "so-so understood" fixed-width

• I don't think I understood what the work is really about. I know about UI/UX, responsiveness and such, but what fixed-width is compared to? Yes, it's relative-width, but I mean concretely, what should I see when it's fixed or relative?
• OBJECTION! The two pictures displaying the difference in length size on the moon article should display the same part of the text. Right now, it is impossible to make any insightful opinion when the top of the article is shown up along with the infobox for one, while the other has the full article!
• If the length is 500px or whatever, wouldn't it cause problems when people are on 3940x2048ish resolution? Like having only a tiny quarter of the screen used }i{ ?
• On your "educated guess" saying that "there are two common experiences we might want to anchor around", don't forget the moment when pictures are there, which is also quite here. It's quite similar to infoboxes, but it's still different, ainatit x)?

Wikipedia joining the dark side

• People love being "darky" and all night. I don't feel exactly the same (I don't really care :p), but it'll make a lot of people happy, that I'm sure.
• Just be careful that the theme offers about the same useable color-space for text and images. We don't wanna change every color because everything went black ;p.

Table of contents content without contempt everywhere

• Yes! Good idea! Give lots of cookies to people who thought this! No wait! I want some too }i{ !
• I just hope that it doesn't take the whole page all the time x_x. So maybe an openable table of content. Where? Uh... Somewhere.

Side notes

• "Cleaning up the top bar". One word (now five) : Nicey!
• "Logo is too small". A bit short of explanations (ran out of web ink :p?), but yes, good point.

Mixing metaphors ... I second the motion! Well, some of Tortliena's motions at least. :) I love your sense of humor Tortliena. I agree with the following:

• explain what A/B tests are
• moving and resizing the article zone may causey issues with text/image location - important to test if this is a problem (as it certainly could be)
• If the length is 500px or whatever, wouldn't it cause problems when people are on 3940x2048ish resolution? Like having only a tiny quarter of the screen used - screen resolution, page display choices, and a bunch of related stuff I don't understand seems to be a perennial problem, so it will be important to explain—and show—how pages will look on different platforms, monitor sizes, screen resolutions, etc. (how to show those differences is another challenge)
• Just be careful that the theme offers about the same useable color-space for text and images. - Excellent point!
• So maybe an openable table of content. Where? Uh... Somewhere.
• "Logo is too small" - vandal edit? If not, I have no idea what it means.

Just as a side note, before any design-related concerns are addressed:

bon, @Tortliena, thanks for calling me "someone"! :P I'm Szymon and I also believe we should improve our communication. We'll do!

@SGrabarczuk (WMF) Oui! C'était d'toi que j'voulais parler!

@Markworthen Thanky thank you! Making someone beams puts a beam on my face. Uh well, a roundy one, like a upward one and less straight and woody. Though... To be honest, I just let my thoughts flow a bit like sparkling dust in a clearing. Lot nicer than dust on a sad old book that was never opened. Hence the metaphors, I guess? Oh, gotta open and read all books now!

First UGH for making feedback for this be in FLOW :(

The mockups such as File:Moon article at 550px wide.png look horrible on desktop, keep in mind that screen size could be anything, and even lower resolution screens might be used in a large format such as a projection. Having almost half of the viewport devoid of content is a huge waste.

I disagree. I have a 24" monitor and I have to resize my browser window to half, to be able to read without moving my whole head left and right. Even worse with tables with a couple of columns but set to 100% width... The above mockup indeed looks horrible but File:03_-_DIP_-_Collapsible_sidebar_(closed).png seems good.

I like the fixed width. It looks great on my 5-year-old desktop and medium size monitor.

One-Click Language Switching - I approve of using user behaviour to drive certain language links, but would also recommend including the option for a user to manually set their own language preferences, up to the maximum number of one-click links available.

ULS Prominence - Options A, C and D are fine. Recommend against option B as many users will expect a blue link on white background to take them to another page, which may make them reticent to click.

Random button - Really like the idea of putting this next to the search bar! A prominent and appropriate place for a function much-loved among all user types.

Collapsible Sidebar - if all the ideas in this first prototype are deployed and someone does a gadget to add What Links Here and Wikidata Item to the top page tabs, then personally I may never need open the sidebar again!

Fixed-Width Layout - I'm less convinced on this change than the others. Specifically as much of the literature and data mentioned is reader-oriented yet the changes are intended to apply to editing too. Worth considering if editing constitutes a separate use case from reading in terms of optimum line length. I believe this aspect of the project has the greatest potential for negative user outcomes, so I would consider providing a preference for users to override this option and set their own line-length limits, which may mitigate bad outcomes on unusual display settings (such as the 5120 x 2880 user writing here).

Other Feedback Ideas - All of these are good ideas. Personal experience tells me to always avoid scope-creep. These ideas should not be forgotten though.

ULS as a topic translator - Had a discussion with a friend and there is potentially one user behaviour that has not yet been considered - hovering over language links in order to see a translation of the current article title. I would suggest to maintain such hover-over behaviour in the new language menu, but perhaps a better solution would be to make the target article names immediately visible in the ULS - that new functionality may drive new behaviour and increased interaction if more monolingual users appreciate seeing the name of a topic in multiple languages on this menu, but don't want to click through to articles they don't have the ability to read in full. This kind of hidden user behaviour could be identified by checking if many users click multiple language links of an article in short bursts.

Also - I commend you on the work thus far. This has been a good experience from design to elicitation of, and response to, feedback. :)

I don't understand what we are supposed to write in this "Feedback round 2" field. Aren't all the sections above for feedback? How is "Feedback round 2" different?

It's no longer our initial impression when using the first prototype, but our extended thoughts and feedback concerning the posted changes and reactions to the feedback round 1

This is a thread of my feedback, I've changed the title to make that clear. The team are soliciting feedback on the prototype. I guess this has just shown that the talk page format isn't the most clear way of doing that :D

I personally prefer option D.

Where are these options?

https://commons.wikimedia.org/wiki/File:Showing_four_treatments_for_the_interlanguage_links_menu.png

Thank you!

Regarding one-click language switching, practically is not an option even with the present design. With compact language switch (Universal Language Selector) you almost always have to scroll up or down. The language box is 255px which in the current Moon article in a 1920x1200 resolution is 1% of the screen height. Since most expert Wikipedians will have a lot of other links on the sidebar (f.e. through gadgets) the language switch is almost never visible above the fold. So, we already need more clicks and mouse wheel rolling to get to the languages box. One more link is not a deal since it does not cost another page loading.

Location is ok. You know that you always need to scroll up or even faster press the [Home] button. In the current design one may have to scroll up or down.

Prominence: yes the box button may be too much. Option B is better. Since it is clickable, stick with the blue color to be consistent with the rest of the ui.

Wrong: People who use Monobook are able to select languages with one click in those projects where the language list is not collapsed (such as en.wp, and unlike pt.wp, e.g.). Tuvalkin (talk) 21:32, 8 April 2020 (UTC)

First of all it is not theme related. You can have the ULS also with Monobook, they are diffent options in Preferences. Secondly, with the ULS disabled you have to scoll up or down even more to find the desired language among dozens of others. Scrolling is the same or more costly than a click more. Anyway, I guess people who use Monobook or don't use the ULS will not be affected.

Still wrong: Scrolling is less costly than clicking. And now right: Yes, people who prefer Monobook are very likely to have the ULS turned off. And we (users with Monobook, no ULS, no VE, no MV, no Typography Update, against Flow, against edit reviews, against shortened language list, etc.) are also disproportionally many among those who create content quality and quantity for the projects, making sure the sweet, sweet donation money flows into the hands of the WMF, who in turn uses it to make our life miserable. I wonder how will it end.

If you needy to scroll, then it meany you don't see it on the first go. If you don't see it on the first go, you need to know it's there and actively search for it. Or you're new to this and you just go back to your favorite engine and search for a page you understand a word or just leave things at that and bath your clownfish. Maybe that's why they want to change scrolly to something else? And also... Perhaps why the language switcher is always on top of other websites.

"We’ve sketched out an option that includes links for switching languages directly on the page, adjacent to the general language selector as shown below." -> this is a great idea.

"Perhaps they could appear once someone has switched languages once" -> yes, perhaps with a logic based on the last used languages, perhaps also with the possibility to pin some of them

"if we think they are likely to switch languages (e.g. due to a discrepancy between their operating system language and the language of the Wiki they are reading)" -> yes too

"There were some requests on displaying the English names of languages in addition to the native name (i.e. displaying both Bengali and বাংলা, rather than just বাংলা)." -> yes

"Some people mentioned adding some kind of indicator in the sidebar that points people towards the new location of the language switcher — we hope to explore this." -> good idea

I would add on my workflow which is one-click. I am currently using Monobook with a global script not to collapse interlanguage links: sometimes I have to scroll but not to click.

It is very important for me to be able to see all interwiki links at the same time. I am active in various interlanguage projects (like CEE Spring) and I may want to need, say, Ukrainian Wikipedia articles having links to Belarusian but not to Serbian. I may be interested in English Wikipedia articles which have a featured interwiki in Czech but no Ukrainian interwiki etc. At the same time, I may just be interested in seeing what is written on a specific topic in a given wiki (e.g. do all Wikipedias already have the name of the new Prime Minister of Ukraine?)

As a result, I would need to have a full list of languages available. With a reasonable sorting (ideally alphabetic, I cannot type বাংলা from my keyboard to find it), and not in a very small dropdown menu scrolling after ten languages while the article has a hundred of interwikis. It does not need to be by default, but I would very much like to have it opt-in. Thanks

I’m sure that to be able to see the whole language list at the same time is something that is sought not only by me and NickK — we are legion! Any change in the way interlanguage links are presented and displayed must be able to emulate the legacy mode. (@NickK: can I haz that script, please!?)

As for the name of each language, I think the best approach is to show a pair of labels:

• The target language name in the context language,
• slash, and
• the autonym,

with trivial collation. E.g. «Französisch / Français» in German projects, «Bengalês / বাংলা» in Portuguese projects, «Kireno / Português» in Swahili projects, and so on. (Identical labels could be either duplicated or collapsed.) I presume that getting the name of any (covered) language in any given (covered) language is trivial with Wikidata, yes?

Tuvalkin (talk) 08:49, 15 April 2020 (UTC)

@NickK@Tuvalkin You don't need a script. It is an option in Global Preferences

I do not understand the objections on the location of the language switch of the Vector theme, from people who use Monobook. Yes, most of us commenting here have very unique workflows (me included), we use scripts for our special needs, etc. But the redesign should be helpful for the majority of users who don't need or cannot do (most of them are just readers). I am sure that we will be customizing things that we don't like or would prefer something else.

@Tuvalkin: Yes, global preferences do the job now, I used m:User:NickK/global.js before.

I think the current format of language names is OK, and names with a slash would be unnecessarily long (especially for some languages with already long names like Chavacano de Zamboanga). AFAIK it does not use Wikidata but some ISO database instead. The key point for me is to have all of them displayed so that I can do Ctrl+F or look through the list.

@Geraki: It is not clear that this will affect Vector only. For instance, compact interwikis affect Monobook as well. And to be honest I think Monobook users are not the only ones who are interested in the full list of Wikipedia languages. Having the same article in 100+ languages is one of the most exciting things about Wikipedia. For instance, can it become some sort of sidebar on the right (where there will probably be some free space)?

Quick clarification - the changes proposed would only be for the Vector skin and would not affect Monobook. The plan is to continue providing the current version of vector in user preferences in addition to the new version - some more info on how this will be set up can be found on this page