Talk:Reading/Web/Desktop Improvements

You can comment in any language. When giving feedback, please consider the Goals and Constraints of the project.

We are especially interested in feedback on:


 * Feedback on the ideas and mockups we have collected so far - How could they be further improved? What important considerations are not currently documented?
 * Identifying other focus areas for the project we have not yet discovered
 * Expanding the list of existing gadgets and user scripts that are related to providing a better desktop experience. If you can think of some of these from your wiki, please let us know

Interested in more
I attended session about process of desktop improvements on Wikimania 2019, and there it was very nice discussion. So, as I`m interested about this, you can contact me any time if you needed about upcoming process. --Ehrlich91 (talk) 15:31, 31 August 2019 (UTC)

desktop on mobile
I use wikidata on a mobile device with horizontal FullHD++ display. Still it starts with the mobile optimized view. Worse: After I have switched to desktop view, it ever and ever again reverts to mobile view, even so they tab stays open, I am logged in, if I have to reconnest to wifi. It doesn't matter to me if it is done with cookies, preferencs or javascript, that checks for screeen size, but: The one and only but massive improvement of desktop would be, if desktop view simply would stop to vanish. --C.Suthorn (talk) 08:00, 16 October 2019 (UTC)
 * For your comment: Two options: You might find it useful to switch on the "Advanced contributions mode" in your settings at the mobile versions, see more info at Reading/Web/Advanced mobile contributions. Alternatively, you might try using one of the browser-extensions which forces a redirection, e.g. firefox (but obligatory security warning, don't install random extensions, do check the author/sourcecode/usercount/license/etc.)
 * If you have any feedback on the ideas and details specifically in the project page here, that would be appreciated. :) Quiddity (WMF) (talk) 16:01, 16 October 2019 (UTC)
 * About Firefox: On the mobile device, I cannot decide to use the browser of my choice. (similar might be the case with iOS, where Safari is embedded so close with the OS, that using another browser is not really a way to go). I will look into the mobile preferences, but: Why? I never entered a xx.m.wiki... Url into a browser. I always use xx.wiki... because I prefer the desktop version. --C.Suthorn (talk) 16:41, 16 October 2019 (UTC)

Admin tools

 * Deletion page -- It happens a lot when the admins need to delete several pages in a row with the same reason. So this tool should be able to store the last selected one to put it by default.
 * Block page -- Same as above.
 * Special:import -- Same as above, the most part of the importations are templates so it's counterproductive to import them into "Transwiki:" by default: let's use the last selected option instead. JackPotte (talk) 08:17, 16 October 2019 (UTC)
 * Hi. This project is to do with the entire design of the skin of the wikis, for all users, and is not going to be touching the design of individual special:pages. However, please do file phabricator tasks for your feature-requests, as they are good ideas. (this list of related phab #tags might help you).
 * If you have any feedback or questions about the details in the project page(s) here, that would be greatly appreciated. Thanks! Quiddity (WMF) (talk) 16:11, 16 October 2019 (UTC)

Less items, less links, less confusing in toolbar
Currently, the sidebar blocks may be configured by local project admins, while the  tools block seems to be hardcoded at skin PHP level.

This should be reduced, and/or made available to local config.

I do regard the following links as no longer meaningful for anonymous readers and perhaps even newbies. They should get  on   for new or anonymous users: For deliberate  like history or info or edit the user is in expert mode anyway. In such mode additional tools may appear, even more than today.
 * Related changes – not reasonable for a normal reader, confusing, meaningful for experienced editors only. One of many many possible advanced links, but a quite sophisticated one. Dedicated to those who are interested in checking article changes, but not promising for a reader.
 * Upload file – a reader wants to read an article, not uploading a picture. Might have been meaningful in the first decade of wiki experience, but does need some background information about licenses. Available through Special pages anyway, like a hundred other special pages. If a project does like that link it can be offered in a Contribute section of the sidebar, but I do recommend a tutorial as link target for new users.
 * Wikidata item – needs background; confusing for regular readers and does not help.

The same goes for printing, PDF (broken), exporting, book creation. Might have been meaningful in the first years, but papers in bookshelf are not really matching the needs of the handheld device driven community.

General note, even on items configurable to by local project – the following items might have been nice in the first years of wiki experience, but they do not tell anything on a Wikipedia or Commons:
 * Recent changes – not meaningful for external people. You need to be member of that community to understand what is going on. Otherwise it is a meaningless game. Yes, things happen. Yes.
 * Random page – to make the first experience that Wikipedia is an encyclopedia with many articles on topics you never heard of. Reasonable to introduce the new Wikipedia project in 2005. Nowadays our readers are born after Wikipedia has been founded. Nobody needs to make a test experience that Wikipedia is an encyclopedia with articles. Brother and sister, Mom and Dad are using Wikipedia frequently.
 * Sandbox – not meaningful for content projects. Has been helpful in the first decade for wikisyntax experiments. Meaningful on a test wiki or by a technical site like mediawiki.org but useless with VisualEditor. For creation of a new article you need much more background on contents and requirements and policies. That link may be offered within guidelines how to contribute, but pointless for readers.

Items may be delivered as  and could be subject to user or project CSS rules for certain needs, but on +900 wikis without technical community it is better to switch off by default. The links are equipped with  already.

I do agree with the following Stockholm statements, and pointed to explicit items.
 * Different people have different needs.
 * The interface should be more modular and configurable.
 * The interface should be less dense, especially for readers. There was agreement that over time a lot of clutter has built up in the interface.

By keeping the classic appearance for registered users more or less as current but omitting items for anonymous view a smooth migration for old fighters will reduce riots due to disruptive changes.

Greetings --PerfektesChaos (talk) 09:48, 16 October 2019 (UTC)

Re: Feedback wanted on Desktop Improvements project (fawikipedia)
I have nots iced Farsi wikipedia has been chosen to be one of the first winkies to utilise new format of wikipedia as beta. From your note in farsi version of village pump I gathered users need to attend this page and give feedback. I agree to be part of this improvement plan. Some concerns have already been discussed there. Gharouni (talk) 10:43, 16 October 2019 (UTC)

"Reading mode" and "editing mode"
In my opinion, a main reason for the problems related to UI is that the classic Vector skin tries to serve both readers and editors with mid-2000s tech, but fails to be a good interface for any of these two groups. A separation into quite distinct "read mode" and "edit mode" could be helpful, although it is clear to me that our readers are always considered to be (potential) new editors, and one does not want to alienate newcomers with a complete new interface that they have never seen in their reader role. Another side remark: please make sure that the UI is quickly responsive after a page is loaded. There is a tendency that too much or inefficient javascript code slows down page loading, which can be really annoying for editors at least. —MisterSynergy (talk) 12:15, 16 October 2019 (UTC)
 * Regarding a potential "reading mode" it would be cool if the content was horizontally restricted to a certain maximum width, in order to keep text line length at reasonable values. This would make reading *much* more efficient on Desktop. I suspect that the current average display has full HD resolution, which leads to texts which are really difficult to read due to line length (around 250 characters per line (!), depending on font and so on…); editors also tend to write paragraphs that are too long because of that. For readers, there should also be much more whitespace surrounding the text, and much fewer links to all sorts of editorial tools and pages.
 * In "reading mode", the "editing mode" should be clearly advertised, and when entering the "edit mode", all the necessary links for editors could be displayed. Even that should be less than what we see currently, and lots of links could be re-organized in a much more logical way. IMO even for the "editing mode" a horizontal width limitation would be helpful, but it is not as important as for the "reading mode".
 * That's a good description of a core part of the problems, and of the challenges connected to the idea of a two-mode experience. :) Thank you for the specific ideas, and for the friendly description of the (shared) concern about performance [We do know that some experienced users still use MonoBook primarily for reasons of improved performance, among other reasons]. If you have any thoughts or questions about the ideas and design-mockups currently in the project pages, that would also be appreciated (perhaps in a new section). Thanks, Quiddity (WMF) (talk) 16:25, 16 October 2019 (UTC)
 * I quickly scrolled through these slides and was positively surprised that the presented design mockups—which I all really like—seemingly still count as "no drastic changes to the layout" . That said, some of the design mockups are already implemented either way in the Timeless skin that I happily use in German Wikipedia for roughly a year now. That skin does implement some of my suggestions, in particular the fixed content width, and I find it much better than the classical Vector skin in spite of its apparent beta quality in many places. It feels like a development clearly into the right direction, but in some sense not implemented consequently enough, like "stopped somewhere halfway of the necessary journey towards a really useful UI design"; for instance, it still tries to serve readers and editors with basically one UI which is a compromise for both modes, and the number of rarely used links has been re-arranged, but not really reduced. Anyways, based on what is presented in the PDF slides and my positive experience with the Timeless skin, I have some hope that this desktop improvement initiative is going to be useful for the movement. —MisterSynergy (talk) 19:27, 16 October 2019 (UTC)
 * Hmm... I use a lowly 25 inch screen with around 280-300 characters per line and I wish there was more... it's really a matter of personal taste., you named one side issue, that paragraphs become probably too long, but there's more. Thе articles themselves increase; seven years ago a 400 kB featured article was a one-of-a-kind bomb, today it's just one of many. Big screens lend themselves well to large tables, elaborate graphic layouts, math, oversized infoboxes etc., and each of these 'excesses' has quite a few proponents who will certainly oppose any downsizing of text area. Any substantial redesign, IMO, should address graphic layout directly, in a MOS-like way, and then explain what to do with legacy pages. Too many pages won't fit the proposed shrunk page pattern, but who will fix it? Retired electrician (talk) 19:25, 18 October 2019 (UTC)
 * Sure, I understand. The more content we densely squeeze into the viewport, the less excessive it appears in some situations. But I think we should acknowledge that:
 * Line lengths of 250, 300, or even more characters per line (cpl) are simply way beyond any acceptable values with respect to optimal readability; there is in fact personal preference regarding optimal line lengths, but typical values are in the 35 … 110 cpl range. I don't think we should necessarily restrict ourselves to that range, but it can definitely provide orientation.
 * A substantial part of the readers use mobile devices, AFAIR it is meanwhile even the majority of readers. Their displays are much smaller than desktops, thus content produced on and optimized for excessively wide displays does not go down well for them.
 * Median page size was at ~2.5k around two years ago (and it hasn't changed much if I may speculate); important articles in terms of readership tend to be a little larger, but are still more at wikitext lengths of the order of 10k or so. There is a tendency that some authors write articles on advanced university term paper level, but this is certainly not a good orientation for our UI design.
 * In general, I find it quite remarkable that Wikipedia is at its core a text-based medium, but we *never* had an UI that is in any way optimized for the needs of readers: efficient reading, efficient navigation (internal links and search function), and to some extent also use of talk and history pages. This lack of reading experience optimization is probably related to the origins of Wikipedia in the early 2000s, when average desktop displays were much narrower, and content was typically stretched across the entire screen. The Vector skin is sort of a modernized derivative of Monobook, as it still uses the same early-2000s UI design ideas.
 * Mind that a good reading UI could be user configurable: content width, font size, and maybe even font face could simply be made selectable within certain limits, in order to allow some sort of optimization according to personal preferences. There could also be a "dark mode" for reading. (All as indicated in File:Sketch of reading preferences panel for the Desktop improvements project.png.) —MisterSynergy (talk) 21:26, 18 October 2019 (UTC)

Diverging interests of casual readers and experienced editors
I feel like interests of eexperienced editors and casual readers differ a lot here.

I want as little collapsible items as possible, even if I have to choose non-default gadgets. In particular I want to have non-collapsed the following things:
 * As an experienced editor,
 * Advanced editor / admin links (move, delete, protect...): I sometimes have to do bulk deletions / bulk protections, and having to uncollapse every time means one extra click
 * Sidebar tools: page links (what links here, related changes, Wikidata...) and general links (recent changes, new pages, village pump). I am likely to click them for pretty much any page, and I don't want one or two extra cliks for this.
 * Interwikis: I edit multiple wikis and speak multiple languages, sometimes I am interested in a specific language (e.g. I may want to open an article in Polish about a town in Poland), sometimes I am interested in all languages (e.g. I want to find the one which is most up-to-date). No collapsible interwikis, and especially no interwikis search will work for me.
 * Full-text search (e.g. to find and replace a typo).
 * Quick links to sections, particularly to edit the right section.


 * As a reader,
 * I want to quickly find an article I need via search, with as good descriptions as possible in case of disambiguation
 * I want to use some links on sidebar (such as current events or random page)
 * I want to have interwiki links easily accessible and prominent. Not sure the current option is perfect, it might be underused because of this, thus an A/B test would be useful.
 * I should be offered an intuitive way to edit, as we expect to turn interested readers into editors. I should probably be able to check help or FAQ in an intuitive place

I understand that my interests might differ from that of most readers, but please include a less collapsible option, preferrably as a global gadget, and do not hide anything newbies may need when they start editing — NickK (talk) 15:10, 16 October 2019 (UTC)
 * Thanks for the feedback. A few of the points you raise were also mentioned during Wikimania (see Wikimania Stockholm research report for details), and it's clearly understood that some editor workflows need constant and instant access to these links.
 * Overall, it's currently looking like one of the better options might be to collapse the sidebar for logged-out users, and leave the sidebar uncollapsed-by-default for logged-in users, perhaps along with some re-examination of the specific items in the default&customized sidebars.
 * There is also some recent analytics research at T229926 that is looking at some specifics of what links are most used, and determining what to research next, although the nuances of important-but-edge-case-workflows need to be kept in mind as they tend to not show up in broad statistics. Thanks again. Quiddity (WMF) (talk) 19:20, 16 October 2019 (UTC)
 * Thank you, a lot of interesting data there!
 * Can we perhaps have a deeper analysis, notably with inclusion of more projects (particularly those with different sidebar arrangements), and with split of users by activity if possible (e.g. splitting logged out users who edited from those who did not, logged in users with advanced rights, those without but who actively edit, and those who do not edit)? I am pretty sure patterns will be different especially from one group to another.
 * Another point: can we have more data on interwikis usage please? In particular what are the most popular interwikis per language, and whether they are collapsed or not by default.
 * Thanks — NickK (talk) 19:40, 16 October 2019 (UTC)


 * I agree with the separation of the the user populations, but I warn against considering the "readers" as interested in the article page only. If we want to improve reader engagement and competency, please make talk page and history easily accessible for readers. TIA --H-stt (talk) 14:11, 17 October 2019 (UTC)

Customizable UI
There are many links in menu, but some of them I use seldom. So I would like to have possibility to hide some links/sections and some "pin" so are always visible.
 * link to main page is duplication of logo.
 * section print/expot I used maybe once in 15 years.
 * actions for page (move/delete/etc) in vector are hidden, so I still use monobook in my main wikis
 * search field and personal links are always visibkle in timeless, but it would be fine, if I can some links "pin" out of collapsible menu.

And one more thing - it would be fine, if there is button for going to top/end of page (e.g. I want to see categories). JAn Dudík (talk) 19:08, 16 October 2019 (UTC)
 * Thanks for the specific ideas and details. Customizability is always the ideal dream, but is also unfortunately the most technically complex; it's hard to create, hard to maintain, and especially hard to make it with good "performance" (speed) for all the users. This is partially why gadgets/user-scripts are so well-loved by highly-active editors, and hence why we're trying to collect more details on which ones are related to this project. Thanks again. Quiddity (WMF) (talk) 19:28, 16 October 2019 (UTC)

Instead of hiding, make the UI specific for readers/editors.
A lot of the reasearch proposals suggests hiding this and that. That is not really the solution. Instead, the sidebar should be as-is for logged in users (many users are pretty resistant to change anyway), but for others the sidebar would include the table of contents when there are 8+ headers, link to pdf creation for that page (for the laptop users), the language links and an link to an Help desk (where it exists) or the Village pump (where it does not). Many readers also do not realize that the Categories would make it easier for them to find similar material. Maybe that needs to be renamed to Folders, but only for the logged out users.

I see these research suggestions are made based on click counts, but really I would not read so much into that. The fact is that many users do not find these links in the first place. Specifically, it has taken me quite some time to explain where users can find the language links. That is an indication that the whole UI needs to be rethought from scratch, rather than shuffling or hiding links away.

What would be really useful is moving the "Edit" tab over next to the "Talk" tab. Really, that change is long overdue, and yes, there is an research paper on it somewhere. Also, the crosswiki search will be really useful for readers, but that is allready being worked on anyway.--Snaevar (talk) 20:59, 16 October 2019 (UTC)
 * thank you for the ideas. A couple of notes from our side:
 * We are currently looking into different behavior for the sidebar for logged-in and logged-out users, with the sidebar being open for logged-in users and closed for loged-out users. Some of your suggestions are actually pretty close to what we were thinking as well.  What we are trying to do in terms of separating different links is to have the things related to the article (such as PDFs, table of contents, etc) in a different place than things related to site navigation (such as links to the help desk or village pump).  I like the idea of making a help link more obvious for logged-out users - maybe this is something we can explore further
 * For language links, we are exploring a few more options on making them more prominent, such as moving them to the top and highlighting the main languages someone might use
 * Feel free to check out all the individual ideas we tested and some more in the research report. Thanks again OVasileva (WMF) (talk) 10:58, 17 October 2019 (UTC)

Improvements for Consideration
I mention the following improvements for consideration: Thanks for asking. -- Dave Braunschweig (talk) 02:29, 17 October 2019 (UTC)
 * 1) Shared templates - Similar to how File: works now, if Template: exists locally, use the local copy. If Template: doesn't exist locally, use a common copy. It doesn't have to come from Commons. It could come from MediaWiki or Meta as a central repository for common templates. But having common templates and a single point of update, perhaps by language, would go a long way toward standardizing the user interface and functionality.
 * 2) Shared gadgets - Similar to shared templates, provide a central repository of common gadgets, again either on MediaWiki or Meta. Having a central place allows easier implementation for small wikis.
 * 3) en.wikiversity has Quiz and MOOC add-ins / gadgets. I don't know if they would be useful elsewhere, but they should be considered.
 * 4) The LintHint gadget should be standardized and centralized.
 * 5) In the process of standardizing and centralizing gadgets, provide clear documentation and examples for how new gadgets can be created. This may exist already, in which case, link to it and improve it.
 * 6) The biggest complaint I hear from new users is how difficult it is to work with files / images. Upload is not at all obvious, the upload user interface on Commons is completely different, etc. Embedding existing files is also not intuitive for new users. We need to get to a point where properly licensed media can be added as easily in wiki as it can on other sites or editors will move on and create content elsewhere.
 * 7) Remember security. Much of what you describe is under the restricted UI area, where most users can't make changes.
 * Those are some good ideas, some of which are being worked on elsewhere e.g. T121470 (and the first 2 are taking a long time because they're immensely hard both technically and socially), but they are not part of the area that this particular project will be covering. This project is primarily about the areas highlighted in the image at the top of Reading/Web/Desktop Improvements/Research and design: Phase 1, and making the sites easier to use for everyone. Please take a look through the project page(s) and share any further feedback you may have on the ideas and design ideas within. Thank you! Quiddity (WMF) (talk) 18:05, 17 October 2019 (UTC)
 * , shared templates definitely won't be done in the scope of the Desktop Improvement project, but I agree that it's a very necessary change. I'm trying to write a proposal about this here: Global templates. I'd love to hear what do you think about it.
 * Since it won't be in the scope of the Desktop Improvement project, it's better to continue this conversation at Talk:Global_templates.
 * Thanks! --Amir E. Aharoni (talk) 14:52, 28 November 2019 (UTC)
 * Excellent proposal. I added my support. -- Dave Braunschweig (talk) 15:45, 28 November 2019 (UTC)

Unterschied Autoren und Leser

 * Ich denke Autoren benötigen ganz andere und ggf. individuell verschiedene Dinge als ein Leser.
 * Für Autoren ist eine Umfrage hier ggf. nützlich. Für Leser ist es IMO eher nutzlos. Hier im mediawiki-Wiki sind ja nur die "hardcore"-Nutzer. Selbst den normalen Wald- und Wiesen-Autor werdet ihr hier eher nicht erreichen. Das ist m.E. ein gravierender Nachteil. Wenn ihr also an deren Feedback interessiert seit müsst ihr wohl andere Wege wählen ... achja und nicht vergessen: "andere Länder, andere Sitten" - nur weil in US-Amerikaner etwas toll findet, muss das Deutscher noch lange ich toll finden. Also ggf. mal ein wenig umschauen (und nicht wie bei der Verschiebung des Suchfeldes von Links nach rechts 8 (in Worten "acht") Leute frage. So habt ihr das beim letzten Mal gemacht und das ist irgendwas zwischen peinlich und unfähig. Meine Erwartungen sind aber ehrlich gesagt genau so. Ein paar Nutzer hier, ein paar Hardcore-Wikipedianer auf der Wikimania und dann die Techniker bei WMF; fertig. So ist meine Erwartung wie die Millionen Dollar schwere WMF arbeitet; heute und in Zukunft. Nichtdestotrotz hier meine Anmerkungen;
 * Ansonsten bin ich monobook-nutzer der sein Suchfeld links hat. Würd ich gern so beibehalten.
 * ich würde gern bestimmen können welche Sprachen mir prominent angeboten werden. Die 9 größten Sprachen nützen mir überhaupt nix. Außer englisch verstehe ich keine davon. Dafür aber polnisch. Die taucht aber nicht auf. Das individuell gestalten zu können empfände ich nützlich.
 * Ein großteil der Links die Links im Menü zu finden sind halte ich für nicht nützlich. Weder für Autoren noch für Leser. "Witzig" sind die Links unter "In anderen Projekten". Das ist so gut versteckt, dass es nur für Autoren wirklich eine Bedeutung hat. Warum nicht mit Symbolen arbeiten? Allerdings ist das Commons-Symbol so kryptisch, dass es wohl auch nutzlos ist. Hier müsste etwas her, dass auch von einem Nicht-Insider sofort verstanden wird.
 * Tja und abschließend sei es nochmal gesagt: ich, wie Sicherlich die meisten die hier kommentieren sind mehr oder weniger alte Hasen mit einem eingeengten Sichtfeld. Wenn ihr wirklich etwas verbessern wollte und nicht nur ein bischen rumflicken, dann geht zum einen raus und fragt die "einfachen Leute" und nutzt ggf. eine Design-Agentur die mal frischen Wind in die Bude bringt ...Sicherlich (talk) 15:27, 17 October 2019 (UTC)
 * Thank you for the feedback. Sorry for replying in English. For your comments about language links, the details in sections 2.2 and 2.7 here might help: Universal Language Selector/Compact Language Links/de. Quiddity (WMF) (talk) 17:52, 17 October 2019 (UTC)
 * I will add: This is just one of the channels we're using for feedback. We're also going to be doing quicksurveys with all editors, and we will test prototypes (when ready) using central notice so more people can participate, and we will be doing outside user research with readers. Quiddity (WMF) (talk) 18:29, 17 October 2019 (UTC)
 * @User:Quiddity (WMF): Englisch: kein Problem.
 * Sprachlinks: das ist nicht das Problem um welches es mir geht. Im Artikel de:Deutschland sehe ich im linken Menü unter "In anderen Sprachen" standardmäßig Links zu 9 Sprachversionen der Wikipedia. Davon spreche ich genau eine: englisch. Weitere Sprachen kann ich nur durch extra-Klicks sehen. Oder ich ändere das irgendwo in den einstellungen (oder monobook, css. oder k.A. wo ich das geändert habe) und sehe alle Sprachen. Ich würde aber gern standardmäßig "deutsch, englisch, polnisch" sehen. Der Rest ist für mich im allgemeinen irrelevant.
 * Bzgl. "andere Kanäle" muss ich mal Goethe zitieren: "Die Botschaft hör ich wohl, allein mir fehlt der Glaube". Das wurde auch bei der "großen" Designänderung vor X Jahren behauptet. Nach eifrigem Nachfragen stellte sich dann raus, dass es besagte 8 Leute waren. Das in Kombination mit dem sonstigen Auftreten von WMF lässt mich die Aussage wenig glaubhaft erscheinen (sorry, wenn ich Dir damit Unrecht tuen sollte. Am Ende bist aber Du Sicherlich nicht der einzige im Projekt) ....Sicherlich (talk) 07:47, 18 October 2019 (UTC) Erläuterung Auftreten von WMF: Das reicht vom Superprotect über Heilman bis zu Fram aber auch so einfache Dinge wie es WMF seit Jahren nicht schafft außerhalb des englischen Sprachraums zu denken/zu sprechen. Im Sinne von AGF ist es wohl einfach Unvermögen zu Verstehen das dies eine Bedeutung hat. Wenn man AGF weglässt ist es wohl Arroganz
 * Re: language links: If you add Babel boxes to your meta-wiki userpage, that will force the inter-language links that you want, to always be shown (if available) on all wikis. (More details in my link above).
 * Re: non-English work, there is some ongoing or recently concluded/started work, e.g. Growth and New Editor Experiences and New Readers (and now Inuka team) and Project Glow (just from my memory). I understand your point, but it's not possible to talk to/work with everyone at once!
 * If you have any additional ideas on "Ich denke Autoren benötigen ganz andere und ggf. individuell verschiedene Dinge als ein Leser." beyond the ideas you already added, that would be appreciated. If I understand correctly, so far you've recommended: an easier way to customize which inter-wiki language links appear by default, a clearer display of inter-wiki (project) links, and a cleanup of sidebar links.
 * Thanks again. Quiddity (WMF) (talk) 18:48, 21 October 2019 (UTC)
 * Ah! Gut, ich dachte es geht nur um die angezeigte Wiki-Sprache. Gucke ich mir an. Zeigt natürlich gleich das nächste Problem: Einstellungen macht man überall verstreut ein bischen. Wenn irgendwas aber nicht mehr funktioniert ist es abenteuerlich herauszufinden wo was geändert wurde.
 * Sprachen: Guck Dir mal Deine Links genau an: Mit eher zufällig ein bischen, manchmal gar nicht teilweise übersetzten Seiten wird als also "non-English work" angegangen? 😂 Danke für die Bestätigung, dass es WMF völlig überfordert ist mit der bedeutung von "global". Du hast Recht mit "it's not possible to talk to/work with everyone at once!". WMF ist aber nichtmal in der Nähe von "mit allen". Es spricht mit wenigen Hardcore-Wikipedianern. Denen die auf irgendwelchen Konferenzen rumlaufen und/oder mit Leuten die sich auf meta-Wiki oder gar hierher verlaufen. Das ist ganz dicht an "mit keinem" dran. Aber was red ich; diese Geschichten werden regelmäßig an WMF herangetragen und es wird genickt und zugestimmt und gesagt "danke für Deinen wertvollen Input" und es passiert genau gar nix. ...Sicherlich (talk) 21:27, 21 October 2019 (UTC)
 * The actual work in those other projects is/was carried out in the local languages. I agree it would be great if everything was translated, but that's not practical. It's already a lot of (deeply appreciated) effort to do translations for pages that really do need it like this one, and Tech News. We all have to prioritize as best we can. Quiddity (WMF) (talk) 16:58, 22 October 2019 (UTC)
 * "that's not practical" - ist es für die großen Sprachen problemlos: Dolmetscher einstellen: Problem gelöst ... man könnte natürlich auch eine Art Botschafter in den Projekten haben, der neben der Sprache auch gleich noch die Kultur kennt. Sowas in der Art gabs ja auch, wurde aber durch den völlig sinnlosen und überzogenen Einsatz von Sperrechten (aka Superprotect) leider verbrannt. Man könnte Sicherlich auch die lokalen Chapter dafür begeistern. ... Es gäbe also genug Wege, wenn ein Wille da wäre ...Sicherlich (talk) 19:42, 22 October 2019 (UTC) "like this one"? Also die deutsche Übersetzung ist ziemlich unvollständig, dito die spanische, die französische, die polnische usw. einzig zh scheint übersetzt

Proposal: respect the user's screen space and attention
[ Dumping this here since I don't know what a sane format for this would be on the page.]

TLDR version: please fix T163098!

The current page layout on most projects appear to have been driven by "Stuff I think is important" priorities from people working on one narrow nook and cranny of the software or another. For example, the "branding" folks (those guys that think renaming every project to "Wikipedia" is a great idea) will insist that the logo be in exactly the place and size where it currently sits. The Legal folks will insist we have a footer full of disclaimers and other legal mumbo jumbo. We must, of course, have the search field easily accessible and visible (after all, the ElasticSearch guys spent a lot of time on the new search engine). Visual Editor is the saviour for editor retention, and since all those recalitrant old-timers refuse to have it be the One True Editor, we must set aside prime space for two "Edit" buttons. And so forth… And all of those things are probably true too. It's just that they are narrow concerns and true only in isolation.

The one concern missing in all of these voices is the content. The article on Wikipedia, the media and file description on Commons, the works on Wikisource, etc. To take a meta-example from a non-content page, the Special:Watchlist. Go look at it… See all the fancy OOUI chrome for the filtering functionality (which nobody uses on the Watchlist, but it's the same code that's used on Special:RecentChanges, where it is used, so the Watchlist gets it too)? All the other stuff crammed in there? Now try to identify what the primary purpose of that page is, and what part of that page the user is primarily interested in. How much of the available page space is budgeted for that primary content, and how much is budgeted for secondary and tertiary content?

I did this exercise for my own very real use case on English Wikipedia, and filed a bug for it: T163098 (Isarra was, not unexpectedly, the only person that looked at it). Ballparking on those screenshots (I'll get out a ruler and measure if you want) I'd say 90% of the available page space is given over to secondary or tertiary content, and only 10% to the primary content. That's not just not optimal, it's an outright catastrophic failure.

The issue isn't as bad for actual content pages, but there's still a disproportionate amount of space given over to things other than the primary content (the Wikipedia article, as the obvious example).

This problem also manifests in ways more subtle than mere relative size: look at a page and tell me what element is most important in it? The writing system direction tends to correlate with a hierarchy of importance for visual regions of a page, so for left-to-right horizontal readers, the page elements in the top left corner are by far the most important, with decreasing importance the further to the right and down you go. Guess what's in the bottom right corner (most likely partially hidden behind a need to scroll vertically)? That's right, the primary content of the page (the Wikipedia article). What's most important? The logo, then the toolbox widgets and other meta-stuff.

I was bothered by this reversal of priorities to the point I actually wrote a toy user script (w:User:Xover/focus.js; if you try it, it puts a little image dingus in the top left corner that toggles hiding/showing) that hides everything except the primary content on the page, mainly for use on my Watchlist. The difference is… eye-opening!

I'm going to propose… that the effort start by completely reversing the hierachy, and goes to the opposite extreme. Top left is reserved for the actual primary content. Any chrome, branding, information (legal etc.), links and tools go to the right and the bottom (maybe the logo joins the legal disclaimers and terms of use?). And that starting from that baseline, every single element that wants to move up and to the left has to justify its increased priority relative to every other page element, and especially the primary content. And the more space you want to occupy (the bigger the chunk of the budget you're asking for), the better you have to justify it. If we absolutely positively need to have something up in the top—left real estate somewhere, at least make it as small as possible. A small 18x18 globe icon that pops up the language switcher? Probably much easier to justify up there than a big >100x100 box of text listing the different languages…

You can't deploy a design taken to that opposite extreme, of course, because visual hierarchy and such aren't the only axis on which to assign priority, and in the real world you have to take into account users' learned behaviour from other sites. But maybe starting from that new baseline, and with new fresh eyes, it becomes feasible to move the logo to the top right instead of the top left? Maybe, just maybe, we can move or redesign the left sidebar such that it doesn't take up so much of that valuable top—left page space? If we stick more of the left sidebar stuff up into drop-down menus at the top (like the "More" menu), maybe what's left can be handled differently? If switching languages is a button-like UI widget somewhere, maybe we don't need to have a left-sidebar list of all of them? And so forth and so on…

With widescreen monitors and the type of content we host, the vertical space is much more precious than the horizontal, and the space that's too far right is effectively "junk" real estate (in a fullscreen window on a 32" desktop display, the right edge is in Siberia). So it should be hard to justify every use of a vertical pixel, and anything that's happy to exist on the far right of the page can get that space for cheap. But whether Bel Air or the Caucasus, the design needs to consider the cost of the stuff that's put on the page, especially that fixed stuff that's always there and is present on every page.

And one thing is for the visitors (they may need hand-holding in the form of branding and links to FAQs etc.), but for someone who has been here ten years and is trying to write an article about a neglected female scientist from the global south… They know what site they're on. They probably wrote the FAQ that's linked there. They're +sysop on a couple of the other language projects linked in the sidebar. They have keyboard shortcuts that trigger custom user scripts for all the stuff that's in the editor toolbar. They don't need the reminder that their contributions must be dual-licensed under blah blah. Why isn't the editor text box full screen on the left of the screen and a live-updating preview of the page in fullscreen on the right? Those are the two elements they actually need in that setting. Visual Editor would approximate this, but since it has prioritised being friendly to new users it has limited support for stuff experienced users need (like arbitrary templates) meaning the experienced users are the ones most opposed to Visual Editor.

The interface isn't for a single, homogenous, group of users, and so it can't be a single fixed thing that tries to cater to everyone. Who the user is determines what are the important parts of it, so the interface needs to adapt to which user is using it. And if it does, it can get rid of things that are of no interest to the current user and thus gain back valuable real estate on the page. Ugly confusing wikimarkup and template invocations should not be dumped in the face of a new user or normal reader just trying to fix a typo, so take those away and use the space for branding, legal, or FAQ links. Conversely, take away the branding, and legal, and FAQs for the experienced users (who have asked for that in their preferences), and you have loads of space to put in technical tools or prevent distractions from the content or…

Bottom line, I, as a user of the interface, want you to respect my available screen space and the demands on my attention, and to be frugal in imposing on either. What task or content I am after determines what is worth my screen space or my attention. Your concern for branding, or legal, or user interface design or technical purity are insufficient grounds for "spending" my screen space and my attention.

I am, above, exaggerating for rhetorical purposes, of course; but if you adopt that perspective and then analyse the UI and layout there are a lot of questionable decisions there.

And if anyone can manage to boil that wall of text down to something that fits in the format of these suggestions I'll be mightily impressed, and not a little grateful! :) --Xover (talk) 10:11, 18 October 2019 (UTC)
 * Hi . Thanks for taking the time to write in detail. :) IIUC, and just hitting the highlights, and without addressing the many good ideas in T163098, you are commenting on:
 * 1) the size of OOUI interface elements -- (I made a related reply about that in the #section below this),
 * 2) the layout of various interface elements, which sometimes get added on new lines individually, instead of all in a row. -- Yes, this has been a point of concern for experienced editors. It's hard to balance newcomer-friendly clarity with experienced-editor needs for density/efficiency, but there is still room for improvement in some of the designs.
 * 3) the collapsibility of blocks of interface elements -- Good news, you can collapse the new filters! Although I just noticed some odd whitespace there, and will file a task... T236105.
 * 4) Whether anyone uses the improved filters on their watchlists -- I do for one! E.g. https://i.postimg.cc/qBy8f3CH/image.png - the background-color filters help me quickly find potentially problematic edits to focus on. I've also got a custom rule which gives 60% opacity for editors with 500+ edits which further helps me focus attention on newcomers. Plus I frequently tweak which namespaces are displayed.
 * 5) recommending overall that more of the actual content in watchlist/etc pages should be "above the fold"
 * 5.1) endorsing the idea of giving more visual focus to the content of mainspace content-pages.
 * 6) tentatively endorsing the idea of a new feature to toggle a sticky-collapse of the site-sidebar
 * 7) tentatively endorsing the idea of more page-tools being located in dropdown menus -- (However, I'll note that many other comments on this page and the other research were from active editors whom are concerned about any changes to features that they use constantly being any harder to access at all. E.g. they don't want the "block user" link hidden in a dropdown menu because they use it dozens of times/day.)
 * 8) various comments about the value of vertical space, and the top-left corner (in LTR languages).
 * 9) suggestion of potentially moving the site-sidebar to the opposite side of the screen
 * 10) requesting side-by-side editing and preview -- I know there's a userscript on enwiki for this (w:en:User:Bradv/splitpreview.js), but after testing it just now I see the areas are not resizable (i.e. it has a bug. Understandable as it hasn't been updated since 2008!) - you could try asking the author how complicated it would be to fix it? Or try filing a task in phabricator requesting that feature be added to the existing wikitext editor(s).
 * 11) Overall: requesting more customizability/flexibility/auto-adaptation based on the individual needs of each user(type). -- (again, see my comment in the section below, about ideal world scenario of infinite customization vs the pragmatic present, but personally I agree!)
 * I hope that manages to boil it down accurately without losing too much of the nuance! Some good ideas, with some personal and some global recommendations. Thanks again! Quiddity (WMF) (talk) 22:11, 21 October 2019 (UTC)
 * I think you've admirably summed up the essence of my points (impressively: I wouldn't have been able to distill them so!). Except on one point: I'm not actually arguing for a lot of customization, so much as better adaptability. Compare the "Advanced mode" being rolled out for mobile. Since there are way too many competing concerns for one layout to rule them all, categorising users and scenarios into a smaller number of broad categories and making the UI able to adapt to each of these broad groups, possibly by making each group self-classify by picking their category either in the preferences or on the fly ("Right now I'm adminning", "Right now I'm writing articles", "Right now I'm patrolling recent changes", etc.). Obvious categories are "Default/new user", "Experienced normal user", and "Admin" (I'm not sure accessibility categories are relevant here: in this context, the most distinguishing feature of a blind admin is that they are an admin, not that they happen to be blind); but some deeper analysis would be needed here. The good news is that this is something that can be done iteratively—if funding and priorities otherwise allows for that—and such an effort would almost certainly benefit greatly from any general improvements. Somewhere in the bowels of Phabricator there's also an epic for treating the rendered output as somewhat of an "API" (ala. the toolboxes) that would enable Gadget or user scripts to customise the layout more easily and to a greater degree, which might alleviate the need for specific core changes and enable more experimentation (data gathering) before making any core and core skin changes. --Xover (talk) 08:50, 22 October 2019 (UTC)

Adapt the size of OOUI widget to desktop environment
Hello, I think that some improvement could be made to OOUI in desktop interface. It seems that OOUI has been designed with a mobile-first perspective in mind (all widgets are oversized on computer screens : big buttons, large spacing between component, a lot of padding in text input or drop lists, huge checkboxes...). From my point of view, all these elements are wasting vertical space on the screen making forms unpractical and inefficient to use on a computer. Sometimes it is impossible to display a form entirely in the viewport (for example on the block page). It contains just a few components but I need to use my scroll wheel to see all elements. I have a 4K monitor with 2160 pixel in height and I'm a really surprised not been able to fully display a simple form on my screen (which was possible before OOUI). Similarly, labels and text boxes are not on the same line, wasting vertical space even more. My screen has 3840 pixels in width so I think there is enough place to put label and input boxes on the same line... These big widgets are probably very useful on devices where you use fingers to click, select, check the checkboxes... like phones and tablets but are really annoying to use on a computer with a mouse... As an advanced user, this inconvenient interface could eventually discourage me from continuing to contribute to Wikipedia... As it is impossible to disable or avoid OOUI, I tried to reduce the oversized components, paddings and margins in my custom CSS but with very few results because of OOUI CSS complexity... --Shawn (talk) 18:48, 21 October 2019 (UTC)
 * Hi. The other reason that some OOUI design aspects are larger than some people like (including me), is for accessibility reasons. E.g. people with vision problems, and people who have challenges with getting a mouse-pointer to align with a very small target (e.g. arthritis, hand tremors, etc). In an ideal world, all users would have multiple personal preferences for how everything looks, but sadly that massively increases the software complexity (I wrote an essay about it years ago at Just make it a user preference, because I adore customization, but it really is very very hard, both to setup, and then to maintain forever). However some improvements are planned, and further feature requests are always welcome in phabricator. But we people who like extreme density of interfaces need to balance our desire with the needs of others, at least for now. I hope that helps! This specific project won't really have much overlap with OOUI, but if you have specific questions I might be able to help if you post them on my talkpage, or at Talk:OOUI.
 * If you have any feedback about the ideas and questions in the project page(s) here, please do share those. Thanks, Quiddity (WMF) (talk) 19:11, 21 October 2019 (UTC)
 * I don't think OOUI can be out of scope for any effort to improve the desktop experience. A lot of existing UI is based on OOUI, and it is encouraged for new stuff. And accessibility does not mean "bigger buttons": as Shawn points out, that is more a touch-vs-pointer concern. People able to operate a mouse pointer at all fall within a, relatively speaking, narrow range of ability and are helped by general accessibility properties. In particular, if the UI supports being zoomed by standard browser mechanisms and use appropriate foreground—background contrast, both people with fine-motor issues and people with vision problems are helped. My screenshot of the cramped watchlist above is with the zoom level at 125% because on that particular laptop and where I sit relative to the screen when using it, my eyes need a little help with the text (graphic designers that knee-jerk to reducing font size to 0.8 and increasing line-spacing to 1.2 should be forced to use unsmoothed bitmap fonts—Arial for preference—for a year!). --Xover (talk) 09:02, 22 October 2019 (UTC)

Maps and flagged revisions
On bar:Nassig there is a map created with openstreetmap, but this functionality does not work in wikis with flagged revisions activated. It would be a big improvement to solve this problem. --QXK (talk) 10:43, 26 October 2019 (UTC)
 * That's a good point, but not connected to this specific project. It looks like there is a task for that issue at T192695 if I understand correctly. I hope that helps. Quiddity (WMF) (talk) 19:30, 29 October 2019 (UTC)


 * Hi Quiddity. I think that QXK's request is inside the scope of the project. The main issue is, that wikis with the FlaggedRevs extension cannot make use of the mapframe feature of the Kartographer extension. Therefore readers using the desktop see broken maps. For exmaple de:Emmerich am Rhein. Do you see the little red dot in the west of Germany? Click on the map. You will see a blank map of Germany without the dot or any other marker. Another example: de:Burg Giebichenstein. A click on the map with the little red crown shows the blank map. This is a very bad experience for readers. So fixing T192695 will solve the issue. Raymond (talk) 07:32, 30 October 2019 (UTC)
 * Hi I agree that the bug is an important problem to solve. But this project/page is about changes to the overall design of the wiki UI - see the image at the top of Reading/Web/Desktop Improvements for a visual reference. Additionally, the software at fault for that bug, Kartographer and FlaggedRevisions, are not maintained/written by anyone in the Reading Web team, therefor they don't have the relevant expertise to help investigate that bug. I hope that clarifies things. I will ask a few people to take a fresh look at it, in case that helps. Quiddity (WMF) (talk) 18:50, 4 November 2019 (UTC)
 * Thank you Quiddity for the explanation. Raymond (talk) 18:58, 4 November 2019 (UTC)
 * Hello Quiddity, the problem with FlaggedRevs and mapframe has been discussed on many pages but it seems that there is no solution in sight. Thank you for adressing it to the right people. I hope somebody will investigate this bug soon. --QXK (talk) 21:58, 4 November 2019 (UTC)

Should subpage redirect to here?
Currently there is no discussion at Talk:Reading/Web/Desktop Improvements/Wikimania Stockholm research report. Should that talk page perhaps redirect to here, since this is where the discussion is actually happening? (If so, I'm not sure how to make the redirect, since that talk page comes up as a "Flow-enabled" page when you follow the redlink.) - dcljr (talk) 03:19, 28 October 2019 (UTC)
 * Fixed! (And I'll do the others next) Thanks. Quiddity (WMF) (talk) 18:12, 29 October 2019 (UTC)
 * Should we enable flow on this talk page just like Talk:Reading/Web/Advanced mobile contributions? Masumrezarock100 (talk) 05:30, 3 November 2019 (UTC)
 * No, we're using a classic wikitext page here on purpose to make it familiar for experienced editors from other wikis. Thanks though. Quiddity (WMF) (talk) 18:36, 4 November 2019 (UTC)

Do not hide anything by default without a reliable mechanism to opt out
A lot of what I have to say has already been pointed out in the report itself, but here are my views, anyway. Specific ideas from the report are underlined for ease of scanning. (Note: I am an experienced MediaWiki editor — but not an admin, steward, or sysadmin — who nowadays mostly maintains Wikimedia News and sometimes helps newly created Wikimedia content wikis "get the kinks out" after their creation. Both of these things call on me to visit multiple Wikimedia content wikis each day — usually different ones each day — mostly in languages I don't understand; so, cross-wiki standardization is important for me.)

It worries me when I hear people talking about "hiding" (collapsing or menufying) items in the interface by default for the convenience of some group of users (usually readers). Everyone uses MediaWiki sites in different ways, and one user's "clean" and "comfortable" interface is another's "hideous" (no pun intended) and "frustrating" one. In general, therefore, I think any proposal to "hide" an interface element by default should be accompanied by a perfectly reliable opt-out mechanism to keep it always visible (preferably across all Wikimedia wikis that use unified login) if a user wants that. Note that providing this through a simple "toggle" feature per-wiki (change it once and it remains set that way on that wiki only) is not sufficient: for logged-in users there should be a "set it once, forever, everywhere" mechanism (and, for that matter, also a way to override that on specific wikis — i.e., a global preference).

More specifically, I find the idea of providing different interfaces for different types of users (within the same skin) intriguing, but a little worrying: the implementation of the idea is, of course, critical to its success or failure. I don't particularly like the idea of forcing logged-out users to see the site purely from a "reader" perespective (after all, logged-out users can, of course, also edit). And I especially don't like the idea of forcing logged-in users to see the site in one particular (new) way. In light of this, the idea of selectable reading preferences (such as content width, text size, background color, and hover previews, according to the mockup) is an exciting possiblity. I know the existence of a mockup doesn't mean it's possible to do, but if these kinds of choices could be provided to logged-out users, then surely the choice of how detailed an interface you want to see could also be provided to users, whether logged out or in. In particular, users could choose to interact with the site as a "reader", a "new editor", or an "experienced editor" (or whatever), and the interface would show a selection of features appropriate for those audiences. (I'm sure it's much more complicated than I'm making it out to be… but should it be? After all, everything we're talking about here is, for the most part, "presentation" only, as opposed to "content" — literally, for each thing, should it be visible and, if so, where and in what form — so if we were "doing things right", it seems like it would be "relatively easy" to give users this kind of choice. Right?&lt;/dream&gt;)

As for collapsing the sidebar by default, I'm glad this is only being considered for logged-out users, because I would strongly oppose doing this for everyone. And collapsing individual submenus in the sidebar was already tried in the past and it didn't work out; how would it be better this time? (Not surprisingly, my own opinion on this is: if I can choose to see any or all of the submenus not collapsed, every time on every wiki, then I'm fine with it. Otherwise, no.)

And while we're talking about the sidebar, I would be against placing the table of contents in the sidebar (either replacing what's already there, or in addition to it). Letting it be an always-available drop-down menu on a "fixed" article bar (always at the top of the page when scrolling) seems like a better idea to me (but only if this can be implemented much better than the "Save" button in Special:Preferences currently is). Similarly for selecting languages through a drop-down menu : you usually have to scroll to find the languages, anyway, so needing to click (or possibly just hover) on an article bar to see them is perhaps not too much of a burden. In both cases, ideally it would be immediately clear what the feature does before you engage with it — although this is admittedly a high hurdle. Note, BTW, that some users may need to select "arbitrary" languages from full lists of available options on a regular basis (as opposed to, say, a handful of their own most-chosen options or some kind of "curated" list), so hiding the full list behind multiple clicks or menu levels may be annoying for them. (I found the report unclear as to how very long lists of languages were going to be handled.)

I have no strong feelings about how the search bar is presented, since I personally hardly ever use it. (I usually open a new tab and use my browser's "quick search" feature [I've set up "wp" to signal an English Wikipedia search, "wt" Wiktionary] when I want to search for something.) However, when I do use the search box, I find the "open search results in a new tab or window when holding down the Ctrl key" gadget on the English Wikipedia very useful. I wish I could use that everywhere (it really should be the default).

As for hiding "article tools" behind a menu, not suprisingly, I am also wary of this idea. If it must be done, then making it always accessible (again, on the magical "article bar") and possibly responsive to mere hovering might be preferable. (Not sure how reasonable this hovering idea is, but if it happens it should probably be made opt-out [i.e., require a click to open menus].)

Finally, the idea of a "pinning" feature that would allow certain user-chosen items to always be visible (assuming some stuff gets hidden) is an interesting one, but could it work across wikis and across login sessions?

As with the report itself, I have not tried to make these opinions entirely consistent with one another. I'm mostly reacting to each thing in isolation, as if that's the only thing being changed. (And sorry for the inordinate length of this comment. I didn't have time to make it shorter.) - dcljr (talk) 12:34, 28 October 2019 (UTC)
 * Gloriously detailed and clear (and friendly) feedback, thank you. I'll respond more, later. Quiddity (WMF) (talk) 23:03, 29 October 2019 (UTC)

Default settings defaulting to old solutions
I work with hundreds of new editors (students) each year, and I can tell you what is IMHO the biggest problem with all the new ideas that slowly are getting implemented: half the students don't pay attention to the intro new account pop up 'chose visual vs classic etc.', and end up stuck with old, unfriendly versions. Each intro class I have to spend lots of time fixing stuff in their preferences to make sure they have the same, unified (and modern/friendly) set of tools. So rather than suggest specific improvements, I want to stress the importance of making sure that new accounts will be deployed with new/best tools. DON'T give them the choice 'old vs new'. Set them up with new stuff, and let the few who care go to preferences and enable old style tools/modes/whatever. Most newbies will be much happier with new layouts and we are still loosing people/annoying them by making them edit in old style layouts/code editors etc. just because they didn't read properly through the new editor welcome 'chose old vs new' popup.--Piotrus (talk) 06:38, 1 November 2019 (UTC)
 * If you can wrangle enwp into not losing its collective mind at the idea of Visual Editor being the default for new users I am sure any number of people would be giddily happy to make it so. But keep in mind that VE still has some severe limitations in terms of editing almost any article you choose at enwp (mostly related to templates) so even if you only care about new users this wouldn't be a perfect solution. I do agree with the main thrust of your comment though: forcing new users to make a choice they don't understand and couldn't care less about is not user friendly. Such choices almost always belong in the preferences where a sufficiently motivated user can hunt it down (annoyance is a great motivator), possibly aided by shortcuts to the relevant pref from contexts where it might be relevant. If you're going to pop something modal in a user's face it better be a matter of life and death! --Xover (talk) 14:28, 1 November 2019 (UTC)
 * As I see it on enwiki, 'Visual Editor' has a distinct name, but the so-called classic editor, wikieditor, source editor, wikimarkup editor - call it what you will- does not have a clear identity at all, nor does it have the equivalent of the VE Manual...it's simply 'there'. So, it's hard to talk about one editing tool (VE) compared to another tool when that second tool is virtually nameless, and thus incredibly hard to refer to in a coherent manner. If we could make it clear that Tool B is great for simple editing, but Tool A is better for more complex work, and thus there'll be times when only Tool A will do, then we'd keep a lot more people happy. They'd then know that Tool A is needed for tasks X,Y, and Z, but not for general tasks A,B, or C. If they want to do those tasks they'll have to learn how to use (INSERT EDITING TOOL NAME HERE). But we never seem to make this clear distinction clear! I realise this more of an issue for enwiki to deal with, but I thought it was worth flagging up. Nick Moyes (talk) 23:15, 27 November 2019 (UTC)
 * Good point, I actually realize the same thing recently (there is no guide to the 'classic' editor in the style of VE). This is actually a VERY big problem, and should be addressed by WMF (shouldn't be that difficult, either, just write a manual). Btw, Wiki Edu has a training module entitled "Wikicode vs VE". --Piotrus (talk) 03:05, 28 November 2019 (UTC)

Interested wikis
Ni! For when the day comes, Portuguese Wikiversity would be interested in participating in testing the improvements as a whole wiki. We will be waiting for further contact through our Esplanada. --Solstag (talk) 10:52, 6 November 2019 (UTC)

Section editing links
Hi,

One of the oldest feature requests for our wikis is a section editing link for the opening section, also known in English as lead section, lede, and 0th section. (See ; original 2004 Bugzilla bug.)

This was never done for the desktop site, even though it's supposed to be really easy. It was done on mobile platforms, and was quite successful there as far as I know.

Perhaps this project is an opportunity to finally do it on the desktop site? --Amir E. Aharoni (talk) 14:21, 28 November 2019 (UTC)
 * For reference: en:MediaWiki:Gadget-edittop.js is how this is done on desktop currently. - dcljr (talk) 01:29, 1 December 2019 (UTC)
 * In some wikis, which use this particular gadget :)
 * It's about time to make it uniform across all wikis. --Amir E. Aharoni (talk) 08:45, 5 December 2019 (UTC)

Language switcher issues
Hi. Regarding the proposed language switcher, the placement seems very prominent. It also seems like it would interfere with a half-dozen other user interface elements that are competing for that space, including geo coordinates, the page protection icons, etc.

I'd like to better understand how common it is for a user to be reading an article in one language and want to switch to a different language-version of that article, particularly when the different language-version might have substantially different content. Is this a common use-case? I have my doubts, at least for English projects.

On sites such as mediawiki.org, there's already a user interface(?) language switcher deployed to MediaWiki wikis. It's in an even more "top" and prominent place in the user interface. What happens with it? Is this proposal to have two language switchers at the top of every page? --MZMcBride (talk) 07:23, 13 December 2019 (UTC)

Be bold!
Hi, I just came across this again and just wanted to say that I am very much looking forward to seeing the outcomes of this project. I invite you to be bold and change things as much as your research suggests. My hypothesis would be to at least halve the number of things a reader can click on on the top, to the left and at the bottom of an article body. :-) --Gnom (talk) 23:00, 14 December 2019 (UTC) Vector is 10 years old. Both the Internet (not only design or user interface) and research on users' behaviors have changed a lot and made progress since then. I see no reason for being so last century. Tar Lócesilion (queta) 01:44, 19 December 2019 (UTC)
 * +1 to that. The simplest feedback I can give is just: be bold. Dare to follow your research.

Newsletter for the Desktop Improvements project
Will there be a newsletter for this project? ↠Pine ( ✉ )  20:45, 19 December 2019 (UTC)

Hamburger menu and icons
Hi, so you asked if the hamburger menu is internationally recognised -- it is not. There are research that say you should have either both hamburger and text or just text saying "menu".

Also note that although I agree the sidebar menu is cluttered to an average user, if you will hide it the interactions will regress. I'm guessing you know that, this has been said a lot (e.g. by Luke Wroblewski). I just want to stress this point. If there is anything you want readers to click then move it out of the sidebar. Some community link perhaps? Some kind of indication showing there is more to Wikipedia.

Some links:
 * https://www.nngroup.com/articles/hamburger-menus/ -- about hiding navigation in general. This studies confirms that what is out of sight will rarely be used if ever.
 * https://www.lukew.com/ff/entry.asp?1945= -- "Obvious Always Wins"; "out of sight, out of mind". Mostly visual article that interactions die when menu is hidden and thrive when it is shown.
 * https://axesslab.com/icons-ruining-interfaces/ -- this is a story about how icons we think are obvious... Are not obvious 😉.
 * https://www.nngroup.com/articles/icon-usability/ -- icons usability by NN Group. I like this rule of thumb especially: "Use the 5-second rule: if it takes you more than 5 seconds to think of an appropriate icon for something, it is unlikely that an icon can effectively communicate that meaning.".
 * https://web.archive.org/web/20170721011927/https://sitesforprofit.com/mobile-menu-abtest -- best for last. This is a study about this specific case -- conversion rate for different type of menu buttons (icon, text, icon with text, text with border).

As you can see I'm quite interested in the topic 😉.

Cheers, Nux (talk) 23:43, 2 January 2020 (UTC)