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)

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)

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)