1. Make the UI flexible - create enough extension points in the form/wizard
so each facet will get the opportunity to be shown everywhere.
2. Reflect the different management aspects to the user in the UI - create
a dedicated block for each facet, where it will get opportunity to show its
own data
I lean towards 2 but I think we need combination of both. The example
you've mentioned about puppet/salt/chef is a good example of 1. Config mgmt
is shared property, e.g. the facts handling is the same and at some points,
we need an extension point, e.g. in host form or detail page, I'd like to
provide chef environment or some specific fact as a regular host attribute,
not isolated in chef facet area.
But where it make sense, 2 sounds as a good approach.
--
Marek
On November 7, 2017 10:45:24 ssht...@redhat.com wrote:
I want to start a discussion about the future UX of Host creation/edit form
from facets perspective.
Let's start with a bit more explanation of facets and how I see the future
of host data model.
First of all I'll stat with the purpose of facets - they try to solve a
couple of problems: the ability to mix and match different aspects in
host's lifecycle - to get users the power to decide which parts of
lifecycle should be managed for this host. For example, some hosts should
be present in Foreman only as a book keeping record (nothing should be
managed by the foreman), but some other hosts will manage only the
provisioning part and for the third group of hosts the user wants to manage
only the configuration. Facets also solve the plugability problem - each
facet can belong to a different plugin, which will make foreman models more
flexible in the future. Another problem that facets solve is choice of
plugins with overlapping responsibilities. For example salt, chef and
puppet are competing for the same configuration management space, and the
user should be able to choose which one he wants to use, or even choose
some of them, and manage part of hosts using one plugin, while managing
other hosts using the other.
In my vision core foreman host is a bare book keeping record, while every
"manageable" aspect of hosts resides in a dedicated facet.
All this introduction was about the model - the data part of the object.
Now, about the UI part. As I can see there are two main options:
1. Make the UI flexible - create enough extension points in the form/wizard
so each facet will get the opportunity to be shown everywhere.
2. Reflect the different management aspects to the user in the UI - create
a dedicated block for each facet, where it will get opportunity to show its
own data.
Personally I incline to the second approach - for me it gets clearer for
both developers and the user where to put and expect each type of data.
Especially since I don't see too much overlapping between facets.
I would like to see more thoughts about the subject from both users and UX
team.
I did an attempt to implement the second approach in our current UI in this
PR <https://github.com/theforeman/foreman/pull/3229>, although before I
merge it, I want to make sure that I am not widening the feature gap for
host form redesign.
I will be more than happy to answer any questions, so feel free to ask me
anything.
Shim, AKA the facets guy :)
--
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.
