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)

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)

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.