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)

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)