If the goal is, as I think it was from irc/g+ discussions, to make the
foreman UI look slightly more like the katello "two pane", then it looks
like a good start. While I do appreciate the thought, my suggestion would
be to put all UI efforts on getting the foreman v2 api built out and
feeding katello-style nutupane.
What is nutupane? Nutupane is the katello UI style, implemented in
angular.js and, backed by same RESTful API that also feeds the command line
interface (CLI) and user/customer direct API tools (python, etc.).
One of the strongest benefits of the nutupane is that it is backed by pure
REST API. I'm not sure the significance of this is truly appreciated. This
means a single point-of-entry for all consumers of the foreman/katello
features. The CLI will hit the API, customers may write their own
interactions to the API, and the UI will also call the same API. One thing
to test.
Previous iterations of UI in katello (and what is current in foreman) had
two server-side controllers: One for the API and one for the UI. The UI was
written in haml/erb and could directly access the server models and
infrastructure while they created the html to serve up to th client. From a
developer point of view, this is super simple to work in: To access a
detail on each system in a system group, just use the built-in active
record model attributes. This would lead to a disconnect in the API
controller if that same bit of info was not also shared in that controller
code. In katello there is currently a very large drift between what is
possible to see in the UI and what is possible to determine in the API/CLI.
With a single API controller serving up everything to all consumers, a
large source of potential bugs is removed. Again, I cannot emphasize the
value of this point enough.
Another benefit of nutupane is that it has been through a number of design
iterations, both at the user experience (UX) level, as well as the coding
level.
From a UX point of view, a lot of thought has gone into what you see today.
There are things like infinite scolling (just scroll down the page to have
more load), bulk actions (select N objects and perform action on all),
in-place editing of fields, and many more subtle details. The quick
implementation of "two pane" as seen in the OP screenshot is not going to
have the benefit of several years worth of iterations; it will be catch up
all the time.
I know there have been some feedback that katello's nutupane does not have
a track record of success. I would strongly disagree and argue that its
current success is exactly because of the past struggles and iterations.
The struggles were with trying to meet user/customer/UX/product
expectations with the tooling in place. Katello started where foreman is
today with basic erb/haml and js. Then jquery usage increased as demands
from users grew more complicated (and as the underlying use model in
katello grew). To meet these demands, the existing UI tooling was used and
the attempt hit a point of diminishing returns. At this point a lot of
individual effort by a couple engineers (nights, weekends, own time)
focused on picking a UI framework that would support the product demands.
Nutupane is what came out of this effort. After using it myself for a few
short weeks, I am very excited by the freedom with which it is allowing me
to think about product concepts I couldn't imagine in the old style.
Once concern of mine, that I have heard echoed in various ways by others,
is that it is "complicated." To be honest, I don't think any of the
engineers that work with MVC and have any UI javascript experience will
find working with angular.js in nutupane complicated. It is far simpler
than the javascript that existed before, in my opinion. That said, there is
certainly a learning curve in how to debug it effectively. Once I was
taught a few tricks-of-the-trade, though, it is very accessible. Remember
too that none of this UI work is being done in a vacuum: Each page
converted in katello to nutupane brings with it new examples, refinement to
existing patterns, and an increasingly veteran developer. I understand the
feeling of "complicated" but expect to be challenged for specifics if it's
suggested.
In summary, I think there are very, very compelling reasons for moving
towards the dynamic UI infrastructure that nutupane is offering. Putting
efforts into reinventing the same old "two pane" wheel that the product
outgrew a year ago does not seem like the best idea to me.
···
On Wednesday, October 9, 2013 3:28:37 AM UTC-4, Lukas Zapletal wrote:
>
> If we add more fields on the host page there, will there be a scollbar
> in the pane? Isn't it too small?
>
> Overall it looks good to me.
>
> LZ
>
> On Tue, Oct 08, 2013 at 06:24:11PM +0100, Dominic Cleal wrote:
> > I'd invite you all to play with Amos' new two pane UI:
> >
> > PR: https://github.com/theforeman/foreman/pull/937 (abenari/two_pane)
> >
> > Screenshot of the edit pane (list is as-normal):
> > http://domcleal.fedorapeople.org/foreman_pr937.png
> >
> > Feedback on the PR please :)
> >
> > --
> > Dominic Cleal
> > Red Hat Engineering
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev...@googlegroups.com .
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> Later,
>
> Lukas "lzap" Zapletal
> irc: lzap #theforeman
>