Story #1969

Control transient/persistent switch in Workbench

Added by Tom Clegg almost 8 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Start date:
04/22/2014
Due date:
% Done:

100%

Estimated time:
(Total: 10.50 h)
Story points:
2.0
Release relationship:
Auto

Subtasks

Task #2568: Pick appropriate UI widget and stick on collections#indexResolvedTom Clegg

Task #2569: Add switch widget to collections#showResolvedTom Clegg

Task #2570: Add switch widget to collections table on dashboardResolvedTom Clegg

Task #2691: Write testsResolvedTom Clegg

Task #2692: Fix colorsResolvedTom Clegg

Task #2694: Review 1969-persistent-switch branchResolvedPeter Amstutz

Associated revisions

Revision c18bde83
Added by Tom Clegg over 7 years ago

Merge branch '1969-persistent-switch'

closes #1969

Revision 471cc718 (diff)
Added by Tom Clegg over 7 years ago

Remove debug log message. refs #1969

History

#1 Updated by Peter Amstutz over 7 years ago

  • Story points set to 2.0

#2 Updated by Ward Vandewege over 7 years ago

  • Target version set to 2014-04-16 Dev tools and data/resource management

#3 Updated by Tom Clegg over 7 years ago

  • Subject changed from Control disk usage (transient/persistent switch, both manually with Workbench and routinely with pipelines; garbage collection) to Control transient/persistent switch in Workbench
  • Assigned To set to Tom Clegg

#4 Updated by Tom Clegg over 7 years ago

  • Target version changed from 2014-04-16 Dev tools and data/resource management to 2014-05-07 Storing and Organizing Data

#5 Updated by Peter Amstutz over 7 years ago

Reviewing 4fa5a3d

  1. The radio button takes up a lot of space, and is somewhat ambiguous as to which value is actually selected. I would prefer that it only show the current value, and the user clicks on it to get a pop up menu to choose the desired value seems. This would use less space on the page and be less visually ambiguous.
  2. The default seems to be that everything is "cache", unless explicitly marked persistent. This seems dangerous. Shouldn't the default be that everything is persistent, except for stuff that the system knows can be regenerated or is not very interesting?
  3. If someone else has something marked "persistent", I still see it as "cache". This is even true for admin users.
  4. In general surfacing this feature prominently on the Collections page seems like is going to be confusing and mysterious to users, and perhaps we should not expose something that is mostly handled internally. (Having it on the detail pages for individual collections is fine.)

#6 Updated by Tom Clegg over 7 years ago

Peter Amstutz wrote:

Reviewing 4fa5a3d

  1. The radio button takes up a lot of space, and is somewhat ambiguous as to which value is actually selected. I would prefer that it only show the current value, and the user clicks on it to get a pop up menu to choose the desired value seems. This would use less space on the page and be less visually ambiguous.

Radio button is better in that it's right in front of you, and one click instead of click-move-click.

Changed to a single button toggle in 4e3ac7f -- takes up less space, shows only the current state, and requires only one click.

  1. The default seems to be that everything is "cache", unless explicitly marked persistent. This seems dangerous. Shouldn't the default be that everything is persistent, except for stuff that the system knows can be regenerated or is not very interesting?

Certainly, there are some things that should default to persistent, but don't yet -- like arv-put, and job logs. (This feature is probably the easiest way to expose such gaps.)

  1. If someone else has something marked "persistent", I still see it as "cache". This is even true for admin users.

Right. Showing who else has marked item X as persistent will be a good admin feature but this is just the user feature. The flag means "I want to keep this" -- not "someone wants to keep this".

  1. In general surfacing this feature prominently on the Collections page seems like is going to be confusing and mysterious to users, and perhaps we should not expose something that is mostly handled internally. (Having it on the detail pages for individual collections is fine.)

Clicking each collection individually to see whether it's persistent sounds painful.

Perhaps this needs a different kind of UI so its purpose is more obvious.

E.g., by default you only see "persistent" things, and you have to click something to show cache-only stuff too?

#7 Updated by Anonymous over 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

Applied in changeset arvados|commit:c18bde8300e115b215e58d6930d0495b2c33b49f.

Also available in: Atom PDF