← Back to team overview

launchpad-dev team mailing list archive

Re: Plan to migrate Blueprint work items from whiteboards

 

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.

> 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.

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.

Thanks for working on this LP team!


Follow ups

References