Improving the UX for Operating Systems / Templates

Support
1

With the help of your suggestions I have created a proposal [1] for a more
streamlined Operating System and Provisioning Template workflow.

My goal was to make the least invasive changes with the most positive UX
payoff. I have mapped out the current and revised workflow. I think we can
eliminate: 3 workflow blockers and 2 context changes. All with somewhat
minimal UI changes.

I would like is for you to look through the proposal and give your feedback
so we can end with a solution that provides the most efficient/intuitive
workflow.

Thanks for your feedback,

Kyle

[1]
https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf

2

Kyle,

I see this as the biggest UX pain point when starting with Foreman. I
like your suggestion of an embedded edit form for both Installation
Media and Templates.

Together with this, we should consider merging Provisioning Template and
Type tabs into one. I don't understand why we have Type on a separate
tab. Also this would make the embedded editing of Templates easier to
implement.

If you want to understand the motivation for this, on our Deep Dives
page (Foreman :: Media) there is a recording of our
session of configuration of clean Foreman instance. You can find it
under the Discussion about 1.5 user interface name.

Together with this, I'd like to discuss possibility of introduction of
OS Family for Provisioning Template. We have discussed the option of
showing all templates for newly created OS (page 7 on Kyle's
wireframes). So instead associating Template with OS, users would be
presented with all of them. Most template types are less than five which
is good for a dropdown, except provision type. And for this one the OS
Family filtering could do it.

If you don't like the idea of showing all, maybe there is a way of
sticking with what we have now, but adding some extra button "Load
unassociated" which would load them all (OS Family filter would be a
bonus) and association would be done automatically when selected.

Thank you Kyle for the hard work on this, we need to improve our UI in
this area.

LZ

··· On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > With the help of your suggestions I have created a proposal [1] for a more > streamlined Operating System and Provisioning Template workflow. > > My goal was to make the least invasive changes with the most positive UX > payoff. I have mapped out the current and revised workflow. I think we can > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > minimal UI changes. > > I would like is for you to look through the proposal and give your feedback > so we can end with a solution that provides the most efficient/intuitive > workflow. > > Thanks for your feedback, > > Kyle > > [1] > https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf > > -- > You received this message because you are subscribed to the Google Groups "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas #lzap Zapletal

3

Hi Kyle,

This is interesting, thanks for sharing it. At least in my own
experience, the biggest pain is making associations which doesn't
seem addressed in detail here.

Ubuntu 14.10 is set to come out soon, and users who want to use it will
need to do a bunch of steps to enable provisioning for it:

  1. Create Ubuntu 14.10 OS
  2. Assign Installation Media
  3. Save OS
  4. Go to 'Provisioning Templates' menu
  5. Assing Ubuntu 14.10 to relevant templates - PXE, preseed, finish,
    user data, et al.
  6. Go back to the OS, and now assign a default from
    those templates from the drop down

The presentation says:

"User clicks the Template tab and now sees each applicable type
dropdown pre-populated, Users are no longer required to save the
template first. They can add templates while creating"

That's a good idea. Today, a user must make an association to an
existing OS for that dropdown to be populated, thus the convoluted steps
#4, #5, and #6.

I have an open PR that instead of making specific assocations, sets
compatibility info on a template. That would let the dropdown get
populated without the additional steps.

Also, the nice thing about automating compatibility info for templates,
for Katello users, it becomes zero steps as we can now do everything for
the user when they import OS content.

That's https://github.com/theforeman/foreman/pull/1662.

However, we need to change the assocation tab to let a user specify OS
compability based on multiple entries of OS, major, and minor – and
perhaps at the family level as well.

I have an example in a comment on the above PR.

This seems complex, but unfortunately, we would need to keep things to
let explicit OS versions, otherwise we'd end up breaking template
combinations matching (a user couldn't have separate rules for Fedora 20
and RHEL 5 for example). I would prefer to see dynamic template combos
go away entirely, but that's a topic for another day.

Any chance you could do a wireframe for a new Assocation or
Compatability tab on the templates? Or maybe you have some different
ideas about how compatability should be set.

··· On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > With the help of your suggestions I have created a proposal [1] for a more > streamlined Operating System and Provisioning Template workflow. > > My goal was to make the least invasive changes with the most positive UX > payoff. I have mapped out the current and revised workflow. I think we can > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > minimal UI changes. > > I would like is for you to look through the proposal and give your feedback > so we can end with a solution that provides the most efficient/intuitive > workflow. > > Thanks for your feedback, > > Kyle

–
Stephen Benjamin

Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham,
Michael O’Neill, Charles Peters

4

Guys,

what are your opinions? I'd like to file some feature requests but I
don't see any discussion.

Does it mean you all agree with my conclusions?

LZ

··· On Thu, Jul 24, 2014 at 06:16:29PM +0200, Lukas Zapletal wrote: > Kyle, > > I see this as the biggest UX pain point when starting with Foreman. I > like your suggestion of an embedded edit form for both Installation > Media and Templates. > > Together with this, we should consider merging Provisioning Template and > Type tabs into one. I don't understand why we have Type on a separate > tab. Also this would make the embedded editing of Templates easier to > implement. > > If you want to understand the motivation for this, on our Deep Dives > page (http://theforeman.org/media.html) there is a recording of our > session of configuration of clean Foreman instance. You can find it > under the Discussion about 1.5 user interface name. > > Together with this, I'd like to discuss possibility of introduction of > OS Family for Provisioning Template. We have discussed the option of > showing all templates for newly created OS (page 7 on Kyle's > wireframes). So instead associating Template with OS, users would be > presented with all of them. Most template types are less than five which > is good for a dropdown, except provision type. And for this one the OS > Family filtering could do it. > > If you don't like the idea of showing all, maybe there is a way of > sticking with what we have now, but adding some extra button "Load > unassociated" which would load them all (OS Family filter would be a > bonus) and association would be done automatically when selected. > > Thank you Kyle for the hard work on this, we need to improve our UI in > this area. > > LZ > > On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > > With the help of your suggestions I have created a proposal [1] for a more > > streamlined Operating System and Provisioning Template workflow. > > > > My goal was to make the least invasive changes with the most positive UX > > payoff. I have mapped out the current and revised workflow. I think we can > > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > > minimal UI changes. > > > > I would like is for you to look through the proposal and give your feedback > > so we can end with a solution that provides the most efficient/intuitive > > workflow. > > > > Thanks for your feedback, > > > > Kyle > > > > [1] > > https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf > > > > -- > > You received this message because you are subscribed to the Google Groups "Foreman users" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com. > > To post to this group, send email to foreman-users@googlegroups.com. > > Visit this group at http://groups.google.com/group/foreman-users. > > For more options, visit https://groups.google.com/d/optout. > > -- > Later, > Lukas #lzap Zapletal > > -- > You received this message because you are subscribed to the Google Groups "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas #lzap Zapletal

5

I was reading through your PR. Seems we are both trying to solve the same
problem. It would be great to unify our efforts. I like the new
functionality you have described in you reply. My goal is to eliminate as
many steps as possible for the users.

Could I get a demo of your proposal to help me understand so I can build
wireframes against it?

··· On Sunday, August 10, 2014 9:51:59 AM UTC-4, Stephen Benjamin wrote: > > On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > > With the help of your suggestions I have created a proposal [1] for a > more > > streamlined Operating System and Provisioning Template workflow. > > > > My goal was to make the least invasive changes with the most positive UX > > payoff. I have mapped out the current and revised workflow. I think we > can > > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > > minimal UI changes. > > > > I would like is for you to look through the proposal and give your > feedback > > so we can end with a solution that provides the most efficient/intuitive > > workflow. > > > > Thanks for your feedback, > > > > Kyle > > Hi Kyle, > > This is interesting, thanks for sharing it. At least in my own > experience, the biggest pain is making associations which doesn't > seem addressed in detail here. > > Ubuntu 14.10 is set to come out soon, and users who want to use it will > need to do a bunch of steps to enable provisioning for it: > > 1) Create Ubuntu 14.10 OS > 2) Assign Installation Media > 3) Save OS > 4) Go to 'Provisioning Templates' menu > 5) Assing Ubuntu 14.10 to relevant templates - PXE, preseed, finish, > user data, et al. > 6) Go back to the OS, and now assign a default from > those templates from the drop down > > The presentation says: > > "User clicks the Template tab and now sees each applicable type > dropdown pre-populated, Users are no longer required to save the > template first. They can add templates while creating" > > That's a good idea. Today, a user must make an association to an > existing OS for that dropdown to be populated, thus the convoluted steps > #4, #5, and #6. > > I have an open PR that instead of making specific assocations, sets > compatibility info on a template. That would let the dropdown get > populated without the additional steps. > > Also, the nice thing about automating compatibility info for templates, > for Katello users, it becomes zero steps as we can now do everything for > the user when they import OS content. > > That's https://github.com/theforeman/foreman/pull/1662. > > However, we need to change the assocation tab to let a user specify OS > compability based on multiple entries of OS, major, and minor -- and > perhaps at the family level as well. > > I have an example in a comment on the above PR. > > This seems complex, but unfortunately, we would need to keep things to > let explicit OS versions, otherwise we'd end up breaking template > combinations matching (a user couldn't have separate rules for Fedora 20 > and RHEL 5 for example). I would prefer to see dynamic template combos > go away entirely, but that's a topic for another day. > > Any chance you could do a wireframe for a new Assocation or > Compatability tab on the templates? Or maybe you have some different > ideas about how compatability should be set. > > > > > -- > Stephen Benjamin > > ______________________________________________________ > Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn > Handelsregister: Amtsgericht München, HRB 153243 > Geschäftsführer: Charles Cachera, Michael Cunningham, > Michael O'Neill, Charles Peters > > >
6

I do like the concept of the flow as it certainly reduces complexity. It's hard to give it a firm thumbs-up until actually trying to use it to get work done.

A big part of me, though, gets really worried around the UI. There are several new patterns introduced here and we, the combined foreman and katello developer and user communities, still have so much to do with just aligning basic patterns. The katello UI already has one or two create-in-place patterns, how does this pdf compare? Adding a "edit" link in dropdown choices seems interesting, but are we going to have to implement that in two UI frameworks (foreman's and katello's) in order to make it consistent across the entirety of the upstream product?

Could this work be done in a rough bastion UI plugin against the API perhaps? That, I think, would alleviate my concerns a lot while also being a great example towards my long-held vision of a "core" app that is extended with modules for features.

In summary, yes I do think this is a good start, and no I don't want to see anything implemented without some of the more fundamental questions answered first.

··· ----- Original Message ----- > Guys, > > what are your opinions? I'd like to file some feature requests but I > don't see any discussion. > > Does it mean you all agree with my conclusions? > > LZ > > On Thu, Jul 24, 2014 at 06:16:29PM +0200, Lukas Zapletal wrote: > > Kyle, > > > > I see this as the biggest UX pain point when starting with Foreman. I > > like your suggestion of an embedded edit form for both Installation > > Media and Templates. > > > > Together with this, we should consider merging Provisioning Template and > > Type tabs into one. I don't understand why we have Type on a separate > > tab. Also this would make the embedded editing of Templates easier to > > implement. > > > > If you want to understand the motivation for this, on our Deep Dives > > page (http://theforeman.org/media.html) there is a recording of our > > session of configuration of clean Foreman instance. You can find it > > under the Discussion about 1.5 user interface name. > > > > Together with this, I'd like to discuss possibility of introduction of > > OS Family for Provisioning Template. We have discussed the option of > > showing all templates for newly created OS (page 7 on Kyle's > > wireframes). So instead associating Template with OS, users would be > > presented with all of them. Most template types are less than five which > > is good for a dropdown, except provision type. And for this one the OS > > Family filtering could do it. > > > > If you don't like the idea of showing all, maybe there is a way of > > sticking with what we have now, but adding some extra button "Load > > unassociated" which would load them all (OS Family filter would be a > > bonus) and association would be done automatically when selected. > > > > Thank you Kyle for the hard work on this, we need to improve our UI in > > this area. > > > > LZ > > > > On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > > > With the help of your suggestions I have created a proposal [1] for a > > > more > > > streamlined Operating System and Provisioning Template workflow. > > > > > > My goal was to make the least invasive changes with the most positive UX > > > payoff. I have mapped out the current and revised workflow. I think we > > > can > > > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > > > minimal UI changes. > > > > > > I would like is for you to look through the proposal and give your > > > feedback > > > so we can end with a solution that provides the most efficient/intuitive > > > workflow. > > > > > > Thanks for your feedback, > > > > > > Kyle > > > > > > [1] > > > https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Foreman users" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-users+unsubscribe@googlegroups.com. > > > To post to this group, send email to foreman-users@googlegroups.com. > > > Visit this group at http://groups.google.com/group/foreman-users. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > Later, > > Lukas #lzap Zapletal > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Foreman users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-users+unsubscribe@googlegroups.com. > > To post to this group, send email to foreman-users@googlegroups.com. > > Visit this group at http://groups.google.com/group/foreman-users. > > For more options, visit https://groups.google.com/d/optout. > > -- > Later, > Lukas #lzap Zapletal > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout. >
7

There seems to be developer work in this area already[1], unless I am misunderstanding. Kyle, are you involved?

[1] fixes #6370 - automatically associate templates with compatible OS's
https://github.com/theforeman/foreman/pull/1662

··· ----- Original Message ----- > > I do like the concept of the flow as it certainly reduces complexity. It's > hard to give it a firm thumbs-up until actually trying to use it to get work > done. > > A big part of me, though, gets really worried around the UI. There are > several new patterns introduced here and we, the combined foreman and > katello developer and user communities, still have so much to do with just > aligning basic patterns. The katello UI already has one or two > create-in-place patterns, how does this pdf compare? Adding a "edit" link in > dropdown choices seems interesting, but are we going to have to implement > that in two UI frameworks (foreman's and katello's) in order to make it > consistent across the entirety of the upstream product? > > Could this work be done in a rough bastion UI plugin against the API perhaps? > That, I think, would alleviate my concerns a lot while also being a great > example towards my long-held vision of a "core" app that is extended with > modules for features. > > In summary, yes I do think this is a good start, and no I don't want to see > anything implemented without some of the more fundamental questions answered > first. > > > ----- Original Message ----- > > Guys, > > > > what are your opinions? I'd like to file some feature requests but I > > don't see any discussion. > > > > Does it mean you all agree with my conclusions? > > > > LZ > > > > On Thu, Jul 24, 2014 at 06:16:29PM +0200, Lukas Zapletal wrote: > > > Kyle, > > > > > > I see this as the biggest UX pain point when starting with Foreman. I > > > like your suggestion of an embedded edit form for both Installation > > > Media and Templates. > > > > > > Together with this, we should consider merging Provisioning Template and > > > Type tabs into one. I don't understand why we have Type on a separate > > > tab. Also this would make the embedded editing of Templates easier to > > > implement. > > > > > > If you want to understand the motivation for this, on our Deep Dives > > > page (http://theforeman.org/media.html) there is a recording of our > > > session of configuration of clean Foreman instance. You can find it > > > under the Discussion about 1.5 user interface name. > > > > > > Together with this, I'd like to discuss possibility of introduction of > > > OS Family for Provisioning Template. We have discussed the option of > > > showing all templates for newly created OS (page 7 on Kyle's > > > wireframes). So instead associating Template with OS, users would be > > > presented with all of them. Most template types are less than five which > > > is good for a dropdown, except provision type. And for this one the OS > > > Family filtering could do it. > > > > > > If you don't like the idea of showing all, maybe there is a way of > > > sticking with what we have now, but adding some extra button "Load > > > unassociated" which would load them all (OS Family filter would be a > > > bonus) and association would be done automatically when selected. > > > > > > Thank you Kyle for the hard work on this, we need to improve our UI in > > > this area. > > > > > > LZ > > > > > > On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > > > > With the help of your suggestions I have created a proposal [1] for a > > > > more > > > > streamlined Operating System and Provisioning Template workflow. > > > > > > > > My goal was to make the least invasive changes with the most positive > > > > UX > > > > payoff. I have mapped out the current and revised workflow. I think we > > > > can > > > > eliminate: 3 workflow blockers and 2 context changes. All with somewhat > > > > minimal UI changes. > > > > > > > > I would like is for you to look through the proposal and give your > > > > feedback > > > > so we can end with a solution that provides the most > > > > efficient/intuitive > > > > workflow. > > > > > > > > Thanks for your feedback, > > > > > > > > Kyle > > > > > > > > [1] > > > > https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "Foreman users" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-users+unsubscribe@googlegroups.com. > > > > To post to this group, send email to foreman-users@googlegroups.com. > > > > Visit this group at http://groups.google.com/group/foreman-users. > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > > Later, > > > Lukas #lzap Zapletal > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Foreman users" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-users+unsubscribe@googlegroups.com. > > > To post to this group, send email to foreman-users@googlegroups.com. > > > Visit this group at http://groups.google.com/group/foreman-users. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > Later, > > Lukas #lzap Zapletal > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Foreman users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-users+unsubscribe@googlegroups.com. > > To post to this group, send email to foreman-users@googlegroups.com. > > Visit this group at http://groups.google.com/group/foreman-users. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscribe@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout. >
8

>
> I do like the concept of the flow as it certainly reduces complexity. It's hard to give it a firm thumbs-up until actually trying to use it to get work done.
>
> A big part of me, though, gets really worried around the UI. There are several new patterns introduced here and we, the combined foreman and katello developer and user communities, still have so much to do with just aligning basic patterns. The katello UI already has one or two create-in-place patterns, how does this pdf compare? Adding a "edit" link in dropdown choices seems interesting, but are we going to have to implement that in two UI frameworks (foreman's and katello's) in order to make it consistent across the entirety of the upstream product?
>
> Could this work be done in a rough bastion UI plugin against the API perhaps? That, I think, would alleviate my concerns a lot while also being a great example towards my long-held vision of a "core" app that is extended with modules for features.
>
> In summary, yes I do think this is a good start, and no I don't want to see anything implemented without some of the more fundamental questions answered first.
>

I think we all agree this setup process is pain. Kyle hits the point
nicely. Although I like Kyle's in-tab-forms I agree with Tom we should
be converging to unified look and feel.

Tom, what are current create-in-place strategies katello uses?

In fact even simple "add new" link that opens the forms in a new browser
tab together with "refresh" button for the select lists would be a big
improvement. The key point is to enable adding associated resources
without leaving the form/loosing the entered data. This would be a win
regardless the look.

Also +1 for moving template type from it's separate tab as Lukas mentioned.

T.

··· On 08/06/2014 10:21 PM, Tom McKay wrote:

----- Original Message -----

Guys,

what are your opinions? I’d like to file some feature requests but I
don’t see any discussion.

Does it mean you all agree with my conclusions?

LZ

On Thu, Jul 24, 2014 at 06:16:29PM +0200, Lukas Zapletal wrote:

Kyle,

I see this as the biggest UX pain point when starting with Foreman. I
like your suggestion of an embedded edit form for both Installation
Media and Templates.

Together with this, we should consider merging Provisioning Template and
Type tabs into one. I don’t understand why we have Type on a separate
tab. Also this would make the embedded editing of Templates easier to
implement.

If you want to understand the motivation for this, on our Deep Dives
page (Foreman :: Media) there is a recording of our
session of configuration of clean Foreman instance. You can find it
under the Discussion about 1.5 user interface name.

Together with this, I’d like to discuss possibility of introduction of
OS Family for Provisioning Template. We have discussed the option of
showing all templates for newly created OS (page 7 on Kyle’s
wireframes). So instead associating Template with OS, users would be
presented with all of them. Most template types are less than five which
is good for a dropdown, except provision type. And for this one the OS
Family filtering could do it.

If you don’t like the idea of showing all, maybe there is a way of
sticking with what we have now, but adding some extra button “Load
unassociated” which would load them all (OS Family filter would be a
bonus) and association would be done automatically when selected.

Thank you Kyle for the hard work on this, we need to improve our UI in
this area.

LZ

On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote:

With the help of your suggestions I have created a proposal [1] for a
more
streamlined Operating System and Provisioning Template workflow.

My goal was to make the least invasive changes with the most positive UX
payoff. I have mapped out the current and revised workflow. I think we
can
eliminate: 3 workflow blockers and 2 context changes. All with somewhat
minimal UI changes.

I would like is for you to look through the proposal and give your
feedback
so we can end with a solution that provides the most efficient/intuitive
workflow.

Thanks for your feedback,

Kyle

[1]
https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas #lzap Zapletal

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas #lzap Zapletal

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

9

+1

The create in place interactions mechanisms are the same in the PDF as
Katello, the detail is populated with the create new form and they get a
breadcrumb. The difference is the add and remove lists, but the usecases
for the smaller volumes are different under OS and the interactions make
sense here.

If we are concerned with unifying the tools Foreman needs to start using
PatternFly. I would be glad to help in anyway I can.

··· On Friday, August 8, 2014 8:57:42 AM UTC-4, Tomas Strachota wrote: > > On 08/06/2014 10:21 PM, Tom McKay wrote: > > > > I do like the concept of the flow as it certainly reduces complexity. > It's hard to give it a firm thumbs-up until actually trying to use it to > get work done. > > > > A big part of me, though, gets really worried around the UI. There are > several new patterns introduced here and we, the combined foreman and > katello developer and user communities, still have so much to do with just > aligning basic patterns. The katello UI already has one or two > create-in-place patterns, how does this pdf compare? Adding a "edit" link > in dropdown choices seems interesting, but are we going to have to > implement that in two UI frameworks (foreman's and katello's) in order to > make it consistent across the entirety of the upstream product? > > > > Could this work be done in a rough bastion UI plugin against the API > perhaps? That, I think, would alleviate my concerns a lot while also being > a great example towards my long-held vision of a "core" app that is > extended with modules for features. > > > > In summary, yes I do think this is a good start, and no I don't want to > see anything implemented without some of the more fundamental questions > answered first. > > > > I think we all agree this setup process is pain. Kyle hits the point > nicely. Although I like Kyle's in-tab-forms I agree with Tom we should > be converging to unified look and feel. > > Tom, what are current create-in-place strategies katello uses? > > In fact even simple "add new" link that opens the forms in a new browser > tab together with "refresh" button for the select lists would be a big > improvement. The key point is to enable adding associated resources > without leaving the form/loosing the entered data. This would be a win > regardless the look. > > Also +1 for moving template type from it's separate tab as Lukas > mentioned. > > T. > > > > > ----- Original Message ----- > >> Guys, > >> > >> what are your opinions? I'd like to file some feature requests but I > >> don't see any discussion. > >> > >> Does it mean you all agree with my conclusions? > >> > >> LZ > >> > >> On Thu, Jul 24, 2014 at 06:16:29PM +0200, Lukas Zapletal wrote: > >>> Kyle, > >>> > >>> I see this as the biggest UX pain point when starting with Foreman. I > >>> like your suggestion of an embedded edit form for both Installation > >>> Media and Templates. > >>> > >>> Together with this, we should consider merging Provisioning Template > and > >>> Type tabs into one. I don't understand why we have Type on a separate > >>> tab. Also this would make the embedded editing of Templates easier to > >>> implement. > >>> > >>> If you want to understand the motivation for this, on our Deep Dives > >>> page (http://theforeman.org/media.html) there is a recording of our > >>> session of configuration of clean Foreman instance. You can find it > >>> under the Discussion about 1.5 user interface name. > >>> > >>> Together with this, I'd like to discuss possibility of introduction of > >>> OS Family for Provisioning Template. We have discussed the option of > >>> showing all templates for newly created OS (page 7 on Kyle's > >>> wireframes). So instead associating Template with OS, users would be > >>> presented with all of them. Most template types are less than five > which > >>> is good for a dropdown, except provision type. And for this one the OS > >>> Family filtering could do it. > >>> > >>> If you don't like the idea of showing all, maybe there is a way of > >>> sticking with what we have now, but adding some extra button "Load > >>> unassociated" which would load them all (OS Family filter would be a > >>> bonus) and association would be done automatically when selected. > >>> > >>> Thank you Kyle for the hard work on this, we need to improve our UI in > >>> this area. > >>> > >>> LZ > >>> > >>> On Thu, Jul 24, 2014 at 07:35:58AM -0700, Kyle Baker wrote: > >>>> With the help of your suggestions I have created a proposal [1] for a > >>>> more > >>>> streamlined Operating System and Provisioning Template workflow. > >>>> > >>>> My goal was to make the least invasive changes with the most positive > UX > >>>> payoff. I have mapped out the current and revised workflow. I think > we > >>>> can > >>>> eliminate: 3 workflow blockers and 2 context changes. All with > somewhat > >>>> minimal UI changes. > >>>> > >>>> I would like is for you to look through the proposal and give your > >>>> feedback > >>>> so we can end with a solution that provides the most > efficient/intuitive > >>>> workflow. > >>>> > >>>> Thanks for your feedback, > >>>> > >>>> Kyle > >>>> > >>>> [1] > >>>> > https://dl.dropboxusercontent.com/u/5892944/Foreman-OS-Template-Workflow-2014-07-23.pdf > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > Groups > >>>> "Foreman users" group. > >>>> To unsubscribe from this group and stop receiving emails from it, > send an > >>>> email to foreman-user...@googlegroups.com . > >>>> To post to this group, send email to forema...@googlegroups.com > . > >>>> Visit this group at http://groups.google.com/group/foreman-users. > >>>> For more options, visit https://groups.google.com/d/optout. > >>> > >>> -- > >>> Later, > >>> Lukas #lzap Zapletal > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Foreman users" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to foreman-user...@googlegroups.com . > >>> To post to this group, send email to forema...@googlegroups.com > . > >>> Visit this group at http://groups.google.com/group/foreman-users. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> Later, > >> Lukas #lzap Zapletal > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Foreman users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to foreman-user...@googlegroups.com . > >> To post to this group, send email to forema...@googlegroups.com > . > >> Visit this group at http://groups.google.com/group/foreman-users. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > >