Conductor UI - some ideas for a better conductor

wes hayutin whayutin at redhat.com
Thu Feb 9 15:21:34 UTC 2012


On Thu, 2012-02-09 at 10:24 +0000, Angus Thomas wrote:
> 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.

my 2cents.. revolutionary changes in the UI dramatically affect QE's
test coverage.

spacecmd is a great tool... also one that is very difficult to automate
tests for.  I worked on satellite and RHUI which both use spacecmd,
having cmdline parity for scripting is essential when implementing a
spacecmd like interface.


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