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.
HostCreationv2.pdf (13 KB)
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?
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).
Overall looks great!
···
On Wed, Feb 8, 2017 at 3:24 PM, Roxanne Hoover 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-
What you call template in the design is what Foreman users calls 'Host groups'.
Host groups define a blueprint of how the host should look like, and
Foreman groups hosts using them.
-
Once you choose a template (or rather hostgroup), it should jump to
the Review step¸ is that correct?
-
It would be awesome if we offered the option to create multiple hosts
with the same form, ala digitalocean (http://imgur.com/Liw0lo5)
I think the biggest hurdle is that we will have to rewrite our host form
to be a wizard in order to accomplish this. On the other hand, Katello
and other plugins could easily mount components or modify the state of
the current ones very easily instead of what they do with deface now
Thanks!
···
On 02/08, Roxanne Hoover 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.
–
Daniel Lobato Garcia
@dLobatog
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato
> 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 Thu, Feb 9, 2017 at 5:27 PM, Tom McKay wrote:
On Wed, Feb 8, 2017 at 3:24 PM, Roxanne Hoover rohoover@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
