Input boxes for empty labels and descriptions should be in edit-mode by default. That saves an additional [edit] click for users.
Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=0
Input boxes for empty labels and descriptions should be in edit-mode by default. That saves an additional [edit] click for users.
Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=0
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T78430 [Epic] Getting Wikidata to render nicely on mobile web | |||
| Open | None | T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web | |||
| Open | None | T95878 [Story] Make Wikidata editable on mobile web | |||
| Open | None | T95649 Create and document a stable framework for extending the Wikibase UI | |||
| Stalled | None | T40968 Keyboard-navigability of the repo UI | |||
| Open | None | T54136 [Epic] Redesign Item UI for Wikidata repo | |||
| Invalid | None | T70903 [Story] Implement new SiteLink UI | |||
| Declined | Lydia_Pintscher | T74021 Enable instant edit-mode for empty term input boxes |
How is that supposed to behave? Do you have an edit mode without being in edit mode? Do you trigger edit mode for all labels and descriptions when starting to type in an empty box?
The idea of having some kind of mixed edit mode would create additional complexity. The pain is that the current state is an inconvenient intermediate step towards implementing the new UI. We could either rewind and put changing edit mode of the "In other languages" into a greater UI change. However, that would create additional work - not just for rewinding. Huge changes do not really fit into the development process (pointing at merge conflicts). We should rather focus on moving on to switching to the new UI priorizing on the steps removing inconveniences created on the way first.
In my opinion, an intermediate solution for an intermediate solution like this bug is proposing is not pointing into the right direction. :-/