Conductor UI - some ideas for a better conductor

Angus Thomas athomas at redhat.com
Thu Feb 9 10:24:09 UTC 2012


On 02/08/2012 08:00 PM, Mo Morsi wrote:
> On 02/06/2012 11:33 PM, Andy Fitzsimon wrote:
>>
>>>
>>> So this brings me to one point that I do want to stress... I think this
>>> outline and the demo you have are fantastic, and I hope we're able to
>>> implement it. But at the same time, I've been here for just over a year
>>> and have already seen 3 wholly different user interfaces 
>>> implemented, to
>>> the point that it's almost a running joke that we rip out and
>>> reimplement our UI when the seasons change. I think our sanity would be
>>> greatly preserved if we could approach this as a series of evolutionary
>>> improvements, as opposed to a revolutionary, "reboot"-style
>>> implementation of a fourth totally-new UI.
>
> +1
>
> We need to make sure that at we invest an equal amount of time into 
> developing and hardening the backend, eg the restful API and the CLI 
> interface.
>

+1

The value of Andy's proposals, which is substantial, is somewhat 
independent of the rate at which we're going to implement them.

Before long, we're going to get out of the bug fix/stabilisation cycles 
that have dominated recently, and get back to planning and implementing 
new features & improvements in sprints.

The backlog is, I expect, going to be pretty full because, as well as 
the issues that all of the developers surely have in mind, we're about 
to start getting a lot more feedback from users of the Aeolus (albeit in 
a productised form).

So, rather than either recoiling against, or resigning to, the idea that 
we're about to re-implement the UI, I think the opportunity at this 
stage is to get a shared understanding of a properly discussed set of 
improvements that we can make incrementally.


A couple of points which mitigate against a radical change to look and 
feel, in favour of incremental improvements:

- We have a lot in common with Katello, in that the functionalities of 
our apps are entirely complimentary. There's some effort going into 
making the two apps more visually similar, so that users can switch 
between them without a jarring disconnect. In order to continue to 
derive that benefit, we'll need to make major UI changes with some 
amount of agreement with the Katello folks.

- We're getting an increasing number of users, a lot of whom are going 
to become attached to our current UI (How could they not? ;-)) and, even 
the ones who aren't fond of it will become familiar with it. The need to 
carry that community with us in the design changes we make in future 
shouldn't be a blocker, but it should make us proceed with caution.

> Ultimately, while not graphical, the backend is an equally important 
> aspect of conductor as it allows the end-user to develop interfaces of 
> their own to meet their needs. It might make sense at some point to 
> extract the service layer stuff into its own subproject and build the 
> graphical web app separately ontop of that.
>
>

You're entirely right about the need for the API and CLI tools. I've 
enthused before about how cool spacecmd* is before. We should aim to 
have something similar.

However, I'm wary of the idea that we can separate out the building of 
the web UI somehow. As long as the capabilities of Conductor, 
deltacloud, imagefactory etc. are continuing to evolve at the current 
rate, there just isn't enough predictability for UI design to be able to 
succeed as a relatively isolated effort.

Instead, we need ongoing discussion of the UI's requirements and 
capabilities to be tied into the overall development. This thread is a 
very good example of the kind of open discussion and review that I think 
will serve us well.


* http://www.ohloh.net/p/spacecmd - To be clear, I don't only mean cool 
as in an impressive app to have put together, though it is, I also mean 
massively useful.  Wrangling many hundreds of instances in RHN is made a 
tonne easier by the ability to write wrapper scripts around spacecmd.

>
>
>
>>
>> Well, if we keep doing it wrong we're always going to have to redo 
>> it... plain and simple ;-P
>
> The tough aspect w/ GUIs is that there is no right or wrong way, and 
> different end users are going to be looking at using different 
> graphical interfaces / workflows.
>
>
>
>>
>> But I appreciate the thought and it is top of my mind to not waste 
>> our energy.  From what I've seen, the history is hardly considered 
>> from both an implementors AND designers perspective and solutions 
>> aren't resolving with a compromise but rather a cop-out.
>
> Not sure I agree, since we started Aeolus the web dev's have been 
> working pretty closely w/ the designers to flush out and realize 
> requirements. I remember working w/ Tim and then Jeremy going back to 
> the original oVirt days and then on the first Deltacloud Aggregator 
> designs and rewrites (there have been more than 3 up to this point).
>
>
>
>
>>
>> There's heaps of salvageable code and concepts from our existing UI 
>> to evolve from.  I hardly think the idea of monitoring and 
>> administering modes are going away and I can't imagine we will want 
>> to ditch pretty and grid view outright (though it would be great if 
>> we could get them both for free).
>
> This is good, but I am concerned w/ the number of issues regarding 
> fixing various aspects as to the UI and amount of time we already 
> spend on them at the end of every sprint / when doing triaging.
>
> Spending more time on and emphasising the backends while proving the 
> capacity for end users to aggregate services and consume them in their 
> own frontends would mitigate alot of this.
>
>
>
>>
>> The majority of these ideas are attempting to isolate components and 
>> implement them as part of a considered set so that we can change and 
>> evolve at any time without tea bagging our users workflow simply 
>> because a query got too expensive so we gave it some random new view.
>>
>> Right now if we want to mitigate the number of http-requests we do we 
>> have to seriously re-architect our haml.  but with a app-shell 
>> approach we can easily switch which aspects are getting too expensive 
>> for the initial load and nominate they be ajaxed when requested only.
>>
>> Right now if we want to tweak the monitoring view to be used in some 
>> weird way like a data centre kiosk it would require a serious effort 
>> and lots of cost-benefit soul-searching before we painstaikingly 
>> construct the views manually with plenty of duplication along the 
>> way.    if we keep our components homogenous and use a global app 
>> shell approach, a completely different display is as simple as 
>> changing one class which specifies what to show/hide.
>>
>
> Intriguing but this raises the question as to why have a unified web 
> interface whatsoever if things in it are going to be isolated / 
> modularized. Rather wouldn't it make sense to have seperate interfaces 
> infront of each Aeolus component (they can all be served by the same 
> webserver) with a shared layout / css stylesheet. That way everything 
> would look the same, but the administrator can enable / disable 
> components using the native system tooling rather than our own custom 
> web-shell.
>
>   -Mo
>
>




More information about the aeolus-devel mailing list