Conductor UI - some ideas for a better conductor

Mo Morsi mmorsi at redhat.com
Wed Feb 8 20:00:37 UTC 2012


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.

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.





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