Conductor UI - some ideas for a better conductor

Bryan Kearney bkearney at redhat.com
Thu Feb 9 15:23:33 UTC 2012


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?

-- bk



More information about the aeolus-devel mailing list