The Signpost

Essay

Mobile editing

Contribute   —  
Share this
By Clovermoss

Sometimes, you hear about editors who edit on their phones. There are two main ways experienced editors edit using a mobile device: using desktop view on a mobile device[a] or using mobile view through a standard web browser. What you don't usually hear about are people who download the dedicated Wikipedia app on their mobile devices even if it is technically an option. As far as I know, I'm the only experienced editor who has tried to edit somewhat frequently with the Android version of this app. I don't have an iOS device so my observations may not be relevant in that context. While I have had brief experiences with the app before this essay, typically when editing on my phone I would use desktop view.

As an experienced editor, what stood out to me immediately was this:

I'm a 20-year-old with basically no understanding of computer science. My perspective is mostly from someone who has grown up in a world geared towards user friendliness and the Android Wikipedia app does not perform the way I've become accustomed to expect. While mobile view doesn't have the full functionality of desktop view, it functions much better in comparison. Despite all of this, the app has definitely grown on me over time. I'm glad that technical issues were fixed even if I was surprised that I had any sort of role in identifying them. I plan to keep using the app and seeing how it improves over time – I think it can get better and I'm cautiously optimistic after my experience interacting with WMF staff.

What it was like at the start

When I first started trying to edit through the app, what got to me most was the sheer frustration of it all. Very few things felt like they were intuitive, it was like learning how to edit all over again. The first thing that surprised me was that when I logged in, it automatically downloaded articles from when I briefly experimented with the app in 2019 because of a default setting to sync across devices, which makes sense in hindsight even if it caught me off-guard.

I tried to see if I could create this page through the app, it let me search existing subpages of my userpage but it would not let me create a page that did not yet exist. Once I had created this page in desktop view on Chrome, the page automatically loaded because I had previously searched for it. From a reader's perspective, I did not like the default way to browse functions. I didn't even realize there was a way to change this until JTanner (WMF) pointed it out to me. The default option mimics a web browser: unless you click "new tab", you have to click the back arrow x times (depending on how many links you have clicked) to get back to the main page or have the option to see your contributions. This felt clunky and unnecessarily frustrating from my perspective. A lot of things felt like that, honestly. Not exactly intuitive and things kept surprising me. It took me a few days to even notice that I could access my watchlist.

Screenshots

Since most people are not familiar with the app, here are some screenshots that demonstrate what it is like:

Technical issues

There was one time I spent 7 minutes trying to type two sentences and the text scrambled across the screen. The end result looked like a test edit: [1]. A previous time, this caused the app to freeze and crash.

I also noticed that whenever I tried to edit an AfD, it would cause the app to crash. I emailed a video documenting the issue since I could not figure out how to upload video to Commons. This actually had a larger impact than even I realized:

Hey there @Clovermoss, nice to meet you.

That crash didn't really have to do with participating in an AfD discussion, but rather with the native wikitext editing interface itself, regardless of which article is edited. The crash occurred when putting the cursor all the way at the bottom of the text and pressing Enter.

When building our native app, we care about squeezing every bit of performance from the Android platform, so that features like editing could be more responsive and usable than the web interface. This often involves some complex logic and system-level optimizations. And although we do as much testing as we can, the occasional crash can sometimes slip through. If you're curious, this is the exact change that fixed the crash. Interestingly, it was a single incorrect character of code that was causing the crash, not even a single line.

— DBrant (WMF), 15:09, 18 November 2022

I try my best to sympathize with people who are actually experienced in regards to technical matters. I don't understand the context or the underlying situation, so to some extent it's impossible to truly understand. I don't have the knowledge to offer feasible solutions. But I realize that it must really suck for people to come to you whenever something goes wrong and not see the massive amount of work that's involved to prevent other massive mistakes. In a manner of speaking, remaining issues are like the tip of an iceberg. I can't offer feasible solutions. However, I do think it's worth pointing out that I've never experienced issues like this on literally any other app and that it's very frustrating from that perspective. The Wikimedia Foundation as a whole exists at a scale that other organizations do not and has access to resources that other open source projects do not have. As someone who has grown up in a user-friendly world, I've never felt frustration to this extent in regards to technical issues with something that is associated with a top website.

Phabricator tickets

While my experiences with this essay have sparked an interest in learning more about the technical side of Wikipedia, I did not file these tickets myself. JTanner (WMF) did this for me in response to this essay. The phrasing attributed to me in the tickets are not exact comments of mine, although overall they paraphrase my observations/suggestions.

Tickets that were started because of my observations Pre-existing tickets that were relevant to my observations
The possibility of explaining what the syntax highlighting means The possibility of VisualEditor on the app
Removing prompts for adding short descriptions outside of mainspace The possibility of creating articles on the app
Removing "profile" as a description for userpages
Resolved
Improving edit summaries
Renaming "quick facts" so there's consistency across platforms Syntax highlighting speed
Making redlinks actually redlinks in preview Enhancements to the app editor
Colour consistency in diffs across platforms
Whether your contribution is the current version of a page
Resolved
Remove option for thanking IP editors because you can't thank them
Resolved
Remove option to thank bots because you can't thank them
Investigating how AfDs display through the app
Fixing the "copy a diff" feature on my device
Resolved
Change "read article" to "read page"
Resolved
Not automatically pinging someone on a reply on their own talk page
Resolved
Not automatically showing my edits as changes in my watchlist  Not done[f]

Conclusion

In general, my experience communicating with WMF staff was fairly positive. I think that if this was considered the norm when the WMF recieves feedback from experienced editors, people would typically have a more positive view of the WMF. Instead, I've noticed that there's a lot of precedent for distrust and past conflicts. Ignoring these issues doesn't make them go away and acknowledging them is a crucial part in moving forward.

At the same time, I do appreciate that my concerns were validated, even if it was mostly by chance that I even got to have the opportunity to raise them to someone who was able to fix them. My adventure into learning more about editing via the app started from a tangential discussion at my talk page that had sprung from a previous discussion at Levivich's. I remembered that I had a WMF staff member post on my talk page once two years ago (MMiller (WMF)), pinged him, and he brought my concerns to JTanner (WMF), who could actually do something about any of this. She took the time to write lengthy replies and actually take action, like file Phabricator tickets on my behalf. My interactions with both of them have been more positive than what I had been expecting. Maybe it's because I'm mostly used to reading about the times where things go wrong. There's also something weirdly satisfying about my opinion mattering even if I realize that it might not be the best from a PR-perspective to have a random 20 year old identifying such issues. I doubt Facebook or Reddit would care that much about my opinion of their websites, so it's amazing to actually have a voice in a conversation like this.

This is the initial response I received about this essay:

Hey there @Clovermoss, thanks for taking the time to use the app and write such detailed feedback. It is very helpful and valued.

At a meta level, to find who works on what, a good place to visit is the Product Department MediaWiki page where it says product teams. You can comment on talk pages for that team and someone should get back to you. The Android team's project page can give you a good idea of what projects we worked on in the past, and what we are actively working on. We make it a priority to also work on tickets that come into our Phabricator Board filed by helpful folks like you when we have capacity. However, our team always makes it a point to give an idea of the "when we have capacity" will be. I share this so if you have feature ideas or notice bugs, outside of what you've listed here and want us to triage it within a week, that is the fastest way to grab our attention. However, we do our best as well to keep an eye out on talk pages or when we get pinged on helpful pages like yours. I have some time scheduled with our team's engineer who has been on the team longer (I have been on this team for 2 years), and can help me better understand why things that predate me may not have been prioritized previously so that I return to this talk page beginning of next week and provide some context for why things are the way they are, and more importantly what plans we have to address it in the future (and an estimate of how far in the future).

Zooming in specifically about the scrambling issue, it is a very unpleasant experience that has to do with syntax highlighting for devices like yours. What is happening there is the system freezing momentarily and causing keystrokes to queue up in the background, so when it unfreezes the keystrokes fall out at once, and is particularly prevalent when trying to edit a full page due to the amount of content that is there. Although with section editing depending on the type of device and amount of content in that section, it can be somewhat sluggish as well. For a while we disabled the ability to edit a full page and only allowed section editing, to limit performance issues. Recently we enabled full page editing because people (understandably) wanted to edit text that sometimes exists above a section, in a template for example, and the only way to allow that was to enable full page editing. The app was originally created for reading, in the past few years editing capabilities have been added based on requests we've received and our desire to serve mobile app users more holistically. That has come with a number of challenges, that I am very excited for us to work on in collaboration with people like you. Specifically concerning fixing the syntax highlighting issue, I can tell based on the engineer in 2017 abandoning the ticket it is quite a large task, but I will have a better understanding by the end of this week of just how heavy a lift it will be to give a better idea of when to revisit it, that is, if fixing this issue specifically is even appropriate. Our team is investigating somewhat showing the mobile web editor by building a layer over it, which would fix the syntax highlighting issue as well as other issues, while also keeping some of the unique features of our editor like Dark Mode. It is a very big project but something being prioritized because ensuring people can have a holistic experience in the app is very important to us. In the interim, any changes we can make to improve the existing native editor like link preview or easier ways to add an image, we are making based on requests that have come in, so it is still helpful to point these things out.

— JTanner (WMF), 22:50, 8 August 2022 (UTC)

There was a lot more back-and-forth from May 2022 to December 2022 (which is the month that I am writing this, I anticipate this to continue to happen). All of these comments can be seen in full at User talk:Clovermoss#Software development challenges. Most of these were comments pointing out issues as I identified them, what my general thoughts were, what I had written in previous versions of this essay, and JTanner helping me by placing Phabricator tickets on my behalf. This discussion actually technically started from a previous conversation about generalized newcomer experiences at User talk:Levivich/Archive 3#Growth team. Reading all of these conversations would probably take someone a few hours but they're there for anyone to read them.

Overall, I would say that I had a good experience communicating with WMF staff, but not everyone can say the same. One essay I think that explains the tension between the WMF and community to people who may be unfamilar with this is User:Novem Linguae/Essays/Community tension with the WMF. The overlap between the WMF and the community should not be comparable to a Venn diagram. Ideally, there should be more communication to limit misunderstandings and unnecessary conflicts.

Notes

  1. ^ Cullen328 is the most vocal advocate of this method and describes it thoroughly in his own mobile editing essay: User:Cullen328/Smartphone editing
  2. ^ The sole exception to this is using the "new thread" feature on a talk or user talk page. This has some issues though because if you want to leave a templated message, you'll get two conflicting headings. It is impossible to create pages in other namespaces through any method on the app.
  3. ^ This has been fixed and I can copy diffs now.
  4. ^ This has been changed in an update. The homepage still shows my total global contributions but clicking on it will display my total edits to enwiki. The 'views' option displayed in this screenshot is also no longer statically zero for my device since being updated.
  5. ^ This specific issue has been fixed but you still see similar issues elsewhere in certain contexts. An example is that if I go to the overflow menu to edit a page outside of mainspace, it will always say "edit article".
  6. ^ I was under the impression that edits outside of the mobile app edit interface not showing your own contributions was the default setting. That is not the case, as pointed out by CFeng (WMF)


S
In this issue
+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
  • Mobile pages use a different URL (m.wikipedia.org) which complicates things such as sharing a link in a discussion or viewing a bookmarked page on a desktop computer. Unlike other sites, checking the "View desktop site" box in Chrome brings up a zoomed-out version of the mobile site instead of switching to the actual desktop version.
  • Rendering issue:
Expand to see rendering issue
  • H
e
a
v
i
l
y


i
n
d
e
n
t
e
d


t
a
l
k


p
a
g
e


c
o
m
m
m
e
n
t
s


r
e
n
d
e
r


o
n
e


c
h
a
r
a
c
t
e
r


p
e
r


l
i
n
e
.
  • Talk page templates are hidden, buggy or missing entirely. Looking at one example:
  • None of the templates are visible unless you click the "About this page" link.
  • The entire Talk Header section is missing entirely, including talk page instructions and archive links.
  • The "Remedy instructions and exemptions" section is missing from the Arbitration Remedies template, and there's no big orange exclamation point.
  • "Daily pageviews" shows a blank box
  • "Section sizes" is missing
  • There's a random "This edit request has been answered" message, apparently from a section further down the page.
  • This means that new editors working from mobile devices have no access to talk page instructions or archives and have to click through to see important arbitration notices, some of which are incomplete. Given the amount of thought that goes into the wording and formatting of these notices, the fact that some editors see a different or incomplete version is concerning.
Bringing the mobile version up to modern UI standards should be an urgent priority. It's not just an aesthetic issue; mobile-based editors literally do not have access to the same information or notices as desktop users. –dlthewave 17:00, 1 January 2023 (UTC)[reply]
  • Mobile pages use a different URL (m.wikipedia.org) which complicates things such as sharing a link in a discussion or viewing a bookmarked page on a desktop computer. To save having to click "View desktop site" every time you use your smartphone to connect to Wikipedia, you can put mw.loader.load("https://en.wikipedia.org/w/index.php?title=User:%C3%9Ejarkur/NeverUseMobileVersion.js&action=raw&ctype=text/javascript"); in your Username/common.js directory. Maproom (talk) 11:17, 7 January 2023 (UTC)[reply]
Agreed. There is sort of a dark humor in our typical thinking: "this shit is really important, so we need to put it in a message box template". But the very act of doing that means that most readers can't see it! It makes absolutely no sense to me. jp×g 17:37, 1 January 2023 (UTC)[reply]
I wasn't aware that the mobile version of the website had many of its own technical issues, dlthewave. Thank you for bringing attention to them here. I was just going off of some of the experiences I've heard from other people, but it's important to hear another perspective. Clovermoss🍀 (talk) 20:24, 1 January 2023 (UTC)[reply]
It'd actually be more correct for me to say that I wasn't aware of this specific issue. dlthewave, if you're curious (or maybe you already know) the mobile technical issues I'm more familiar with is what's listed at Wikipedia:Mobile communication bugs. I'm like you in that I can't speak code but I know enough from hanging around on this website about why certain things mentioned there are vital and should not have the issues that they have (or used to before they were fixed). Clovermoss🍀 (talk) 15:26, 2 January 2023 (UTC)[reply]
Dlthewave, before the DiscussionTools project, there was no way to deal with the quite-indented issue you illuminate because of how unstructured our talk pages are (Flow would have solved this a decade ago...). It might be possible now with how DiscussionTools works, but there is some chunk of UI work that needs doing (I would guess this ends up something like how reddit works). That is phab:T116686.
Mobile having the same URL is phab:T214998. Maybe we'll get it another 5 years down the road. :')
Regarding "about this page" and the rest of "everything at the top of talk pages", I know that particular machinery is on its way out as a result of DiscussionTools taking over how talk pages work on mobile from MobileFrontend. phab:T319145 is probably the relevant task, though you can see some other children (I linked some below). This mobile link with dtenable=1 should be illustrative of what works in the future, which is most of it. For today, you can click the "Read as wiki page" button that should also show up toward the bottom of your mobile browser and then you'll get most of the reams of wikitext you might prefer at the top of the page -- it's more than you might prefer, even :). Collapsing doesn't work on mobile currently, see phab:T323639 for the mobile talk page solution (side note, I'm sad-annoyed that Matma Rex got some objections to adding mw-collapsible on all of mobile that look to me like perfection being enemy of the good). The WikiProjects are missing there but only at narrow width, probably related to what the stack of CSS related to Template:WikiProject banner shell/styles.css is doing reacting with the CSS on mobile (most likely and specifically the assumptions about tables that mobile makes) and/or the fact mw-collapsible doesn't work on mobile, so that's something to look into (double ping Matma Rex just to draw eyeballs to your user name). Izno (talk) 06:05, 2 January 2023 (UTC)[reply]
The WikiProjects are missing there but only at narrow width… It's because of the height: 0; rule at Template:WPBannerMeta/styles.css. I don't know what is the purpose of it. I was going to submit an edit request to remove it after the collapsing is fixed (so that it'd be easier to explain), but feel free to remove it now since it seems you already understand it better than I do and don't need my explanation ;) Matma Rex talk 13:22, 2 January 2023 (UTC)[reply]
Testing on Template:WikiProject banner shell/testcases by just removing the height in console with a banner both inside and outside the shell does seem to indicate that there isn't any value to the rule, indeed. I can't think of another reason for it to exist, and it was suspect when I moved these over to TemplateStyles (which is why I know how these work :). Put it down to unmarked Internet Explorer legacy. I'll make the adjustment. Izno (talk) 18:26, 2 January 2023 (UTC)[reply]
Izno, I'm glad to hear that a solution is in the works. I'm more concerned about ensuring that new editors are seeing these notices on the default version of the page, rather than finding a workaround for myself. The dtenable=1 version looks much better and perhaps this should appear on the main Talk page rather than the "learn more" click-through. –dlthewave 21:24, 2 January 2023 (UTC)[reply]
Dlthewave, yes, dtenable is expected to be the final version meaning the default, DT just isn't "live" yet. Hence my linking to the task which I think will be closed when it is, but you can follow the others if you wish. Izno (talk) 21:26, 2 January 2023 (UTC)[reply]
  • I think the statistics for app pageviews could be inaccurate.

Looking at your talk page natively in the app does not count as a pageview, since we’re using the DiscussionTools API to get the contents of the conversations. We will talk to the Editing team to see if querying the DiscussionTools API should count as a pageview.

— JTanner (WMF), 13:55, 16 August 2022
This was part of a larger response to my observation that changes I had already seen in my watchlist were not "seen" when I switched to desktop/mobile. I would look at my watchlist and see an edit to my own talk page as an "unseen change" (which is what one of the screenshots in this essay demonstrates). I don't know how much this might affect normal pageview statistics but it sounds like it's possible that there's greater visibility on the app than people may realize. Clovermoss🍀 (talk) 12:53, 3 January 2023 (UTC)[reply]
For the month of December, talk page views on mobile web were non-existent in the top 100 pages (I turned off the option to consider only main space views). Views are dominated first by the main page (apparently), secondly by search, and then whatever's in the news. I would expect page views for mobile app to follow the same trend. Izno (talk) 17:19, 3 January 2023 (UTC)[reply]
@Izno: So is it just talk page views that are affected? It wasn't just my edits to talk pages that would show up as unseen changes in my watchlist, that was just an example I was using. This led to my concern that there may be a broader impact to inaccurate pageview statistics regarding the app. At least on specific devices like the one I was using at the time. There was an issue with my old phone not being able to copy diffs because the option just didn't show up. The response I got was that they test how things work on 10 devices which is apparently above average for similar websites. It sounded low to me, but again, I don't know how this stuff works. Even with my new phone (a Pixel 6a), you can't see diffs when they are linked. They just show up as blank space. This was an issue with my old phone too and I'm wondering if this is what is meant to happen.
The issue with not being able to copy diffs was eventually fixed with my old phone because I brought it up but I guess it prompted this distrust that these things may not be consistent across devices since it worked on her phone and she seemed surprised that it didn't work on mine? I was using a Samsung Galaxy J2 before if that matters. Maybe there's not much to be done to fix technical issues for older devices but it might be worth trying given what Bilorv stated. Not everyone can afford a new phone.
To try and make my thoughts more clear, what I'm saying is that even if talk page views weren't supposed to count for everyone, is it possible pageview statistics are inaccurate even when they are meant to be counted? Or is that a question you can't speculate/give an answer on? Clovermoss🍀 (talk) 01:23, 4 January 2023 (UTC)[reply]
@Clovermoss: This led to my concern that there may be a broader impact to inaccurate pageview statistics regarding the app. I don't personally believe that's a significant concern. For a few reasons:
  1. The issues you mention (diff problems, talk page edits, etc.) are editing difficulties, and edits as a whole are a vanishingly small percentage of pageviews. It's a big leap to extrapolate difficulties experienced with mobile editing into difficulties with mobile viewing.
  2. If you turn on the "Show mobile percentages" column of our topviews stats (like the list Izno linked to), some of the most-viewed pages are over ninety-eight percent mobile viewers. (In December, XXX: Return of Xander Cage had 4.93M pageviews, 99% of which were mobile!) If mobile pageviews were being either systematically or significantly undercounted, there's just no way that would be the case.
The mobile editing experience is poorer because it's harder, and because a lot of it comes down to there being no [easy|good] solutions to problems like the ones you've described. For any site, not just Wikipedia. There's a reason web developers in general don't work on their phones much: It's simply a bad platform for editing... well, most things, really, but existing, formatted text or mixed-media content in particular. Sure, we all use our devices to read web content, and we may use them to write site comments, emails, even the occasional letter, report, or blog post. But creating content on a blank page is significantly easier than editing existing content, something rarely done from mobile devices because it sucks to do from mobile devices.
I don't personally believe the solution to that is as simple as improving the tools. There's an implicit assumption there that a device as small as a phone, with no physical keyboard, is capable of providing adequate tools for the task. My counter-argument is: the devices have been steadily improving for fifteen years now. They're endlessly faster, smarter, provide better and better feedback, and at this point even mid-range models have such high-resolution displays that they've long since stopped rendering content at pixel resolution, because it'd be too tiny to make out. Yet, the experience of editing Wikipedia pages, or anything else, on them isn't significantly improved from what it was like a decade ago.
I also definitely don't believe that the issue is in any way that, as you say: This limitation on editing seems exist because none of the desktop skins have editing interfaces that are responsive (flow to screen size)? The desktop edit interface is not suited for a device as small as a phone. It's questionable how useful it is even at tablet sizes. To be useful, a mobile editor needs a radically different interface, not a responsive interface. Responsive content can work for viewing (though I'll be the first to say, Wikipedia's content is definitely still lacking on that front), but it's no solution at all for editing.
Google Docs or Microsoft Word, as two random examples, don't just squeeze their desktop interface down to fit on mobile devices. They have a completely separate application for editing content, built from the ground up as a mobile platform, that bears almost no resemblance to the editing interface they provide on the desktop (or in a desktop browser). Same documents, but completely different editing interface. And despite that, they're also still severely limited in just how much you can do when editing on a mobile device, vs. the full desktop experience. (Plus, neither comes even close to tackling tricky content problems like our citation templates, or editing hidden/auto-formatted content like that in general, really.) FeRDNYC (talk) 11:55, 4 January 2023 (UTC)[reply]
@FeRDNYC: I appreciate the breaking down why the pageview scenerio is implausible. What I'm confused about is the second quote that you disagree with me on because I didn't say that. Clovermoss🍀 (talk) 12:08, 4 January 2023 (UTC)[reply]
Mobile editing is never going to be as easy as editing from a desktop, and editing from a desktop is disadvantageous to editing with two desktop screens. But the Android app's capabilities are nowhere near the limitations of its medium, not when a single user reporting their issues leads to a dozen Phabricator major tickets. Just as the word processors you've named are redesigned for mobile, we need a redesign with mobile users in mind. — Bilorv (talk) 12:31, 4 January 2023 (UTC)[reply]
Hi, @FeRDNYC:: Regarding I also definitely don't believe that the issue is in any way that, as you say: This limitation on editing seems exist because none of the desktop skins have editing interfaces that are responsive (flow to screen size)? The desktop edit interface is not suited for a device as small as a phone. It's questionable how useful it is even at tablet sizes. To be useful, a mobile editor needs a radically different interface, not a responsive interface. Responsive content can work for viewing (though I'll be the first to say, Wikipedia's content is definitely still lacking on that front), but it's no solution at all for editing. This was me. I made this comment because it seems like many (some?) editors are using the desktop view on a smaller device in landscape mode as described in the often-mentioned essay by Cullen328. This suggests to me that the desktop interface could use a little "responsiveness" so that could be used in portrait mode, which for phones is a more natural way to type (IMHO). I did not intend to suggest that the whole mobile editing thing didn't need a "radically different interface," to which I do agree, but I lack the understanding to suggest exactly what in detail (without sounding totally bonkers). Is "making the desktop view flow better" just a band-aid? Oh absolutely, but there doesn't seem to be much political will (again I'm not sure who is "in charge" of this anyway) for a radical redesign of the mobile view editing interface. And maybe it's really this lack of political will that I find perplexing. Still, all food for thought! Cheers! — LumonRedacts 14:14, 4 January 2023 (UTC)[reply]
@Clovermoss I think other (non-talk) page views from mobile apps are being counted correctly, even though they use a different method than desktop/mobile web page views, which is why the watchlist doesn't know you've seen those pages. I looked around on Phabricator for known issues and it seems it has been buggy in the past, but it has been fixed – most recently in 2020 in task T256508. Matma Rex talk 14:20, 4 January 2023 (UTC)[reply]
  • I hope some of the people you pinged join in this discussion, then. I'd be interested in other people's experiences with the app, especially if they've been using it longer than the 6 months I have been. Afterall, I'm just one person so there's likely aspects I haven't experienced or perspectives I haven't considered. Clovermoss🍀 (talk) 03:36, 5 January 2023 (UTC)[reply]
    Hello Clovermoss, it’s great to hear from you again in this fantastic post!
    This is Amal Ramadan, the community relations specialist; JTannerWMF mentioned me previously in your earliest post, and I am delighted that I have the opportunity to engage with you and those interested in apps in conversations like this one.
    Just wanted to give you an idea of the status of some of the items that haven’t been completed based on your table:
    All of our users' comments and feedback are welcomed all the time; that’s why we are starting a mega chore wheel that will include a summary of the received feedback and suggested features from the users; hoping the above is helpful to you. Feel free to contact us at any time 🙂 ARamadan-WMF (talk) 13:03, 1 February 2023 (UTC)[reply]
    Also, we are working on preparing tools and flagged pages where you all can send your feedback and thoughts alongside our support emails and reviews on the play and app store.
    And we will announce the next office hour that will be held with the apps team and users in the upcoming weeks. ARamadan-WMF (talk) 13:11, 3 February 2023 (UTC)[reply]
We would love to see you all! ARamadan-WMF (talk) 08:23, 7 March 2023 (UTC)[reply]

Mobile feature request

Mobile feature request: I would like disambiguation page links to show up in orange font on mobile like they do on the desktop site. Please and thank you. best, jengod (talk) 15:21, 1 February 2023 (UTC)[reply]

The apps' online meeting in October 2023

Hello!

Following these productive discussions regarding the utilization of Wikipedia mobile apps, I would like to extend an invitation to you to an online meeting with the mobile apps team. It will take place on the 27th of October at 5 p.m. UTC (check your zone’s exact time).

The host will be Jazmin Tanner, the product manager of the apps team, with a number of our software engineers; you can join the meeting from the following:

https://wikimedia.zoom.us/j/83695206107

Feel free to share your questions and thoughts about Wikipedia’s mobile apps on the Wikimedia Apps/Office Hours page on mediawiki.org. We would love to hear from you. The last date to add your input will be on the 24th of October at 12:00 UTC.

If you’d like a one-day reminder before the meeting, simply add your username, and I’ll send you one.

We will be waiting for you all!

ARamadan-WMF (talk) 10:58, 21 September 2023 (UTC)[reply]



       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0