Scoping the UI changes for 2.0

[Martin Pool]

2009/4/17 Ian Clatworthy <ian.clatworthy at internode.on.net>:
> Having opened the can of worms w.r.t. "how should we change
> the 2.0 UI?", let me clarify my objectives and how I see the
> process working.

I'm glad you sent that; I was just contemplating something similar.

We could look at slipping 2.0 to do more of these changes, but there
are already lots of good changes in there: formats, filters, better
network performance.  And the new repository format does provide the
kind of milestone that makes sense for a 2.0.  I think we can improve
the user model, but it also feels like one of the cases where adding
one more good thing to a release will keep pushing it out for a long
time.

These are really interesting and important conversations but I don't
want them to dominate getting things finished that are already almost
there.

> 1. Throw some ideas out there for debate and get all of us
>   thinking about root causes to existing UI issues.
>
> 2. Collect the feedback and classify the suggestions into
>   categories:
>
>   a. Things we should delete.
>   b. Defaults we should change.
>   c. Things we ought to add.
>   d. Documentation we need to rework based on a, b and c.
>
> 3. Do the essentials for 2.0, particularly stuff in categories
>   a and b.

I'm not disagreeing, but I do want to frame it as a bit more than
throwing ideas out there, which is a bit of what's happening in the
thread at the moment.  We want to get back to a clean and cohesive
model, and I think that may come from looking more systematically
across all of the cases we have to cover, and the constraints or goals
on them from both the user and performance sides.  Before we settled a
specific design for the new repo format we had a list of
characteristics the design had to meet and that seemed to work well.

-- 
Martin <http://launchpad.net/~mbp/>