https://bugzilla.wikimedia.org/show_bug.cgi?id=71845
--- Comment #7 from Romaine <[email protected]> --- (In reply to tobias.gritschacher from comment #5) > Ok, did not understand your complete workflow in the first place. Now it is > clearer to me what you are really doing. You are adding a new sitelink > together with label/description/aliases in that language, right? Yes. In the past we have advised users to add the label together with the link, as it is mostly the same. > Indeed the workflow for the case above, became more complicated. Before we > introduced section-edit-mode for the termbox, empty input-fields were in > edit-mode by default. That saved one click on [edit]. Also for sitelinks > after [edit] there is an additional click on [add] necessary if you want to > add a new one. That makes 2 additional clicks more for the scenario > described above. We need to think how to improve the situation. Thanks for recognizing, that is indeed the wish. > Just some random thought by myself: > - probably we can restore the behavior of having input-boxes for empty > labels and descriptions in edit-mode by default. Not sure how hard that > would be to implement, given the fact we move into the direction of the new > UI design. We need to check. > - you mentioned an additional "scrolling" step to be able to click on [save] > after you added label/description or a sitelink. You can omit this step by > just pressing [return] on your keyboard to trigger the [save]. Additionally > you can cancel your action by pressing the [esc] key. > - the need for the additional click on [add] for adding new sitelinks is > really a pain. I do not like it either. One solution would be to insert a > row for a new sitelink by default when clicking on [edit]. We need to check > if and how this is possible. I am already happy that is recognized what I try to describe. I understand time is needed before the full new design is implemented. This first step concerns me. I am happy that things can be saved by return/enter key, but working with a mouse it is confusing how to save a change. Missing save buttons or having them on a strange place (read: a place where I would not expect them) is what I noticed as well, but that is not my major concern. For myself I consider missing buttons or having them on a strange place something to get known with, but there will be a lot of users who have problems with it and can't handle this. > However these are intermediate steps towards the new UI design, that has > been discussed and iterated over a long time here: > https://www.wikidata.org/wiki/Wikidata:UI_redesign_input > and here: > https://www.wikidata.org/wiki/Wikidata:UI_redesign_input/Archive2 > and here: > https://www.wikidata.org/wiki/Wikidata:UI_redesign_input/Archive > > Did you take part in the discussion? I am not sure if in the end when we are > finished with the new design, you would be able to do the workflow as > described above without adapting it. Changes almost never have advantages > only. But the goal should always be that the advantages outweigh the > disadvantages. I have seen the designs before, but I got lost in them. I lost overview together with not getting it. Because of this I have not taken part in the discussion, I have with this not the feeling that my input would have made sense. These designs give me at least a very restless and chaotic view. Also I try to imagine where I should add the things I normally add to items, and I have to search for the place instead of seeing directly a logic place for them. I think I know where I should add them after looking at the page for 15 minutes, but still one item I regularly add is unknown. Most users add/change mainly labels, descriptions, links to pages, Commonscat statement and the Commons link. If these images on top of Wikidata:UI_redesign_input are really the ones that become the actual new design, Wikidata is making a step towards external users, but three steps away from the users from other Wikimedia wikis. Perhaps then it is better to start with skins for Wikidata, so that users from other wikis can set a different setup which fits much better with their needs. But I must say, this is beyond the initial workflow problem that this bug is about. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
