← Back to team overview

launchpad-dev team mailing list archive

  1. launchpad-dev team
  2. Mailing list archive
  3. Message #08876

Re: Plan to migrate Blueprint work items from whiteboards

  Thread Previous • Date Previous • • Thread Next 
On 06/02/12 10:17, Clint Byrum wrote:

Excerpts from Matthew Revell's message of Mon Feb 06 04:15:30 -0800 2012:

On 3 February 2012 19:28, Guilherme Salgado
<guilherme.salgado@xxxxxxxxxx>  wrote:


So, we had a chat with Matt earlier this week and while we work on the
user-testing for the team-based report we'd like to present our plan to
migrate the work items from the whiteboard to the new table. This is
roughly how we see this happening:


Thanks for this write-up. I'm not sure if you've already had a call
with Rob, so if not we need to organise that, too.


1. Change the blueprint page to have a work-item section,
inline-editable just like the whiteboard. The data displayed there will
have the exact same format[1] we use today for work items (note that
this format is used only on the Web UI; once it's validated we'll parse
it and create/update the individual work items in the DB). We want to do
it that way because:

  - it allows people to edit multiple work items at once, using a
    format they're already familiar with
  - we don't break any tools that rely on screen-scraping (if there
    are any still)
  - it's not any worse than the current user experience (in fact it can
    be considered significantly better as it will validate users input)
  - it should be much cheaper than designing a nice UI that is as
    flexible as editing things in a text area


I'd like to add some context to that last point. For those that don't
know, the work items syntax looks like this:

   Collect the materials of my past busybox integration task: DONE
   Summarise the experience then start to write the presentation: DONE
   Finish the presentation then sent to Bero for review: DONE
   Merge the change from Bero (if any), then freeze to the final
presentation: TODO
   Show the slides on Android Builder Summit: TODO

Basically, it's:
   ARBITRARY TEXT: $STATUS



There's an optional [launchpad-id] if you want the work item assigned
to someone other than the blueprint assignee.
Right, and there's also a line prefixing a block of work items (of the form "Work items [for <milestone>]"). It currently is mandatory but we may be able to make it optional. 




So, a text box for entering/editing work items makes a lot of sense
for this first step. Also, the text box wouldn't be a jarring change
from how people are already using the makeshift work items system
through blueprint whiteboards.

We can look at something more sophisticated, if that's appropriate,
for a future revision.



 From a user standpoint, the ideal experience would be that on entering
"edit mode" of the work items (by clicking, or perhaps pressing 'e' on
the viewing page), I'd be dropped into the first available slot for Work
items, in the text box, with all of them being un-locked for editting
by clicking or key navigation. ideally I'd be able to do:

[up arrow] (go to the previous work item if it exists)
[down arroa] (inverse)

[tab] take me from the description to the status, or status to assignee
(with the blueprint assignee defaulted). If in assignee, tab goes to next
line. (this is pretty much how any table of<input>'s would work I think.)

[enter] move down to the next work item. If the current one is empty,
save all of the others that were editted. Optionally have that pop up
a "do you want to save all changes?", which is confirmed with another
[enter].

[shift-delete] delete the current work item

If these are not all available on the first iteration, thats totally fine,
but at least the [tab] key and being able to edit them all at once would
be needed otherwise it will be more of a burden to use this system than
the current whiteboard based one.
On this first iteration we are keeping the exact same UI, so there will be just a second multi-line text entry (identical to the one used for the whiteboard) that you'd use to create/change work items. That means anything that works when editing the whiteboard will also work when editing work items. I think the [tab]/[enter] use cases you describe don't work currently and if that's really the case they wouldn't work on the new UI either. 


It would be nice if these were batched up in the same way as bug statuses
are, where a bit of thrashing on the status field in 15 or 20 seconds
just results in one email.


Yeah, that'd be nice; we'll keep it in mind.

--
Guilherme Salgado <https://launchpad.net/~salgado>

References

  Thread Previous • Date Previous • • Thread Next