Conductor UI - some ideas for a better conductor

wes hayutin whayutin at redhat.com
Thu Feb 9 15:46:32 UTC 2012


On Thu, 2012-02-09 at 10:23 -0500, Bryan Kearney wrote:
> On 02/09/2012 10:21 AM, wes hayutin wrote:
> > 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.
> >
> 
> 
> why is it hard to test? is it because there is no straight command line?
Its difficult to script automation tests... At the time I was looking at
it only the "expect" tool was a possible option.  Using expect really
blows.  Having parity w/ standard cli commands makes a spacecmd like
interface more digestible to QE, and sysadmins probably.
> 
> -- bk





More information about the aeolus-devel mailing list