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