Jump to content

Community Wishlist Survey 2017/Mobile and apps

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2017
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 (talk • contribs) 12:25, 9 November 2017 (UTC)[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]
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]
@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]
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]

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]

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

@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]
Es ist ein ZTE Blade L5 und hat eine Bildschirmgröße von 480 x 854 Pixel (https://www.inside-handy.de/handys/zte-blade-l5/daten). 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]
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]

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

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]

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]

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 (talk • contribs) 14:21, 18 November 2017 (UTC)[reply]

@Don't kross my dross: See question above, thanks. Quiddity (WMF) (talk) 21:35, 20 November 2017 (UTC)[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]

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]

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]

It seems to be some thingy which is enabled by direct editing of https://phabricator.wikimedia.org/diffusion/GMOA/browse/master/routes/announcements.js which leads to API like https://en.wikipedia.org/api/rest_v1/feed/announcements 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]

@Seddon (WMF): You're the expert.  ;-) Whatamidoing (WMF) (talk) 18:29, 7 November 2017 (UTC)[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]

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]

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]

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 en.m.wikipedia.org 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]

@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]
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]
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]
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]
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]

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]
I also think that this would be very useful Nick-D (talk) 06:09, 9 November 2017 (UTC)[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]

Endorse--BugWarp (talk) 13:18, 10 November 2017 (UTC)[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]

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]

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]

Voting

[edit]

LinguaLibre's audio learning mobile app

Example of UI for multimedia dictionary.
  • Problem: The Wikimedia project http://LinguaLibre.fr (github • live by 0x010C) allows non-wikimedians volunteers to records hundreds of words in their languages very efficiently. Yet, these audios moving to the wiktionary, a tangible end-product with these hundreds audios datasets hardly materializes for the volunteer speakers and non-wikimedians.
  • Who would benefit: Larger public and wikimedians. Boost volunteer speakers motivation by providing immediat materialization of their recording efforts.
  • Proposed solution:
    ➊ Develop a template dictionary HTML/CSS/JS web app in the line of this very recent French Sign Language app (github • live by Lyhana8) or this Chinese Vocabulary app (github • live by myself).
    ➋ Implement technical solution so this template + other dataset from lingua libre = variation of the app with this other data set.
    ➌ Embed web app code via PhoneGap Build or alike so to produce and publish language-specific mobile apps, soon after recording sessions.
  • More comments: Other technical ways are welcome, but we need to have a "learning-this-dataset app" or "learning-this-dataset webpage".
  • Phabricator tickets:

Discussion

[edit]

Voting

[edit]


Better categorization from Commons Mobile

  • Problem: Categorization in the mobile app is available, but not particularly explorable. Users in the web interface can use HotCat to explore the category tree, but the mobile web interface doesn't allow that either.
  • Who would benefit: Mobile users uploading pictures to Commons.
  • Proposed solution: Enhance the categorization activity in the Commons app to allow HotCat-style exploration of selected categories. (Mainly navigation from parent categories to child categories and vice versa.)
  • More comments: When uploading via the Commons app, I find myself using a laptop to look up the proper categories for my photos. It means that I can't upload pictures unless I'm at my computer, which mostly defeats the purpose of the mobile app.
  • Phabricator tickets:

Discussion

[edit]

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

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

Voting

[edit]

Add searchbar to Nearby

  • Problem: Special:Nearby only shows you the notable places around your current place. Further in the app if you want to change the location, you need to swipe all across the globe on the map. That is rather slow and inconvinent on small 4-5" devices.
  • Who would benefit: All users of Nearby.
  • Proposed solution: Please add a searchbar to Nearby so that we could all change places and find things in seconds. Would be great if we could do search according to a district/city/county or zipcode. (GPS coordinates would be fine, too.)
  • More comments:

Discussion

[edit]

Voting

[edit]

Enable video uploads from Commons mobile app

  • Problem: Still images can be uploaded from the mobile Commons app, but videos cannot be. Even if the app supported uploading video files, mobile devices take videos in non-free formats, usually H.264 in an MP4 container.
  • Who would benefit: Mobile users who take video.
  • Proposed solution: Phones generally take video in patent-encumbered MP4 format. The Commons app should include a copy of ffmpeg or an equivalent, and encode the video in the best available free format (at this point, WebM with VP9 and Opus) at a comparable bitrate at the appropriate quality. (See File:Front_loading_garbage_truck_loading_a_dumpster.webm, especially the 'Technical Details' field, for an example of this being done manually.)
  • Phabricator tickets:

Discussion

[edit]
  • How will the resulting flood of copyvios, social networking junk and other out of scope stuff be dealt with? To the best of my knowledge, there's no reverse video search engine. MER-C (talk) 04:23, 10 November 2017 (UTC)[reply]
    • @MER-C: That's a great question. Past discussions suggested significant ratelimits and/or trust bars (edit count, account age) being met. It could even be a requested permission to begin with. If copyvios and social networking junk aren't problems with the current Commons mobile uploads, I don't think they'll be a problem here. (See "This app has never been responsible for any copyvio/selfie-pocalypse" at the app's documentation page on Commons.) Grendelkhan (talk) 17:37, 10 November 2017 (UTC)[reply]
    • Video copyvios don't seem problematic; a mobile app is the most cumbersome way imaginable to upload those. Selfies etc. could be a problem, that depends on the design and the userbase of the app. Given the past history of the Commons app, there doesn't seem to be much cause for concern, though. --Tgr (WMF) (talk) 23:35, 19 November 2017 (UTC)[reply]

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

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

Voting

[edit]

Mobile app for editing and contributory actions

  • Problem: Многие посетители Википедии и братских проектов читают их через мобильные устройства, в особенности через смартфоны. К сожалению, сегодня и мобильное приложение, и мобильная версия сайта годятся лишь для обывательского чтения. Даже для продвинутого чтения они не годятся (невозможно увидеть скрытые категории, плашки, предупреждения и т.д.). Но через мобильные устройства могло бы быть удобно править вики "на лету". Можно было бы патрулировать статьи, выполнять административные действия, переименовывать страницы и т.д. Могло бы - потому что сейчас это либо неудобно, либо невозможно.
  • Translation: many Wikipedia and sister project visitors are reading them from their mobile devices, especially smartphones. Unfortunately, right now both the mobile app as well as mobile site are suitable only for casual reading. Even advanced reading is impossible as hidden categories, navboxes, warnings, etc are not accessible. But it could have been convenient to edit wikis on the go with mobile devices. We could have patrolled the articles, performed admin actions, moved pages, etc. "Could have" because at the moment it's either impossible or inconvenient.
  • Who would benefit: все редакторы википроектов, а особенно имеющие специальные права. Translation: all wiki editors, especially ones with elevated privileges.
  • Proposed solution: предлагается создать полноценное редакторское мобильное приложение. Основное его поле - окно для чтения и редактирования статей, при этом верхняя его часть должна быть оснащена кнопками "Действия над страницей" (по нажатии предлагаются варианты: править, отпатрулировать, переименовать, удалить, просмотреть историю, просмотреть сведения и т.д), "Обсуждение" (открывает СО статьи, можно принять участие в обсуждении) и "Меню" (открывает боковое меню, в котором находятся: список наблюдения, профиль участника, статистика вики, список неотпатрулированных страниц с фильтрами, настройки бота, действия над учётными записями, кнопка добровольных пожертвований и иные инструменты). Приложение должно иметь современный дизайн, общепринятый для мобильных приложений. Я думаю, у всех есть смартфон и все представляют, как должно выглядеть удобное и современное приложение. Если будет принято решение делать - могу вступить в команду разработчиков и принять участие в разработке интерфейса для него.
  • Translation: I propose to create a full-blown editing mobile app. Its main interface feature would be a window for article reading and editing, and above it there should be buttons for "Page actions" (upon pressing it you would would see options: edit, patrol, move, see history, see info, etc), "Discussion" (opens article talk pages so you could participate in discussions) and "Menu" (opens a sidebar menu that would have: watchlist, user profile, wiki statistics, list of unpatrolled pages with filters, bot settings, account actions, button for fundraising and other tools). The app should have modern design, using standard practices for mobile apps. I think that everybody has a smartphone so everybody should have an idea how a convenient and modern app should look. If a decision will be made to make it, I could join the development team and participate in development of interface for it.
  • More comments: допускаю перспективы дальнейшего развития приложения следующим образом:
  1. Функция "Локатор" - определяет местоположение и рекомендует к ознакомлению статьи Википедии и Викигида о достопримечательностях поблизости, а также показывает фотографии с Викисклада на карте (подобно приложению HINP для соцсетей).
  2. Геймификация работы над статьями. Сделал N правок - получи звёздочку "Редактор такого-то уровня". Написал N дизамбигов - получи значок "Неоднозначная личность". Отпатрулировал больше всех статей за день - получи эмблему "Патрульный-пулемётчик". Создал сколько-то статей - посмотри, сколько процентов участников написали больше тебя. Написал путеводитель родного города - получи статус "Краевед". Понравилась работа другого редактора - поставь ему плюсик. Это повысит интерес к редактированию и привлечёт новичков.
  3. Изготовление такого приложения как универсального средства для любого проекта на движке MediaWiki. Часть функций, возможно, придётся выпилить.
  • Translation: I can imagine the following future development of the app:
  1. Location feature, determines your location and suggests nearby Wikipedia and Wiktionary articles, also showing photos from Commons on the map (like the HINP app for social networks).
  2. Gamefication of article work. After you've made N edits you could get an "X level editor" barnstar. For creating N disambiguations you could get a "Disambiguous personality" sign. If you've patrolled more articles in a day than anybody else, get a "Machinegun patroller" badge. If you've created this many articles, you could see how many people have created more than you. If you wrote a guide to your hometown you could get a "Local expert" status. If you liked another editor's work, you could give them an upvote. This would increase the interest in editing and attract more novices.
  3. Make such app an universal tool for evey MediaWiki based wiki. Some features might have to be removed.
  • Phabricator tickets:

Discussion

[edit]

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

@BugWarp: The voting phase has not started yet, so I changed your "Support" into "Endorse" to avoid misunderstandings. --AKlapper (WMF) (talk) 15:25, 10 November 2017 (UTC)[reply]
@JMinor (WMF): Any thoughts on this? Ryan Kaldari (WMF) (talk) 22:04, 20 November 2017 (UTC)[reply]
In general the Foundation's apps teams would love to improve the editing capabilities, either of the existing app, or potentially through a "purpose built" app for editing and administration. Unfortunately neither the apps teams or nor the Community tech team is currently staffed to take on such a large and important project. That said, if this is in the top wishes, that would change the conversation and make it much more likely to get resourced adequately. -- JMinor (WMF) (talk) 23:05, 20 November 2017 (UTC)[reply]

I would prefer the mobile version of wikipedia (mobile view) to be optimized in a similar way. Such improvements would be acessible from all devices so anyone could benefit form them and wikipedia mobile would behave similar on diffrent devices. The development of excellent and fullscale open platform solutions should be priorititzed to walled garden applications. --X:: black ::X (talk) 22:40, 11 December 2017 (UTC), updated 22:41, 11 December 2017 (UTC) and 11:59, 12 December 2017 (UTC)[reply]

This proposal is about features which are currently only usable on mobile web, not in apps. So mobile web doesn’t have to be optimizes in a similar way, it already is. —Tacsipacsi (talk) 19:34, 12 December 2017 (UTC)[reply]
In the (englisch translation of the) proposed solution it says "[…] above it there should be buttons for "Page actions" (upon pressing it you would would see options: […] patrol, move, […] see info, etc) […] and "Menu" (opens a sidebar menu that would have: […] wiki statistics, list of unpatrolled pages with filters, bot settings, account actions, button for fundraising and other tools). […] [S]hould have modern design […]." I don't regard it as necessary to realize these proposed elements exactly like this, but I don't see the mobile version to have realized these or similar features in a quality more or less similar to the proposal. Especially if I assume that a modern design must be ergonomic, functional, easy to use and adaptable (to hadicaps, screens etc.) (e. g. highlighting unseen changes in the watchlist or even making accessibe Wikitext syntax highlighting to the same time as in the desktop version). --X:: black ::X (talk) 14:02, 13 December 2017 (UTC)[reply]
Sorry, I haven’t noticed these. Then I modify: this proposal contains elements which are already available on mobile web, so that ones don’t have to be optimized on mobile web, only in apps. —Tacsipacsi (talk) 18:16, 13 December 2017 (UTC)[reply]

Voting

[edit]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Mobile_and_apps&oldid=23947736"