Community Wishlist Survey 2017/Mobile and apps

Mobile and apps
18 proposals, 204 contributors

Wikimedia projects automatic reader

  • Problem: Wikimedia projects contains are until now and exepted with Kiwix mobile app only readable and not audible. However, lisening theses project contain could be very usefull for people from glogal south knowing western langage but unable to read it. It could be also a wonderful opportunity for every body to listen projects contains in public transport or traffic jam.
  • Who would benefit: Every user of Wikimedia projects
  • Proposed solution: Implement a text to speak engine on the wikimedia projects mobile app.
  • More comments:
  • Phabricator tickets:

Discussion edit

I consider this to be a built in feature of most phones these days. Could be easily added to the app I think ? Adding to mobile web is harder. —TheDJ (talkcontribs) 12:25, 9 November 2017 (UTC)Reply[reply]

There is already some work in progress (see mw:Wikispeech), though not for some app. --AKlapper (WMF) (talk) 15:23, 10 November 2017 (UTC)Reply[reply]
Would be nice to have a "listen" button beside the read button on the desktop version. Doc James (talk · contribs · email) 22:09, 13 November 2017 (UTC)Reply[reply]
@Doc James: You can try out Wikispeech here. Although on labs the player is always activated, I remember our plans were to activate it exactly by a "listen" button like you envisioned (although plans might have improved since I was involved). Ainali (talk) 11:09, 15 November 2017 (UTC) Hi!Reply[reply]
Thanks for the questions and suggestions! Yes, we do plan to have a "listen" button on Wikipedia.
Wikispeech works on browser in mobile, but currently not the mobile view and we have not worked to include it in the app. We do however hope to work on that later. We would much appreciate your endorsements here. John Andersson (WMSE) (talk) 11:06, 23 November 2017 (UTC)Reply[reply]

Agree with TheDJ for mobile apps its best to use the built in screen readers. Users understand how to use them, they are well supported and most sight impaired users would not know to look for a "special" button or link. However, integrating Wikipeech on web (especially desktop) might be useful. -- JMinor (WMF) (talk) 19:09, 20 November 2017 (UTC)Reply[reply]

Voting edit

Categories shown in the 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.
  • More comments:

Discussion edit

Voting edit

Infobox pictures in the app don't match those on web

  • Problem: On the mobile app, pictures in the intro of articles like The Hague or Amsterdam are not shown and captions do not match what there user sees.
  • Who would benefit: Everyone
  • Proposed solution: Find a technical solution to render the same "montage" as on the desktop version.
  • More comments:
  • Phabricator tickets:

Discussion edit

Voting edit

Navigation template on mobile

  • Problem: Navigation template aren't visible on mobile.
  • Who would benefit: Everyone.
  • Proposed solution: Allow everyone to read navigation template. ¯\_(ツ)_/¯
  • More comments: I don't understand why navigation template can't be see on mobile when infobox can be see ? I ask why on wp:fr, and some users answer me that is only can be resolve by dev...

Discussion edit

Voting edit

VisualEditor has limited functionality on mobile

  • Problem: In the mobile Visual Editor some functionality cannot be used or can only be used to some limited extent. That's because the menu does not offer all functionality. Furthermore, the following items are cut: Some toolbars, the "formatting" menu. Furthermore the menu gets into the way for tables.
  • Who would benefit: Users of mobile VE
  • Proposed solution: Make the displayed items in the toolbar dynamic and hide other entries under "...". Also include the "desktop only" elements.
  • More comments:
  • Phabricator tickets:

Discussion edit

Translation: In the mobile Visual Editor some functionality cannot be used or can only be used to some limited extent. That's because the menu does not offer all functionality. Furthermore, the following items are cut: Some toolbars, the "formatting" menu. Furthermore the menu gets into the way for tables. Proposal: Make the displayed items in the toolbar dynamic and hide other entries under "...". Also include the "desktop only" elements. --AKlapper (WMF) (talk) 00:19, 20 November 2017 (UTC)Reply[reply]

@Honischboy: Auf welche Bildschirmweite bezieht sich dies? Ich kann das Problem nur reproduzieren unter 360px Weite. Und wie genau stoert das Menu bei Tabellen die Sicht? / Which display width does this refer to? I can only reproduce with less than 360px width. And who exactly does the menu get into the way for tables? --AKlapper (WMF) (talk) 00:19, 20 November 2017 (UTC)Reply[reply]
Es ist ein ZTE Blade L5 und hat eine Bildschirmgröße von 480 x 854 Pixel ( Das Problem kam übrigen erst, als auch bei kleinen Bildschirmen die Schaltflächen - beschriftungen angezeigt weren “mussten”. --Honischboy (talk) 18:12, 21 November 2017 (UTC)Reply[reply]
Das Menü bei Tabellen stört mir die Sicht, indem es so weit vom Oberen Bildschirmrand “Herunterhängt”, dass ein großer Teil des Bildschirms davon abgedeckt ist. Ich kann auch ein paar Screenshots davon senden. --Honischboy (talk) 18:12, 21 November 2017 (UTC)Reply[reply]

Voting edit

Mobile app for sister projects

  • Problem: Now exists Wikipedia mobile application (Android). But all links to sister projects like Wikiquote, Wikisource or Wiktionary must be opened using browser.
  • Who would benefit: All mobile users
  • Proposed solution: Rewrite current app or make new one which will support other Wikimedia projects too.
  • More comments:
  • Phabricator tickets:

Discussion edit

  • I wonder whether it would be a better investment to concentrate on making MediaWiki more functional in mobile web browsers than on making apps for different platforms. Anomie (talk) 13:11, 7 November 2017 (UTC)Reply[reply]
Great idea with supporting more platforms. I feel the new Iphone for Wikimedia app that now supports Forced touch or 3D touch is an argument for native applications. I can see this Forced touch as a new possibility to navigate a link and have more targets that would open up new very interesting possibilities that current mobile web browser cant. As more and more people use smartphones and the smartphone also makes it much more important to getting relevant information based on the users current location I think native apps are prefered as long as the mobile web interface has less functionality... - Salgo60 (talk) 10:52, 17 November 2017 (UTC)Reply[reply]
  • Endorse. I miss app for Wikivoyage and Wikisource for example. Doesn't matter if there will be separated or generic app. --Venca24 (talk) 08:53, 16 November 2017 (UTC)Reply[reply]
  • This may be out of the Community team's ability to deliver, given that app development is a specialized skillset. I'd look to the Commons app on Android as a the best example of how to make this happen. That project is volunteer owned, with support from a Foundation grant, and occasional consultation with the Foundation's Android team. --JMinor (WMF) (talk) 18:57, 20 November 2017 (UTC)Reply[reply]
I verry much understand and agree to JMinors concerns. Instead the MobileFrontend for mobile view should be further developed and optimized for all projects (e. g. making Categories accessible in the sister projects, making accessible Wikitext syntax highlighting to the same time as in the desktop version, highlighting unseen changes in the watchlist, etc.). Such improvements would be accessible from all devices so anyone could benefit form them and the mobile solution of wikimedia would behave similar on diffrent devices/OS. The development of excellent and fullscale open platform solutions should be priorititzed to walled garden applications by wikimedia staff. Of course volunteer projects are always welcome. --X:: black ::X (talk) 14:13, 14 December 2017 (UTC)Reply[reply]

Voting edit

Syntax highlighting for code snippets in mobile app

  • Problem: No syntax highlighting while reading articles with code or Lua modules in the Wikipedia mobile application
  • Who would benefit: anyone using the Wikipedia mobile app
  • Proposed solution: simply integrate syntax highlighting in the code surrounded by <code/>
  • More comments: none
  • Phabricator tickets:

Discussion edit

  • I created a ticket for this problem. phab:T180332 (Forgot to sign this before —TheDJ (talkcontribs))
  • This is something the Android app team has looked into, and there is a basic prototype. Generally, the challenge here is around performance (ie. making the highlighting be quick enough to be useful). But overall this is something we'd all like to see in the apps. JMinor (WMF) (talk) 18:54, 20 November 2017 (UTC)Reply[reply]
    • @JMinor (WMF): I think this is asking for non-WikiText syntax highlighting, i.e. for code snippets or Module pages. Ryan Kaldari (WMF) (talk) 21:43, 20 November 2017 (UTC)Reply[reply]
      • Oh, thanks Ryan Kaldari (WMF) I should have read more carefully. In that case I think the ticket linked is the right way to go.
        • That was my understanding as well. The ticket that I opened already has a patch by the apps team to include the missing styling into the app bundle. —TheDJ (talkcontribs) 14:44, 21 November 2017 (UTC)Reply[reply]
  • The ticket linked above has been completed (for Android) and will be deployed with our next release. Wish granted! DBrant (WMF) (talk) 19:59, 28 November 2017 (UTC)Reply[reply]

Voting edit

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.
  • Who would benefit: Editors checking their watchlist 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:

Discussion edit

Endorse --BugWarp (talk) 13:16, 10 November 2017 (UTC)Reply[reply]

Voting edit

View old revisions with mobile site

  • Proposed solution: Provide a way to view past revisions.
  • More comments:
  • Phabricator tickets:

Discussion edit

You mean: "Make it possible to navigate to the old (or new) revision from the diff page" ? instead of only being able to navigate to the previous and the next diff. —TheDJ (talkcontribs) 14:21, 18 November 2017 (UTC)Reply[reply]

@Don't kross my dross: See question above, thanks. Quiddity (WMF) (talk) 21:35, 20 November 2017 (UTC)Reply[reply]

In essence, yes. I want to see both the changes themselves (already possible via the diff) and the effects those changes had on the article (by viewing an old revision and comparing it with another revision, which is currently impossible). Whether these things appear together on the one page or separately is really a matter for the design team. Access would be from the page history (and/or the diff view, if it was provided separately). Don't kross my dross (talk) 05:35, 22 November 2017 (UTC)Reply[reply]

Voting edit

Make it possible to add coordinates through the app

  • Problem: Many articles still don't have coordinates. They are also difficult to add in their templates or in Wikidata, due to long numbers. Meanwhile, most editors carry around a GPS with decent quality.
  • Who would benefit: In the end, readers, but target group is editors.
  • Proposed solution: Make it possible to add or correct coordinates to an article through the app. If there are no coordinates on Wikidata, it should also add them there. Preferably, the app should display on a map what coordinates are going to be added, and that should be possible to fine-tune to make up for bad receptions or places where it is difficult to actually stand on the subject.
  • More comments:
  • Phabricator tickets:

Discussion edit

  • Foursquare/Swarm has a nice UI for this, when you add a new venue to their system. Does that look like what you would want for Wikimedia ? —TheDJ (talkcontribs) 14:19, 18 November 2017 (UTC)Reply[reply]
    • Yes, that looks pretty good (but I don't think this should be a way to start new articles or items, just adding coordinates to existing ones). Ainali (talk) 15:36, 18 November 2017 (UTC)Reply[reply]

Voting edit

Add CentralNotice to the apps

  • Problem: I´m not sure, but I have never seen a CentralNotice in the android-app. If 50% of all users are going to Wikimedia by smartphone, I think, there should be some kind of CentralNotice too.
  • Who would benefit: Wikimedia
  • Proposed solution: Create a CentralNotice for the app or maybe use the notification system.
  • More comments:
  • Phabricator tickets:

Discussion edit

According to phab:T145830, there seems to be an "announcements feed service" in place, but that seems to be focused on surveys and donations. --AKlapper (WMF) (talk) 10:09, 7 November 2017 (UTC)Reply[reply]

It seems to be some thingy which is enabled by direct editing of which leads to API like return that announcement and mobile apps grab and show it. As a Meta-wiki admin (thus having CentralNotice management rights) I have access to none of the things needed to use that service. Well, just to make it more obvious than it is. --Base (talk) 19:18, 15 November 2017 (UTC)Reply[reply]

@Seddon (WMF): You're the expert.  ;-) Whatamidoing (WMF) (talk) 18:29, 7 November 2017 (UTC)Reply[reply]

For a bit of context, the system Base points to is a very simple announcement system we developed to recruit testers, announce new features and test mobile fundraising by inserting cards into the mobile Explore feed. It is not intended to replace CentralNotice, but serve as a stopgap to allow us to have some basic communication with app users. We (the apps teams) fully endorse mobile appropriate support for CentralNotice in articles across apps. Unfortunately its not something we can build ourselves. Currently the Fundraising Tech team (with Seddon as sherpa) is defining requirements for an improved CentralNotice, which will hopefully include support for apps. JMinor (WMF) (talk) 19:04, 20 November 2017 (UTC)Reply[reply]

Site notice too please not only central notice. Afaik site notice content is editable by wiki sysops. Gryllida 01:00, 4 December 2017 (UTC)Reply[reply]

Yes, it is. It is located at MediaWiki:Sitenotice (and MediaWiki:Anonnotice for only logged-out users). —Tacsipacsi (talk) 13:06, 4 December 2017 (UTC)Reply[reply]

Voting edit

Permanent opt-out of mobile frontend

  • Problem:

A number of Wikimedians like myself use only desktop version of Wikimedia projects while on mobile.

I do it since I had a 208×208 display Symbian smartphone and I do it still when I have an Android touch screen with much bigger display.

The reason I do it is because I want to have the same experience as on desktop, because for me it is important to have access to all the tools and features (e.g. article deletion; CentralNotice administration; user blocking; rollback; flagged revisions; user scripts and styles for fast image tagging, RfD creation, disambig highlighting; and so forth) the same way I do when browsing from a desktop machine. Even for normal reading the folded sections in Minerva skin provide not the best experience, especially for looking up some information with browser Find feature.

This yields to the result that by far the most useful feature of mobile frontend is the "Desktop" link, which is hard to click on (related articles load late and I end up clicking on them), which does not always work (I regularly have an error claiming I need to enable cookies to toggle while they are enabled), which is unaccessible while on watchlist and which is just unnecessary step to do. It also has to be followed on each wiki or every time after following Google search results. The thing to keep in mind that it often has to be done while on mobile data which are not always unlimited and cheap.

  • Who would benefit:

Users who prefer desktop experience on mobile devices.

  • Proposed solution:

Add a "force desktop view" option to preferences. This should allow to disable mobile front-end permanently for the user account. This should also make links like direct to desktop version (that's what Google gives in search results).

Optionally provide an alias to &useskin=minerva which will show current page in mobile view (possibly in current selected mobile skin when we have not just minerva)

  • More comments:
  • Phabricator tickets: I need help looking them up, I am pretty sure there were some

Discussion edit

My editing is done exclusively on my phone (as it is my only internet connection), but prefer the desktop view because of the tools & scripts available in desktop. (Why does mobile = limited functionality?)

Further to my frustration is that Wikipedia doesn't comply with my browser's request desktop mode preference. Maybe start with that. Senator2029 talk 23:59, 16 November 2017 (UTC)Reply[reply]

@Senator2029: Which browser/platform is this? I just tried Chrome/Android and it correctly didn't redirect. Max Semenik (talk) 07:31, 17 November 2017 (UTC)Reply[reply]
I'm using Chrome in Android and if I pull up an article in mobile view and use the browser's "Request desktop site" I don't get the desktop version (it doesn't redirect to the non-mobile version); I get a variant of the mobile version with no sidebar. Editing a page or section uses the mobile editor. Ca2james (talk) 05:26, 18 November 2017 (UTC)Reply[reply]
I also regularly get redirecting errors when going between article pages, and other pages like History/talk, and frequently having trouble getting to the desktop versions of those pages on my phone. I would appreciate a session-length opt-out like this. Sadads (talk) 07:43, 23 November 2017 (UTC)Reply[reply]
what/where/who/wtf is «Browser's "Request desktop site"»? Sounds interesting. Sometimes - increasingly more I'm afraid - I follow a link to the mobile version and they look quite bad/poor on desktop. So any auto-magically fixing that would be good for readers, I guess. - Nabla (talk) 15:08, 2 December 2017 (UTC)Reply[reply]
Interestingly, for the opposite (always use wikipedia-mobile-frontend), there is at least a Chrome Extension called Wikipedia-Mobile-4-Ever on w:en:GitHub. --X:: black ::X (talk) 14:30, 14 December 2017 (UTC)Reply[reply]

Voting edit

Watchlist in mobile

  • Problem: It's not possible to see the watchlist in the official Wikipedia app for Android.
  • Who would benefit: Editors
  • Proposed solution: Implement an access to Watchlist in mobile apps.
  • More comments:

Discussion edit

I've been wanting this for a while. I don't really have a use for the mobile app without a watchlist so I bookmarked a link to the page on my phone's homescreen for the time being. Semmendinger (talk) 21:11, 8 November 2017 (UTC)Reply[reply]
I also think that this would be very useful Nick-D (talk) 06:09, 9 November 2017 (UTC)Reply[reply]

It is very important that anyone can edit on mobile app, it is a very important point in a phone's world Nirmal Brar Faridkot (talk) 13:52, 9 November 2017 (UTC)Reply[reply]

Endorse--BugWarp (talk) 13:18, 10 November 2017 (UTC)Reply[reply]
@BugWarp: The voting phase has not started yet, so I changed your "Support" into "Endorse" to avoid misunderstandings. --AKlapper (WMF) (talk) 15:18, 10 November 2017 (UTC)Reply[reply]

The apps teams are also interested in Wathchlist support. Its a technically challenging problem, and we would like to see cross-wiki watching supported (since the apps are cross-wiki by nature), but we agree/support this suggestion. -- JMinor (WMF) (talk) 19:13, 20 November 2017 (UTC)Reply[reply]

At least the problem that unseen changes aren't highlighted in the watchlist of the mobile version of wikipedia (mobile view) (as stated by Tacsipacsi below) should be solved, so that there is a proper and functional solution for users of mobile devices. --X:: black ::X (talk) 13:39, 14 December 2017 (UTC)Reply[reply]

Voting edit