Pending Changes usability issues

Christer Palm

(56●4●1) Dec 09 '10, 10:38 a.m.

Hello!
We're evaluating RTC 3.0 and while testing some basic use cases I found some usability issues with the Pending Changes view in the Eclipse client.

1. Attempting to split a set of changes into multiple change sets by selecting some individual changed resources in Pending Changes and then selecting Check-in and Deliver from the context menu does not work as expected. Rather than working on the selection set, all pending changes against the component are checked in and delivered. A related use case would be trying to exclude some local changes from the delivery. This is in contrast to the Check-in action which does work on the selection set only.

2. The Ignore action in the Pending Changes view first asks Are you sure? and then after the user says Yes, pops up a warning explaining the consequences of the action. However, at that point it is already too late as the user has already accepted. The explanation should appear before (or together with) asking for confirmation.

3. Selecting Flow Targets: Show all (advanced) in Preferences disables the ability to add new flow targets to a workspace from the Pending changes view.

Is this something that will be fixed in the future?

0 votes

4 answers

7,881 views

0 votes

4 answers

Permanent link

Tim Mok

JAZZ DEVELOPER (6.6k●3●8) Dec 09 '10, 12:10 p.m.

Hello!
We're evaluating RTC 3.0 and while testing some basic use cases I found some usability issues with the Pending Changes view in the Eclipse client.

1. Attempting to split a set of changes into multiple change sets by selecting some individual changed resources in Pending Changes and then selecting Check-in and Deliver from the context menu does not work as expected. Rather than working on the selection set, all pending changes against the component are checked in and delivered. A related use case would be trying to exclude some local changes from the delivery. This is in contrast to the Check-in action which does work on the selection set only.

2. The Ignore action in the Pending Changes view first asks Are you sure? and then after the user says Yes, pops up a warning explaining the consequences of the action. However, at that point it is already too late as the user has already accepted. The explanation should appear before (or together with) asking for confirmation.

3. Selecting Flow Targets: Show all (advanced) in Preferences disables the ability to add new flow targets to a workspace from the Pending changes view.

Is this something that will be fixed in the future?

Please open work items on the first two issues. They sound like something that should be fixed.

For the show all flows mode, Pending Changes doesn't have anything to add flow targets to the workspace's flow table directly. Changing flow targets will add a target to the flow table if it does not already exist. However, that action is disabled because changing flow targets is irrelevant in all flows mode. You can still add flow targets by editing the workspace and adding the flow target.

0 votes

Permanent link

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Dec 09 '10, 10:38 p.m.

You should feel free to submit a work item for each of these issues.
My personal opinion:
(1) When the user has multi-selected several changes, then one could see
how you'd expect this "partial checkin" behavior you describe. But what
if the user just right clicks on a single change, and selects "checkin
and deliver". Normally one wants to checkin and deliver a whole change
set, not just one change in that change set (i.e. the current behavior).
So the downside of the semantics you describe is that it would break
this normal semantics.
Note that they way to achieve what you want is to first move the changes
into a new change set, and then execute the checkin and deliver operation.
(2) I agree this should be fixed.
(3) I agree this should be fixed. You should be able to change the
"current" target (which affects whether you get a "delivering to
non-current target" warning), and you should be able to add a new target.

Cheers,
Geoff

On 12/9/2010 10:53 AM, cpalm wrote:

Hello!
We're evaluating RTC 3.0 and while testing some basic use cases I
found some usability issues with the Pending Changes view in the
Eclipse client.

1. Attempting to split a set of changes into multiple change sets by
selecting some individual changed resources in Pending Changes and
then selecting Check-in and Deliver from the context menu does not
work as expected. Rather than working on the selection set, all
pending changes against the component are checked in and delivered. A
related use case would be trying to exclude some local changes from
the delivery. This is in contrast to the Check-in action which
does work on the selection set only.

2. The Ignore action in the Pending Changes view first asks Are you
sure? and then after the user says Yes, pops up a warning explaining
the consequences of the action. However, at that point it is already
too late as the user has already accepted. The explanation should
appear before (or together with) asking for confirmation.

3. Selecting Flow Targets: Show all (advanced) in Preferences disables
the ability to add new flow targets to a workspace from the Pending
changes view.

Is this something that will be fixed in the future?

0 votes

Permanent link

Christer Palm

(56●4●1) Dec 10 '10, 9:02 a.m.

Hi!
Thanks for your response. I have opened defects 147950, 147952 and 147954 to track those issues.

Wrt the scope of Check-in and deliver I definitely agree that the normal use case would be that the user wants to deliver all unresolved changes. However, would he really drill down and invoke the deliver from the individual change level in that case? Anyway, if that would be an issue, it could easily be covered for by adding having two actions: "Check-in and deliver all changes" and "Check-in and deliver selected changes" (where the latter is only visible when individual changes have been selected).

Best regards,
Christer Palm

0 votes

Permanent link

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Dec 10 '10, 9:08 p.m.

WRT the "check-in and deliver selected changes" operation ... one would
also want just "check in selected changes". And perhaps "suspend
selected changes" ...

The problem is that extra operations on the context menu are not "free"
.... they introduce conceptual load on the user, and the possibility of
confusion "ooops ... I clicked the wrong check-in and deliver variant".
So whenever one is considering adding a new context menu, one needs to
balance the benefit of the operation against that cost.

Cheers,
Geoff

On 12/10/2010 9:08 AM, cpalm wrote:

Hi!
Thanks for your response. I have opened defects 147950, 147952 and
147954 to track those issues.

Wrt the scope of Check-in and deliver I definitely agree that the
normal use case would be that the user wants to deliver
all unresolved changes. However, would
he really drill down and invoke the deliver from the individual
change level in that case? Anyway, if that would be an issue, it
could easily be covered for by adding having two actions:
"Check-in and deliver all
changes" and "Check-in and deliver selected
changes" (where the latter is only visible when
individual changes have been selected).

Best regards,
Christer Palm

0 votes

Your answer

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,067

Question asked: Dec 09 '10, 10:38 a.m.

Question was seen: 7,881 times

Last updated: Dec 09 '10, 10:38 a.m.

Pending Changes usability issues

Christer Palm

4 answers

7,881 views

0 votes

4 answers

Tim Mok

Geoffrey Clemm

Christer Palm

Geoffrey Clemm

Your answer

Follow this question

Question details

Related questions