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)

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)

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

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)