juju command progress ui

[Mark Ramm]

On 02/28/2013 01:17 AM, Gustavo Niemeyer wrote:
> On Thu, Feb 28, 2013 at 2:35 AM, Julian Edwards
> <julian.edwards at canonical.com>  wrote:
>>> Having a client command that blocks for 10 minutes doing absolutely
>>> nothing while the provider decides to allocate a new machine on its
>>> own time seems to me like a pretty poor user experience.
>> This is exactly what "juju deploy" does if you run it immediately after
>> bootstrap returns.
> That's not correct, and I've explained why:
>
> Bootstrap blocks while its intention isn't *requested*, at which point
> there's nothing else for this command to do. The deploy command
> blocks while its intention isn't *requested*, at which point there's
> nothing else for this command to do.

Yes, we know this. Because we are juju developers the implementation 
model fits in our heads easily.

However, the point Ian is making is that it is not clear to a new user 
that this is what is happening.  They come into the Juju world with a 
different model based on previous experience, and we need to be 
sensitive to that.  Right now folks who are new to Juju are giving us 
feedback on what Juju looks like to them when they first use it -- and 
that is an invaluable resource to those of us who can no longer see with 
beginners eyes.

And it's generally a better user experience to force the UI to conform 
to the "user model" rather than the "implementation model" because 
teaching large numbers of users to expect something different is both 
time consuming and impossible to do completely. And when software does 
not "fit your brain" you don't blame your brain, you blame the software.

What that said, I think Gustavo is absolutely right to say that it is 
important for us not to give up the async nature of juju commands -- 
that is a clear *feature* in my mind. But I agree that we need to be 
much better about helping users to understand what his happening.

You mention SMTP -- nearly all mail clients these days provide some sort 
of progress indicator to users to help them understand the difference 
between "queued up to send" and "sent." In the GUI we do something to 
help folks see this progression, and I think we need something on the 
command line too.

Proposals to help users in this context that have been floated are:

* Command line message after juju bootstrap that says the environment 
has been started, and how to watch the progress
* Command line "juju observe" command that lets you watch the progress
* Command line blocks and provides juju observe like status.

Another proposal would be to implement all three of the above with a new 
command that calls bootstrap and then observe to provide the "blocking 
experience" and we can do some user testing to see if that helps make 
things better.

Rather than talking about what we *think* might work for users, we can 
test with actual users to see what works best for them.

--Mark Ramm