Community Wishlist Survey 2019/Mobile and apps

Mobile and apps
12 proposals, 228 contributors, 476 support votes
The survey has closed. Thanks for your participation :)



Bring Sitenotice to Mobile view

  • Problem: Wikipedia editing is growing up so fast these days due to easy accessibility to mobile. Mostly New editors, readers and information seekers get the mobile view while surfing wikipedia on Mobile devices. We on our wiki organise various new events and edit-a-thons every other month. The only way to get more editor's to edit is by the Sitenotice. Unfortunately wikipedia sites on mobile only show central notice by which we can't target a huge audience.
  • Who would benefit: Almost every mobile user will get the coverage of the notice that is going on in the desktop view. This will limit the bridge between the desktop version and mobile version and editors can get updated information about a wiki.
  • Proposed solution: Enabling a proper sitenotice for mobile. Similar and not marshy like the centralnotice
  • More comments:
  • Phabricator tickets:

Discussion

For the records: phab:T150391 implies that first of all, Sitenotice needs to be made mobile-friendly. --AKlapper (WMF) (talk) 14:53, 31 October 2018 (UTC)[reply]

wgMinervaEnableSiteNotice allows you to enable site notices on the mobile MinervaNeue skin and it already exists but is disabled by default. Any project can enable this via a site request. However, whoever enables it, needs to make sure their site notices are both mobile and desktop friendly as site notices can cause performance degradations and user frustration (usually vented on Twitter). I'd recommend installing some community best practices for editors managing the site notice, before doing that, but there's nothing stopping anyone from doing this now without any wikimedia input. Jdlrobson (talk) 23:00, 1 November 2018 (UTC)[reply]

Voting

  • Problem: our readers, who now read mainly Wikipedia with the mobile version, don't have easy access to the interproject links (sister project links?) of an article.
  • Who would benefit: more than half of the readers.
  • Proposed solution: give readers the opportunity to display interproject links such as interlanguage links.
  • More comments: on frwiki, we used the template Autres projets to display interproject links before Mediawiki takes care of them. Today, it still exists principally because the functionality is missing on mobile. Some contributors find that the template pollutes the footer of the articles and would like to delete it, which is not possible without impacting the readers' experience on the mobile version.
  • Phabricator tickets:
  • Proposer: Lofhi (talk) 21:12, 8 November 2018 (UTC)[reply]

Discussion

Voting

Support reverting/undoing accidentally sent thanks

  • Problem: On mobile, the risk of accidentally sending thanks by touching the big thank button is very high (“fat finger accident”). As many users reported, this could be very frustrating and can cause awkward moments. Different ideas to solve this are already existing (see the Phabricator ticket).
  • Who would benefit: every mobile user
  • Proposed solution: see the Phabricator ticket
  • More comments:
  • Phabricator tickets: T63737
  • Proposer: Bencemac (talk) 09:16, 11 November 2018 (UTC)[reply]

Discussion

A patch exists and just needs a review so if voted this is very doable!! Jdlrobson (talk) 20:41, 15 November 2018 (UTC)[reply]

Bencemac what about viewing [1] on mobile (using Timeless skin)? --Gryllida 07:34, 23 November 2018 (UTC)[reply]

@Gryllida: Most of us do not use Timeless (and do not want to, I guess). Bencemac (talk) 08:06, 23 November 2018 (UTC)[reply]

Voting

Add an undo/revert button to diff view

  • Problem: The mobile web diff view features an enormous 'thank' button at the bottom of the screen. Sadly, I find myself reverting people far more often than I thank them. Quickly reverting a dodgy edit is the sort of quick editing that should work well on mobile. Unfortunately, the mobile interface makes this all but impossible without manually rewriting the text or zooming the view after switching to desktop interface.
  • Who would benefit: Editors checking their watchlist or recentfeed on their phones.
  • Proposed solution: Provide an undo button adjacent to the thank button. Undoing an edit would work the same way as on the desktop site - open the editing interface with the offending text removed from the source.
  • More comments: already proposed in 2017

Discussion

Should this be limited to users with "revert" rights for now, to gauge the effects?--Strainu (talk) 21:28, 29 October 2018 (UTC)[reply]

I thought everyone with "edit" right can also revert on desktop? --Dvorapa (talk) 21:36, 29 October 2018 (UTC)[reply]

Voting

Show categories on Commons mobile website

 
No category link here either.
  • Problem: When viewing a Commons image in a mobile browser, I can't see the image's categories. Let's say I want to see images of durians, I take my smartphone and launch a Google/etc search on the term "durian". The fifth result is a picture on Commons, I click it. The picture is OK but I am hoping for better pictures. If there was a "Durians" category link on that page, I could click it and browse all durian pictures on Commons.
  • Who would benefit: Mobile users who are viewing an image and want to see similar images.
  • Proposed solution: Show category links.
  • More comments: Please note that this is about the mobile version of the website. The Commons native Android app already has this feature.

Discussion

Hi Syced. If you click through to Commons from Google (using the "Wikimedia Commons" button), then you are able to click on the "Durians" category, in your example. So do I understand that what you're looking for is a link to the category directly from the Google Images page? Please clarify.—JMatazzoni (WMF) (talk) 15:30, 31 October 2018 (UTC)[reply]

JMatazzoni (WMF): Please let me know where on this page (see the 2 screenshots) is the link you are talking about, thanks! Syced (talk) 01:45, 1 November 2018 (UTC)[reply]
@Syced and JMatazzoni (WMF): The button for categories is only presented for users that are logged in AND have the Mobile beta setting enabled. I do note that most non-wikimedians have no idea how our category system works btw, so they aren't going to find other durians that way. See also: https://wikimediafoundation.org/2018/10/29/george-oates-conversation/ where it is noted: "She noted how the category system used to organize and tag media files on Commons is confusing and hides—not shows—the richness of content there." —TheDJ (talkcontribs) 15:51, 1 November 2018 (UTC)[reply]
Hey, thanks TheDJ. You are right, that Categories link shows only if you are logged in and have the beta activated (I didn't realize I had done that). Also, I'd thought there was a link directly to the category, but in fact I was looking at something else (the image happened to be the main image on the Durians category page, so there was a link directly to the category). The typical experience is that you have to click a "Categories" button and then find the relevant category and click on that. All of which is to say that Syced is totally right. I'd like to see a prominent link to the categories on the main image page as well. —JMatazzoni (WMF) (talk) 17:12, 1 November 2018 (UTC)[reply]
As the TheDJ mentions, this feature is currently only available if you have the mobile beta mode turned on. The only reason it hasn't been enabled for everyone yet is that the feature still has a few bugs (see task T24660). Thus fulfilling this wish would basically mean fixing those bugs and then releasing the feature to everyone. Kaldari (talk) 17:15, 1 November 2018 (UTC)[reply]
+1 to that... this is actually a very actionable wishlist item, that could be fulfilled with enough votes. Happy to provide details of what's needed there, if necessary. Jdlrobson (talk) 22:16, 1 November 2018 (UTC)[reply]
While I agree that categories are confusing and sometimes hide good pictures (for instance the durian picture that fits my needs best might be in "Monochrome photographs of Surabaya durians in 2015"). But still, it is the best navigation system we have, so we should not remove that feature. Let's not assume that non-logged-in people (=me most of the time, especially on mobile) can not fathom the "complexity" of a category page. Maybe the key to making categories more useful for everyone is to make them display the best pictures with that category and its sub-categories, rather than pictures that have not been categorized further (FastCCI could be key to implementing that technical change), but that's a whole other kettle of worms. Syced (talk) 03:37, 2 November 2018 (UTC)[reply]

Voting

Save button to save the unfinished content for a new page

  • Problem: As the number of editors on Wikipedia mobile continues to grow, there exists a need for a save feature while creating new pages on Wikipedia mobile as creating a new page can take days and one needs to save their content for which they worked hard on.
  • Who would benefit: This would benefit almost every registered user on Wikipedia as this would prevent loss of content by accidental closing of the app/browser on which the editor is logged on. It will also prevent the loss of content due to reloading of pages.
  • Suggested Solution: a save feature should be added to the mobile version of the Wikipedia just like it's added on the desktop version of Wikipedia so that editors on the mobile version can conveniently create new pages whilst being on the phone.
  • Phabricator tickets:
  • Proposer: U1Quattro (talk) 03:08, 5 November 2018 (UTC)[reply]

Discussion

mw:Extension:Drafts exists, though I'm not sure if that supports mobile. --AKlapper (WMF) (talk) 12:26, 5 November 2018 (UTC)[reply]

It doesn't work for mobile. That is what I'm suggesting. It should work for mobile. U1Quattro (talk) 16:56, 5 November 2018 (UTC)[reply]
Will userspace subpages help?--Cohaf (talk) 21:18, 13 November 2018 (UTC)[reply]

Voting

Show categories in the Wikipedia app

  • Problem: Wikipedia editors spend a significant amount of time categorizing pages so that relevant pages can be quickly found. Not having access to these categories puts mobile app users at a significant disadvantage over desktop users. As more users in the developing world come online, they are missing a critical part of articles, especially if they start editing the encyclopedia. In addition, people are switching to mobile at a rapid pace, so feature parity with desktop sites are critical.
  • Who would benefit: Mobile app users (both readers and editors)
  • Proposed solution: Add a list of categories that article is in at the bottom of the article as a list. Also, create a navigation link to access these categories along with the article's sections.

Discussion

Voting

Make copy/paste functions easier tablets and phones

  • Problem: it’s quite a pain to copy/paste on iPads/tablets and phones. Most of the time, you have to scroll through everything to select and copy them, and it’s quite painful especially if they’re modules. This technique takes longer and sometimes causes the devices to freeze and the browsers to crash. It would be amazing to have a button that would automatically select and copy the content of the templates/modules installed by default.
  • Who would benefit: everyone who uses phones and tablets to contribute
  • Proposed solution: add a button that automatically selects and copies the content of the mentioned pages.
  • More comments: There is a a Mobile Copying and Pasting discussion topic at MediaWiki, created by Whatamidoing (WMF).
  • Phabricator tickets:
  • Proposer: ▸ épine talk 10:44, 4 November 2018 (UTC)[reply]

Discussion

@Épine: Could you please explain why you have to copy and paste the content of a page so often on tablets or phones? I'd love to understand better the underlying problem to solve. --AKlapper (WMF) (talk) 00:48, 5 November 2018 (UTC)[reply]

@AKlapper (WMF): when moving modules and templates to smaller wikis, it is necessary to copy from the source obviously. I contribute to multiple projects and the issue is site-wide.--▸ épine talk 08:49, 5 November 2018 (UTC)[reply]
Obviously this is a problem faced by mobile users, and yes I am typing this using my phone. FYI, I written DYKs using phone. Copying can be a hassle, especially for major editing of articles or even AFD where sometimes multiple articles are nominated with the same reason but not bundled together and the interface really makes it a chore to copy your rationale multiple time. However, I don't think this is a site issue but rather hardware issue, your mobile phone OS does play a role in the ease of copy and paste. My 2 cents.--Cohaf (talk) 19:36, 16 November 2018 (UTC)[reply]

I face this problem all the time when I travel and use my phone to edit, as I can't access my laptop. --Мурад 97 (talk) 11:29, 18 November 2018 (UTC)[reply]

The main problem I have is with scrolling while editing. Sometimes the whole page scrolls instead of only the edit box, which makes editing frustrating! Sometimes I have to switch to desktop view just to complete an edit. Erzahler (talk) 23:55, 22 November 2018 (UTC)[reply]

Voting

Offer different wikitext editors including non-JS editor

  • Problem: Currently there are numerous problems I encountered when I try to use mobile browser to edit wiki when I use the default mobile web editor. For instance:
    1. When editing an article and then the browser page get removed from memory due to lack of memory, text typed in javascript-generated editor would not be remembered by the browser, however text typed in traditional text field would be
    2. The current default mobile web editor cannot be used to edit a partially prefilled form on wiki like this community wishlist survey
    3. The "insertable wikimarkup" thing is a bit hard to access on the default mobile web editor.
  • Who would benefit: Everyone who edit on mobile phone
  • Proposed solution: These can be fixed by allowing users to change the mobile editor themselves or by changing the default editor for everyone
  • More comments: The first point in the problem I mentioned is an inherent limitation caused by dynamically generated pages and apparently cannot be fixed by patching the existing editor and thus a change would be needed

Discussion

Did you try the timeless or monobook skin C933103? They are getting more mobile friendly particularly timeless, and may partly address your issues? Gryllida 22:48, 30 October 2018 (UTC)[reply]

Voting

  • Problem: The mobile version of the site doesn't have interlanguage links. With mobile, I sometimes enter a Finnish Wikipedia article with Google and notice it's a stub, and I have to switch to the desktop version just to access the English Wikipedia.
  • Who would benefit: Especially people who speak a language that doesn't have a large Wikipedia.
  • Proposed solution: Enable interlanguage links.
  • More comments:
  • Phabricator tickets:
  • Proposer: Pudeo (talk) 14:08, 3 November 2018 (UTC)[reply]

Discussion

Interlanguage links are available on the mobile web. Just below the article title is this button, which will bring up the list of interlanguage links. I do think that the menu is not as obvious as it should be. Rchard2scout (talk) 15:19, 3 November 2018 (UTC)[reply]

I see. Well, that's not obvious at all (the symbol is cryptic), but glad the feature exists. There seems to be a lot of space next to it, so maybe they should clarify it with "other languages" or something. --Pudeo (talk) 15:23, 3 November 2018 (UTC)[reply]
Ping User:jdlrobson, exactly what I told you during our last meetup. Part of this probably has to do with the fact that desktop doesn't use icons like this.... Difficult problem to solve in my opinion. —TheDJ (talkcontribs) 10:45, 5 November 2018 (UTC)[reply]
yeh we are completely aware of this problem. If it was up to me I'd add a language link in the footer which when clicked scrolls you to the top and points at the language button. People searching the page would then find it. We used to do something similar when transitioning in the new language button. Jdlrobson (talk) 20:43, 5 November 2018 (UTC)[reply]
Side note, we do have some data that compares an older treatment (a button at the bottom of the page) with a new treatment @ phab:T128917#2120680. Maybe there's a wishlist ask here to help with discoverability of these features (I've seen similarly phrased requests for talk and categories which are also in the mobile UI if you know where to find them) Jdlrobson (talk) 21:57, 5 November 2018 (UTC)[reply]

Voting

Add a citation option to mobile editing

  • Problem: Mobile editors are not able to add citations, they have to use the desktop version of Wikipedia in order add a reference.
  • Who would benefit: Mobile editors
  • Proposed solution: This proposal will add an option to make a citation while editing on the mobile site.
  • More comments:
  • Phabricator tickets:
  • Proposer: ParadiseDesertOasis8888 (talk) 00:52, 4 November 2018 (UTC)[reply]

Discussion

Voting

Show navboxes on mobile website and app

  • Problem: Navboxes are a common way to link between related topics on articles. These are not shown on the mobile view, limiting the ability of readers to browse related topics.
  • Who would benefit: Readers and editors
  • Proposed solution: Show navboxes on the mobile app and web view. Use side scrolling if there is not enough space, similar to how tables are handled.
  • More comments:
  • Phabricator tickets: T124168
  • Proposer: Feminist (talk) 04:18, 7 November 2018 (UTC)[reply]

Discussion

Voting