Additionally, this change broke some user gadgets, including MoveSiteLink.
Solving mixed themas is now much more difficult (edit + scrolling + copy + delete + scrolling + save + edit second + scorlling + lang + paste + scrolling + save) instead of simple (edit + move)

(In reply to Romaine from comment #0)

Recently Wikidata was changed which caused it much more work for especially
power users. It is no longer easy to add/change parts of pages. Each time I
now have to edit a section and save it before I can continue in another
section.

A simple adding of 4 pages results in much more clicks.
Was: click + paste + save + add + lang + paste + save
Now: edit + click + paste + scrolling + save (outside my screen) + edit +
add + lang + paste + save (on not expecting place)
And that four times...
This creates a much less efficient working situation.

Please restore the previous situation.

Ok, I think there is quite some misunderstanding how the click-path for editing/adding sitelinks works now:

For adding 4 new sitelinks, the path would be:

[edit] -> [add] -> choose siteid -> choose article -> [add] -> choose siteid -> choose article -> [add] -> choose siteid -> choose article -> [add] -> choose siteid -> choose article -> [save]

Note that you only have to click [edit] once in the beginning and click [save] only once in the end. In between you can add/change/remove as many sitelinks as you want.

Indeed, the worst case (because of the scrolling) is when you only add one sitelink. You click [edit] and have to scroll all the way down to add a new one, then scroll all the way back up to click [save]. We will improve this situation, e.g. by adding a second toolbar at the end of the list.

romaine.wiki wrote:

(In reply to tobias.gritschacher from comment #2)

Note that you only have to click [edit] once in the beginning and click
[save] only once in the end. In between you can add/change/remove as many
sitelinks as you want.

The path I described was accurate. No misunderstanding was there.
If I want to add 4 pages from four wikis, I also need (and want) to fill in the labels for those languages.

In the past I copied the title, and placed it on 2 places in a page, before I continue with the second page I want to add. That a label is filled in together with the link is not understood.

Now is this very very clumsy.

A user copies in the past the page title, and on Wikidata:
(label:) click + paste + save + (linked:) add + lang + paste + save -> 4x.

Now: A user copies currently the page title, and on Wikidata: (label section:) edit + click + paste + scrolling + save (outside my screen) + (linked section:) edit + add + lang + paste + save (on not expecting place) -> this all 4 times

Even for one link this is a lot more clicks, the more links, even more steps are needed.

romaine.wiki wrote:

(In reply to JAn Dudík from comment #1)

Additionally, this change broke some user gadgets, including MoveSiteLink.
Solving mixed themas is now much more difficult (edit + scrolling + copy +
delete + scrolling + save + edit second + scorlling + lang + paste +
scrolling + save) instead of simple (edit + move)

I can confirm this. Strange that the new design has not taken this into account. Not an improvement.

(In reply to Romaine from comment #3)

(In reply to tobias.gritschacher from comment #2)

Note that you only have to click [edit] once in the beginning and click
[save] only once in the end. In between you can add/change/remove as many
sitelinks as you want.

The path I described was accurate. No misunderstanding was there.
If I want to add 4 pages from four wikis, I also need (and want) to fill in
the labels for those languages.

In the past I copied the title, and placed it on 2 places in a page, before
I continue with the second page I want to add. That a label is filled in
together with the link is not understood.

Now is this very very clumsy.

A user copies in the past the page title, and on Wikidata:
(label:) click + paste + save + (linked:) add + lang + paste + save -> 4x.

Now: A user copies currently the page title, and on Wikidata: (label
section:) edit + click + paste + scrolling + save (outside my screen) +
(linked section:) edit + add + lang + paste + save (on not expecting place)
-> this all 4 times

Even for one link this is a lot more clicks, the more links, even more steps
are needed.

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?

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.

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.

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.

(In reply to Romaine from comment #4)

(In reply to JAn Dudík from comment #1)

Additionally, this change broke some user gadgets, including MoveSiteLink.
Solving mixed themas is now much more difficult (edit + scrolling + copy +
delete + scrolling + save + edit second + scorlling + lang + paste +
scrolling + save) instead of simple (edit + move)

I can confirm this. Strange that the new design has not taken this into
account. Not an improvement.

It was announced well beforehand that the upcoming changes will break gadgets. See the announcement here: https://lists.wikimedia.org/pipermail/wikidata-l/2014-August/004492.html
Unfortunately we cannot avoid breaking 3rd-party gadgets when doing extensive refactoring of existing concepts. We try to keep the number of breaking changes as low as possible but when doing a massive change to how the UI works it is impossible to avoid them. I fear they will happen again on our road to the new user interface. We are trying to announce them as early as possible. That's the best we can do.

romaine.wiki wrote:

(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.