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
>>>> implement it. But at the same time, I've been here for just over a
>>>> 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.
>> 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
> 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
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?