Support cloning of non-ID attributes from other items for item creation

[ribose-jeffreylau]

from discussion with @maccraymer

[maccraymer]

What do you mean by "non-ID" items? What we would need is pre-populating a proposed item's content with that from another existing item in the register. -Mike

[ronaldtse]

I think "non-ID" items means "unique identifiers" for a source item to be duplicated. When we duplicate an item we don't want to copy out the identifiers that are meant to be unique keys. e.g. we copy the content into a new item but not the unique identifiers.

[maccraymer]

Thanks for clarifying. I agree. We don't want the unique identifier for the item being copied. On the other hand, we do want the identifiers for the attributes being copied when those attributes are referencing other items in the register. -Mike

[ribose-jeffreylau]

Would be more user-friendly if the button goes straight into edit mode?

[ronaldtse]

Yes going straight into "edit mode" would make it clear to the user that it is something new. In edit mode after cloning the data, the identifier should be emptied out (maybe warned with a red box) so that it cannot be mistakenly created "as-is".

Also, can we rename the "Propose another like this" button? It reads to me like Google's "I'm feeling lucky", i.e. something that hardly anyone understands...

Can we make it clear like "Add a new item with information cloned from this item"?

[strogonoff]

Would be more user-friendly if the button goes straight into edit mode?

Yes. It’s a current limitation.

[strogonoff]

after cloning the data, the identifier should be emptied out (maybe warned with a red box) so that it cannot be mistakenly created "as-is".

Editable GR identifier will eventually be gone from all proposal forms per our communication with Mike.

Also, can we rename the "Propose another like this" button? It reads to me like Google's "I'm feeling lucky", i.e. something that hardly anyone understands...

Is it factually incorrect?

Keep in mind that in case of Google it’s a completely useless button that no serious user would use, existing purely as callback to the past. In our case, it’s a new concept which we cannot expect any user to understand the mechanics of without explanation (not unlike the rest of the GUI we offer).

Can we make it clear like "Add a new item with information cloned from this item"?

This is factually incorrect. An item is not being added; rather, in 19135 terminology, a proposal to add another item is added to group proposal.

That aside, in any case, putting an exhaustive description on every button in a GUI is ill-advised. Every button in any GUI has a short label that stands for something complex that the user learns to associate the button with, and this button is no different. A longer summary belongs to tooltip, to documentation, etc.

For this button’s label, half a dozen options were tried and rejected as not informative enough, too informative or factually incorrect. This is the one that was found to fit the bill. It may not be perfect so a change can be proposed but it should still satisfy the requirements.

What is being considered in the next iteration is moving all of these actions into a drop-down menu. At a cost of an extra click, it will somewhat relax the restrictions on label length and allow us to be slightly more verbose regarding all proposal-related actions while keeping in check GUI complexity.

[ronaldtse]

Editable GR identifier will eventually be gone from all proposal forms per our communication with Mike.

Good. However I am wondering this for register items that will require entering a manually-defined unique identifier, e.g. URN.

Propose another like this

I did not understand this button (until I saw the commit message...) because "like this" can mean many things.

This is factually incorrect. An item is not being added; rather, in 19135 terminology, a proposal to add another item is added to group proposal.

In 19135 there is never a thing called the "group proposal". This was made up terminology by the implementer of the previous Java backend.

In the new version we only have "proposal", and I am now proposing that we have:

• "proposal"
• "proposed change"

So in the new terminology it would be "adding a proposed change based on the data of this item (to the proposal)" would be correct. The "(to the proposal)" part could be omitted because it is understood.

That aside, in any case, putting an exhaustive description on every button in a GUI is ill-advised.

Yes. It might be easiest to just say "Clone" or "Copy this item into a new one"...

[strogonoff]

Acknowledged the new terminology, GUI will be updated to use “proposed change” more. Note that there is a slight ambiguity in the sense that “proposal” can definitely ring as a synonym of “proposed change” that we will have to work around in the GUI.

Regarding “Clone”, it is not bad, in the end I was choosing between that and the current label—I decided against because “Clone” even though short also introduces a magic word/new concept to remember which may or may not be warranted. (It is justified with Clarify, Amend, etc. that reflect standard terminology, but Clone isn’t.) Maybe it is better, this can be reevaluated after action menu overhaul…