On Thu, Feb 9, 2017 at 5:27 PM, Tom McKay <thomasmc...@redhat.com> wrote: > I like the "add" buttons (eg. operating system) but there were some > resources that didn't have add buttons (eg. partition tables). Should all of > the associated resources have buttons? Not UX specifically, but it would > also be helpful if the choice lists were made api calls to populate choices > when opened. This way when a resource is added (perhaps on a different > browser page) that resource is selectable without a page refresh (very > painful in current new host ui). > > I would also note that it is not uncommon, at least for me, to have the > resource already existing (ie. don't need to create it) but it is either in > the wrong org/loc or missing the association (eg. template not associated > correctly). How would this case be handled?
One of ideas that came to my mind is to detect when a resource of the same name exist in a different org and offer assigning it to the current one. But that is probably problematic in terms of permissions. When can you change taxonomy assignment of a resource that you can't see in the current org? Probably only when you're an admin. > > Highlighting the fields red is great but when does that happen? Is the red > persistent (ie. I leave the wizard and return later)? Having the wizard step > number icons change color would be helpful too. Could be red if error but > maybe some other color/style to indicate that the step is incomplete? > > Plugins would need to be able to add/remote steps (eg. ansible), and change > forms. Any UX implications? > > Is there a pattern for sub-steps? Step 5, parameters, for example has three > subsections. Would there be cases where each of those lettered sections have > their own pages with a step progress bar? (Not sure if needed.) > > After I've created a host, does it become a "template" automatically? I > would like a way to, from a host, go to its wizard and duplicate (could be > just change the name and relaunch, for example). The common approach I like in other systems is to ask whether the host should be saved as a template right after it was created. What Tom describes sounds to me like host cloning that is already implemented in the Foreman. Speaking about host templates, is it something that should exist side by side with hostgroups or is it a replacement? > > Overall looks great! +1 it would be huge improvement. Especially the fact that one can save semi-configured hosts before they are provisioned. > > > > > On Wed, Feb 8, 2017 at 3:24 PM, Roxanne Hoover <rohoo...@redhat.com> wrote: >> >> All - >> >> It was identified amongst users that the Host Creation process could use >> some improvement. >> >> I've come up with a design to help reduce confusion, create a >> clearer/unobstructed path to completion and that also integrates some >> features asked for by users. >> >> I feel the design is complete in terms of the knowledge I posses, and am >> now looking for feedback from the community who I'm sure will have thoughts >> - technical or otherwise - I hadn't yet considered. >> >> Looking forward to any feedback. >> >> >> >> >> -- >> 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+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
