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