Wikidata talk:Usability and usefulness/Item editing experience/Mobile editing of statements

Long values? Never heard

I'm not sure how to comment on the prototype, as it is English-centric and doesn't even try to use long values. Everything works fine if you using "start time" or "reference URL". At the same time, we can already see that "determination method…" (20 characters) is cut as it is too long for a table, and "located in the administrative territorial …" is too long for a selection list. In many languages, we have hundreds of properties that start with "идентификатор"/"identyfikator"/"identificador" (13 characters + space), so we have only 6 characters to distinguish between them.
The same issue with "edit". Try to use Ukrainian with "редагувати" or Greek with "επεξεργασία" and you will immediately see that there is simply no room for this text. —putnik 19:06, 12 June 2025 (UTC)

Thank you Putnik, this is really helpful and important feedback. You're absolutely right that terms like "редагувати" or "επεξεργασία" can quickly run into space constraints, and that many property labels are much longer in other languages or start with similar prefixes. At this stage, the prototype is intentionally simplified to test the core layout and interaction patterns. But as we move forward, we’ll definitely be looking at how the design handles longer values, multilingual labels, and RTL scripts to ensure it's usable and inclusive for everyone. Mohammed Abdulai (WMDE) (talk) 10:02, 16 June 2025 (UTC)

Dates

Can you explain why you don't use a date picker for date values? Discostu (talk) 20:34, 13 June 2025 (UTC)

Thanks for the question @Discostu! We’re intentionally replicating how dates are entered on desktop to ensure consistency across devices. A date picker might seem more convenient at first, but it can limit flexibility for example historical dates, uncertain values and non Gregorian calendars. The current input method supports a wider range of formats and use cases, which is important for Wikidata’s diverse data needs. Mohammed Abdulai (WMDE) (talk) 13:07, 16 June 2025 (UTC)

Interface Language

I didn't see how to change the default interface language from English to a language of choice by a user.

And also I love to know the options hidden under the Hamburger icon in the top left

And is there any way possible of interacting with the prototype directly? B722N (talk) 03:25, 14 June 2025 (UTC)

Hi @B722N, Thank you for your feedback and good catch. Changing the interface language and the options in the hamburger menu will continue to work the same way as they do currently. This prototype focuses specifically on testing improvements to how statements are displayed and edited.

The prototype isn’t interactive at this stage. It’s just a visual demonstration to test and gather feedback on the new layout for viewing and editing Item statements. - Mohammed Abdulai (WMDE) (talk) 11:22, 24 June 2025 (UTC)

Thank you for the feedback̊̊@Mohammed Abdulai (WMDE) B722N (talk) 11:26, 24 June 2025 (UTC)

@B722N. We now have something you can interact with directly. Please note that the prototype is just a design file so not everything is clickable. -Mohammed Abdulai (WMDE) (talk) 14:44, 21 July 2025 (UTC)

Thank you for sharing the link @Mohammed Abdulai (WMDE), I am going to check it out B722N (talk) 16:44, 21 July 2025 (UTC)

Simple Mode & Advanced Mode

I wonder if the user interface could be made simpler. Or perhaps we could introduce two modes of operation: Simple Mode (limited features for basic tasks) and Advanced Mode (full-featured, with all the complex buttons displayed). For the Simple Mode, I’ve made a prototype here : https://wdlite.toolforge.org/?item=Q180 Niryhpr (talk) 09:20, 16 June 2025 (UTC)

Thanks so much for that idea. Yes we’ve been exploring similar concepts, including collapsed or simplified versions of the interface to reduce visual complexity. Your prototype is really helpful in showing how a Simple Mode could work. We'll take a closer look and consider how best to incorporate that kind of flexibility. Mohammed Abdulai (WMDE) (talk) 13:23, 16 June 2025 (UTC)

I was expecting to select the values by tapping them

And found myself repeatedly tapping them Ignacio Rodríguez (talk) 16:23, 24 July 2025 (UTC)

@Ignacio Rodríguez: I’m pretty sure that’s how it’ll work, this tap in the field thing only comes from the prototype state. —Tacsipacsi (talk) 16:28, 26 July 2025 (UTC)

Community user test group?

I really appreciate that you share the design prototype at an early stage with the community.

Have you considered reaching out to the community e.g. to the users who already reacted here and ask them to participate in a user testing session? Just sharing the prototype does not give you information about how new versus experienced users interact for example. I also suggest testing with disabled people so you can catch issues with colors, etc. So9q (talk) 09:03, 25 July 2025 (UTC)

@So9q: There’s a call to sign up for interviews in the How you can help section, isn’t that good enough? —Tacsipacsi (talk) 16:26, 26 July 2025 (UTC)

Sounds good, I missed that :sweat smile: So9q (talk) 20:19, 26 July 2025 (UTC)

Why modal?

Modal windows, popups and the like are evil. They force a particular workflow on the user, whether they like it or not. For example, I cannot copy over a reference property for property from another statement because the popup forces me to either publish or dismiss the edit before I can see the other statement. I mentioned references because it’s a quite common thing, I do this all the time on desktop – for example, if I get the birth and death date from the same source, I fill in the details for the birth date and then just copy over the values to the death date. A well-written reference almost always contains at least two or three values (e.g. reference URL (P854), title (P1476) and retrieved (P813); catalogue ID and retrieved (P813) and maybe stated in (P248)catalogue). For complex inputs like coordinates or dates, it’s maybe, maybe okay, but that’s about it. The main statement editor shouldn’t be modal, just like it isn’t modal on desktop. Modal windows, i.e. the interruption to the user’s workflow, shouldn’t last more than a few seconds.

Other than the modal problem, I like the interface, it’s easy to understand and navigate (at least for me as a veteran Wikidata editor). It uses a bit too much of color to my taste (and compared to Vector 2022, on which it runs – Vector 2022 uses almost no background colors), but that doesn’t affect usability. I also found the date input a bit hard to understand, but that probably comes from the prototype state – I cannot actually type in the date I want, so I don’t see how it’d work. —Tacsipacsi (talk) 16:25, 26 July 2025 (UTC)

Thanks so much for your feedback, this is a really interesting and helpful way of thinking about the design.

When we tested this we saw that some editors could get lost on smaller screens. Choosing a modal style for editing was a way to reduce scrolling so editors did not lose track of where they were. It also made qualifiers and references clearer to work with instead of dropping further down the page as you edit. The modal gives a bit more room on the page which helps with longer values and with interface languages that take up more space.

You make a very good point about references though, and the workflow you describe is important. That is something we will look into as we keep refining the design. Arian Bozorg (WMDE) (talk) 13:46, 20 August 2025 (UTC)

I suggest making the modality optional. Then experienced users can turn it off if they want. Similar to source editing for wiki-pages turns off all the helper js which just gets in the way sometimes. So9q (talk) 05:02, 21 August 2025 (UTC)

That's a great approach, we are developing the modal system first, but this could be a nice solution for other workflows on mobile in the future Arian Bozorg (WMDE) (talk) 09:37, 21 August 2025 (UTC)

Agreed, this also ahappens to me all the time on enwiki FaviFake (talk) 15:27, 13 October 2025 (UTC)

+1. Modal should definitely be optional IMO. So9q (talk) 16:12, 13 October 2025 (UTC)

The demo video looks good, but the entry of coordinates with a dozen or more decimal places is ridiculous. Please default to six decimal places (very roughly, six gives precision to one metre; eight to a centimetre).

Please also confirm that it is optionally possible to paste a value, instead of picking from a map. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:17, 25 August 2025 (UTC)

Hi @Andy, thanks for the feedback. Just to clarify, this is a design prototype and it didn’t replicate the current coordinate functionality on Wikidata properly, though it should have. In practice, it will continue to work the same as on desktop: you’ll still be able to paste coordinate values directly instead of picking from a map. Your note about default precision makes sense, and we’ll keep that in mind as we refine the design. -Mohammed Abdulai (WMDE) (talk) 08:27, 18 September 2025 (UTC)

I don't think I ever during all my years of editing ever typed in a coordinate by hand anywhere. It's not something I ever saw anyone elso do either. So copy-paste or share to app or map based picker is the way to go. So9q (talk) 16:16, 13 October 2025 (UTC)

General enthusiasm

Just a note to say I'm really excited for this!!! Lajmmoore (talk) 09:42, 4 November 2025 (UTC)

Ditto 😎 Arlo Barnes (talk) 06:23, 25 January 2026 (UTC)

Commons structured data editor

I find the Wikimedia Commons structured data editor to be extremely usable on mobile, and it uses Wikidata for item and property sourcing. Why not adapt that editing system to Wikidata directly? Are there limitations to that system that prevent its use here? Just curious! Serebit (talk) 23:20, 1 January 2026 (UTC)

Hi @Serebit! Thanks for the helpful suggestion. You're right, the sdc editor is a great model and we have indeed been looking at it. It's architechture is different from the general editing needs of Wikidata so while we can't directly adapt its system, the usability and design are an inspiration for our work on mobile editing.— Mohammed Abdulai (WMDE) (talk) 09:51, 20 January 2026 (UTC)

Add new item

Is there any plan to add a feature for creating new items on mobile as well? If so, I think it should include a mandatory check to prevent the creation of duplicate items, to ensure that users do not create new items for things that already have an item in Wikidata. Rtnf (talk) 06:59, 9 January 2026 (UTC)

Hi @Rtnf! For this current project, our scope is focused specifically on editing statements on existing Items. Creating new Items on mobile is a logical next step for the future, and your point about duplicate prevention is well noted. -Mohammed Abdulai (WMDE) (talk) 11:49, 20 January 2026 (UTC)

Some initial comments

I am pleased to start using this, after trying out the prototype last spring. Some comments from a first few edits:

(1) It will be good to get references URLs permitted to avoid leaving a trail of unreferenced edits.

(2) The placement of the proceed buttons is a bit weird and inconsistent: label change tick button off at the right (off-screen in the normal phone portrait mode), other changes with cancel/publish off at the bottom right of the screen. In addition, when adding a new statement, the focus is going down to that cancel/publish area, giving what appears to be an empty screen until I scroll up to Property at top left. (In the prototype session, I suggested following the Wikipedia mobile editor approach of an on-screen top right blue ">" button to proceed with a change.)

(3) Adding a label and alias in a language which was lacking a label, I got the blue progress bar for a while then it redisplayed the existing item without my edit. I tried exactly the same again and it worked fine. I mention in case others have a similar unreproducible issue. AllyD (talk) 09:36, 9 January 2026 (UTC)

Hi @AllyD, thanks a lot for taking the time to provide such detailed feedback.

1. References: You are absolutely right. Supporting references is a high priority for a complete editing workflow, and we hope to have that functionality released soon.
2. Button placement & focus: This is really helpful feedback. We will look into the button placement with some more in-depth research to see how we can improve the flow.
3. Unsuccessful edit: This is also very strange behaviour. Thank you for reporting it. We will test it on our end to see if we can replicate the issue. If you or anyone else encounters this again, please note any specific details (like the exact Item and property) so we can investigate.

-Mohammed Abdulai (WMDE) (talk) 11:57, 20 January 2026 (UTC)

Red "Edit" links

I am enormously happy to see this finally being addressed. Huge thanks to the developers!

However, I found at least one issue.

Many statements show a red "edit" link.

If I am guessing correctly, that happens when they can't be edited because the data type is not supported or for some other technical reason.

When I click this red link, nothing happens, which is confusing. And the red link design is not great in the first place, because it usually means something else.

You should probably make it gray or something, or just not show it at all, or show some indicator that the statement can't be edited. Amir E. Aharoni {{🌎🌍🌏}} talk 17:51, 9 January 2026 (UTC)

Hi @Amire80, thanks a lot for your clear feedback. You guessed correctly. A link appears in red when the statement uses a datatype that is not yet supported in this initial release. And yeah that can be confusing for people.

As this is a limited beta feature for now, we will keep these links red to visually distinguish unsupported datatypes. However, as we expand support to more datatypes in the future, all active "edit " links will become the standard blue. Thanks again for helping us spot and understand this point of confusion. -Mohammed Abdulai (WMDE) (talk) 12:05, 20 January 2026 (UTC)

Using unknown/no value in qualifers and references is harder than it should be

If you try to add a qualifier (or a reference) to a statement (like in this edit) and set its value to either unknown value or no value then the add button is disabled and the qualifier cannot be added. The only way to add such a qualifier is to set a dummy custom value to enable the add button and then switch to unknown value/no value. Warudo (talk) 02:40, 10 January 2026 (UTC)

@Warudo! This is really helpful feedback, and we will look into fixing this bug. If you encounter any other similar quirks in the interface, please don't hesitate to report them. -Mohammed Abdulai (WMDE) (talk) 12:10, 20 January 2026 (UTC)

Document property data types, that are not yet supported for mobile editing

When trying out this new feature, I noticed that a lot of properties/qualifiers/references that I wanted to add were disabled (grayed out) and were marked as "(not supported on mobile)". However on this project page, it doesn't mention any restrictions or that this feature is only available on certain property types[Edit: I was wrong, sorry], so it was a bit confusing and annoying that many of the properties I wanted to try were not supported. I can understand that this is still work in progress and that certain properties require special ways to input the content (e.g. coordinates), but at least for URLs, External Identifiers and Quantities I would expect this to work with just a simple input field. But regardless, it would help to manage expectations if these limitations were at least communicated on the project page. I quickly checked the different data types and copied the table from Help:Data type and adjusted it accordingly. Feel free to double check if this is correct and then post it on the project page.

-- DFichtmueller (talk) 16:15, 12 January 2026 (UTC)

Data type	Number of properties	Support for Mobile Editing
internal
External identifier	9,902
Item	1,721
Quantity	680
String	348
URL	118
Commons media file	89
Point in time	70
Monolingual text	64
Property	22
Geographic coordinates	10
Tabular data	6
Geographic shape	3
external
Mathematical expression	36
Sense	19
Lexeme	15
Form	10
Musical Notation	6

DFichtmueller (talk) 16:15, 12 January 2026 (UTC)

Sorry, my mistake, I didn't read the page correctly. In the last paragraph on the project page, it states

Try editing statements with the supported String and Wikibase Entity ID datatypes

I must have missed this. However, others might miss this as well, so it would help to show more prominently which property types are already supported and which ones aren't. I apologize for the confusion. -- DFichtmueller (talk) DFichtmueller (talk) 16:55, 12 January 2026 (UTC)

@DFichtmueller To be fair, I didn’t make it easy by putting that information at the bottom of the page. I’ve added a prominent banner at the top of the project page to clearly state which datatypes are currently supported in the mobile beta. -Mohammed Abdulai (WMDE) (talk) 12:19, 20 January 2026 (UTC)

Background colors for the ranks need to be added back in

Tracked in Phabricator
Task T416197

For some reason, this editor disables the green and red background color for preferred and deprecated rank. This is a feature that exists in both desktop and the regular mobile interface and it is very helpful because it allows us to determine a statement's rank at a glance. Without it, I have to check the small rank symbol every time. Please add the colors back. Warudo (talk) 14:26, 23 January 2026 (UTC)

Some properties are not compatible yet

I tried adding statements for properties like P1584, P214, P9051 and P396 but they are greyed out and described as not available. What is missing? Thank you for putting this forward! Steko (talk) 18:27, 30 January 2026 (UTC)

Edit: since I'm on mobile I just jumped to the bottom of the page without reading the collapsed topics that were discussing this aspect in much detail.