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[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[reply]

Voting

Display interproject links on mobile

  • 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[reply]

Discussion

  • I'm fairly certain inter-language links can already be accessed in mobile. I could be wrong. --Izno (talk) 00:34, 9 November 2018 (UTC)Reply[reply]
    Izno : interlanguage links yes (enwiki, dewiki, ruwiki, etc.), but not interproject links (Commons, Wiktionary, etc.). Lofhi (talk) 08:03, 9 November 2018 (UTC)Reply[reply]
  • @Lofhi: This is unlikely to be in the top ten, but your wish is already being developed as part of overhaul of mobile editing. –Ammarpad (talk) 05:51, 19 November 2018 (UTC)Reply[reply]
    Ammarpad : I think the functionality may be too discreet, but it's better than nothing! Thanks for the info. Lofhi (talk) 18:05, 19 November 2018 (UTC)Reply[reply]

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[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[reply]

Bencemac what about viewing [1] on mobile (using Timeless skin)? --Gryllida 07:34, 23 November 2018 (UTC)Reply[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[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[reply]

I thought everyone with "edit" right can also revert on desktop? --Dvorapa (talk) 21:36, 29 October 2018 (UTC)Reply[reply]
  • Endorse: I would have proposed the same. Sheriff | ☎ 911 | 01:46, 4 November 2018 (UTC)Reply[reply]
  • Endorse --Patriccck (talk) 09:15, 4 November 2018 (UTC)Reply[reply]
  • Endorse, and if possible add a Rollback option as well for users who have it. The Thank function can go if there isn't enough space. Feminist (talk) 04:02, 7 November 2018 (UTC)Reply[reply]
  • Endorse, we also do need a button to move page in mobile view. CyberTroopers (talk) 13:54, 18 November 2018 (UTC)Reply[reply]
  • I've thought about this for a while and I oppose it. There's another proposal regarding the "fat finger" problem of accidentally thanking other editors, now someone wants to add an additional "fat finger" problem of accidentally undoing or even rolling back my edits. No thanks. You can revert my edit by editing the page to remove the bit you don't like; maybe it's good to slow down and think about what you're doing instead of banging buttons. Jacknstock (talk) 10:56, 20 November 2018 (UTC)Reply[reply]
  •   Comment I have created a JavaScript hack at en:User:FR30799386/undo which allows a user to do a undo an edit on mobile.FR30799386 (talk) 08:16, 29 November 2018 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[reply]
Will userspace subpages help?--Cohaf (talk) 21:18, 13 November 2018 (UTC)Reply[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

  • Endorse. Looks like almost everyone agrees to this idea. But do the Wikipedia mobile app technical team require more time to implement this? Chongkian (talk) 03:59, 5 November 2018 (UTC)Reply[reply]
  • Endorse. I would like to have categories shown in my mobile since when I bought it. I think categories are very useful for editors and readers, too. --Daniele Pugliesi (talk) 18:35, 5 November 2018 (UTC)Reply[reply]
  • Strongly support. This also applies to navigation templates, which showcase the main articles about a specific topic. --Joalbertine (talk) 20:07, 6 November 2018 (UTC)Reply[reply]
  • Endorse, and add them to the mobile website as well. Feminist (talk) 03:55, 7 November 2018 (UTC)Reply[reply]
  • I'm doubtful that readers (non-editing readers) spend much time looking in categories. I don't think that anyone has ever verified that readers notice the categories or use them. It might be interesting to see if we could get page view data split (logged-in vs logged-out) to determine whether the category system is worthwhile at all (to people who aren't editors like us, of course; I use it for editing purposes). WhatamIdoing (talk) 18:23, 26 November 2018 (UTC)Reply[reply]

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[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[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[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[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[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[reply]

Voting