On 01/06/2015 04:24 PM, Dan Callaghan wrote:
I've just published the first draft of the design proposal for
job page
improvements, which we are targetting for Beaker 21.
https://beaker-project.org/dev/proposals/job-page-improvements.html
It's proposing some substantial changes to the layout and UI of the job
page and the recipe page (similar in scale to the system page
improvements in Beaker 19). Please take a look and send any feedback to
the list.
This looks really good to me, thanks. Nicely lays out the big picture
before moving on to the more concrete proposals (which I think will
represent a substantial improvement over the status quo).
One new insight that occurred to me while reading the list of use cases
(specifically, use case 11) is that new Beaker users are currently
unlikely to realise that the default behaviour is to automatically
delete job results after 30 days until they first hit a case where they
go to look at some job results and they're not there any more. We
display the name of the retention policy on the job results page, but we
don't give any hint as to what that actually *means* in terms of the
future behaviour of the system.
This means we're making a lot of implicit assumptions about user knowledge:
* they know that job results are deleted by default
* they know this is controlled by the retention policy
* they know that retention policies can either have a specific number of
days associated with them or else refer to an external CPE [1] based
retention policy
* they know the mapping from policy names to numbers of days (and which
policies mean "retained indefinitely" or "defined in another system")
* they know that this countdown starts from the job completion time (I
think...)
It would be far more user friendly to display "Scheduled deletion"
information, with a widget to change the scheduled deletion time by
changing the retention policy. In the case of environments where log
retention is defined in an external system or policy based on a given
CPE identifier, it would also be highly desirable to provide an inline
link to that external system/policy document that explains what the
available policies actually mean.
However, that should probably go in as a "deferred feature" rather than
being part of the base proposal.
As a potentially simpler interim fix, we may also want to change the
name of the default "scratch" policy to the more explicit "30days".
Cheers,
Nick.
[1]
http://scap.nist.gov/specifications/cpe/
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect