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):
Feedback on the PR please 
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+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.–
Later,
Lukas “lzap” Zapletal
irc: lzap #theforeman
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 >For reference, the comments posted here
https://github.com/theforeman/foreman/pull/937#issuecomment-25952554 are
just the tip of the iceburg, as they say, to the sort of "reinventing the
wheel" that would need to happen.
···
On Sunday, October 13, 2013 12:44:09 PM UTC-4, Thomas McKay wrote: > > 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 >> >>
> 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.
>
>
Thomas, this was well put. The only thing I question and have not seen in
your post is - why two pane? I have yet to see a usecase which supports
this interaction. I would hate to see the Foreman developers spend one
second on an interaction that adds unnecessary complexity. From what I have
seen in the demo link this really hurts the user experience. It suffers
from the issues stated above where it really make poor use of the screen
real estate and limits the users ability to quickly find objects or even
generally browse the data-grid. I would hate to see this interaction get in
the application especially if it is just because Katello has it.
···
On Sunday, October 13, 2013 12:44:09 PM UTC-4, Thomas McKay wrote: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.pngFeedback 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
for all the reasons we want to continue to show the master list of the
objects while viewing details on the right.
The metaphor of:
- view details of an object and move to an entirely new page
- hit the back button to get back to the list
mechanism is very painful and our users (foreman, katello, spacewalk,
etc) have suffered with this UI pattern forever.
the '2 pane' approach of showing at least one column of the list and
where you came from helps keep your context in the things you are
managing. As a user who has been using Katello's 'old 2 pane' which we
all agree, blows, the one good thing about it is that you always know
where you are when you are viewing. The Katello new2pane approach
addresses the combination of showing a full page grid + and details on
one screen.
Mike