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:
Make the UI flexible - create enough extension points in the form/wizard
so each facet will get the opportunity to be shown everywhere.
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.
I have been playing with Facets the last few weeks and must say, that they
are really great. It's pretty easy to add dedicated functionality to the
host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim mentions.
What I want to do are mostly easy thing, like adding a new tab to the host
form or host show page. Currently, the only way to do this is using deface.
But this feels pretty hacky to me and isn't good to maintain. I'd really
appreciate if there were easy and tested hooks for common areas like the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don't have a strong opinion on either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points. This
is not a nice-to-have feature, but a must-have in my opinion.
>
> 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.
+1 for the second approach if achievable, because it decouples the
model from the presentation.
This way, we should be able to be more flexible on presentation side
without bothering
the extension authors.
On the other hand, it's a bit harder to capture all the needs then to
render a proper UI.
It feels to me that we actually need both, with the first one as a fallback.
– Ivan
···
On Tue, Nov 7, 2017 at 10:45 AM, wrote:
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, 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.
Can you please include screenshots (or, even better, a quick video or gif)
of the new UI to make it easier for people to visualize who don't have the
code checked out?
Assuming I'm understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very difficult
to ensure a good UI since some other plugin could just put whatever they
want wherever in the UI.
Thanks,
Walden
···
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel wrote:
I have been playing with Facets the last few weeks and must say, that they
are really great. It’s pretty easy to add dedicated functionality to the
host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim mentions.
What I want to do are mostly easy thing, like adding a new tab to the host
form or host show page. Currently, the only way to do this is using deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d really
appreciate if there were easy and tested hooks for common areas like the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points. This
is not a nice-to-have feature, but a must-have in my opinion.
OK, I have managed to create some screenshots of the before and after
state. Please don't judge the styling - it's more about the technical
abilities than the styling.
I will take Puppet as an example. Let's say we have puppet facet that has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can be
enabled and disabled based on user's preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
···
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
>
> Hey Shim,
>
> Can you please include screenshots (or, even better, a quick video or gif)
> of the new UI to make it easier for people to visualize who don't have the
> code checked out?
>
> Assuming I'm understanding your description of the two options, I would
> also vote for option #2 as option #1 sounds like it would be very difficult
> to ensure a good UI since some other plugin could just put whatever they
> want wherever in the UI.
>
> Thanks,
> Walden
>
>
>
> On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel > wrote:
>
>> I have been playing with Facets the last few weeks and must say, that
>> they are really great. It's pretty easy to add dedicated functionality to
>> the host model and I want to use that for some of my plugins (Omaha,
>> Monitoring, something new, ...).
>> Everything is great so far except for the missing UI hooks Shim mentions.
>>
>> What I want to do are mostly easy thing, like adding a new tab to the
>> host form or host show page. Currently, the only way to do this is using
>> deface.
>> But this feels pretty hacky to me and isn't good to maintain. I'd really
>> appreciate if there were easy and tested hooks for common areas like the
>> host show page.
>>
>> In my opinion, we are already too late on finishing the facets (and
>> Pagelets) integration. Personally, I don't have a strong opinion on either
>> option. But prefer the second approach as well.
>>
>> In regards to widening the feature gap for a host ux redesign: We have to
>> provide extension points anyways. The Foreman community gains a lot of
>> value from the rich plugin ecosystem and the possibility to extend Foreman
>> fairly easy.
>> When we redo the host ux pages, we have to provide extension points. This
>> is not a nice-to-have feature, but a must-have in my opinion.
>>
>> - Timo
>>
>> --
>> 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/d/optout.
>>
>
>
I see. Yeah I'm sticking with option 2, thanks for the screenshots.
Cheers,
Walden
···
On Sun, Nov 12, 2017 at 1:36 PM, wrote:
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can be
enabled and disabled based on user’s preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or
gif) of the new UI to make it easier for people to visualize who don’t have
the code checked out?
Assuming I’m understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very difficult
to ensure a good UI since some other plugin could just put whatever they
want wherever in the UI.
I have been playing with Facets the last few weeks and must say, that
they are really great. It’s pretty easy to add dedicated functionality to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim mentions.
What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d really
appreciate if there were easy and tested hooks for common areas like the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have
to provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points.
This is not a nice-to-have feature, but a must-have in my opinion.
Timo
–
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/d/optout.
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
this information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can
be enabled and disabled based on user’s preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or
gif) of the new UI to make it easier for people to visualize who don’t have
the code checked out?
Assuming I’m understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very difficult
to ensure a good UI since some other plugin could just put whatever they
want wherever in the UI.
I have been playing with Facets the last few weeks and must say, that
they are really great. It’s pretty easy to add dedicated functionality to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim
mentions.
What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d
really appreciate if there were easy and tested hooks for common areas like
the host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have
to provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points.
This is not a nice-to-have feature, but a must-have in my opinion.
Timo
–
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/d/optout.
I like that the information is grouped together. I think that this could
easily be integrated into the host designs that were done.
···
On Sunday, November 12, 2017 at 1:36:08 PM UTC-5, ssh...@redhat.com wrote:
>
>
> OK, I have managed to create some screenshots of the before and after
> state. Please don't judge the styling - it's more about the technical
> abilities than the styling.
>
> I will take Puppet as an example. Let's say we have puppet facet that has
> the following data: puppet environment, puppet proxy and puppet ca proxy
> fields plus a list of puppet classes assigned to the host.
>
> Before:
> The information is spread on multiple screens:
> Take a look at this screenshot: https://ibb.co/bsXT8G it shows where this
> information is currently located on the main tab.
> This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
> view.
>
> After:
> Everything related to puppet is presented on a single tab. This tab can be
> enabled and disabled based on user's preference - the user can decide to
> turn puppet management on or off for this host.
> https://ibb.co/bNnd8G shows the tab when the fields are enabled, and
> https://ibb.co/eCJ72b shows all the fields disabled.
>
> I hope it helps to visualize both options.
>
>
> On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
>>
>> Hey Shim,
>>
>> Can you please include screenshots (or, even better, a quick video or
>> gif) of the new UI to make it easier for people to visualize who don't have
>> the code checked out?
>>
>> Assuming I'm understanding your description of the two options, I would
>> also vote for option #2 as option #1 sounds like it would be very difficult
>> to ensure a good UI since some other plugin could just put whatever they
>> want wherever in the UI.
>>
>> Thanks,
>> Walden
>>
>>
>>
>> On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel >> wrote:
>>
>>> I have been playing with Facets the last few weeks and must say, that
>>> they are really great. It's pretty easy to add dedicated functionality to
>>> the host model and I want to use that for some of my plugins (Omaha,
>>> Monitoring, something new, ...).
>>> Everything is great so far except for the missing UI hooks Shim mentions.
>>>
>>> What I want to do are mostly easy thing, like adding a new tab to the
>>> host form or host show page. Currently, the only way to do this is using
>>> deface.
>>> But this feels pretty hacky to me and isn't good to maintain. I'd really
>>> appreciate if there were easy and tested hooks for common areas like the
>>> host show page.
>>>
>>> In my opinion, we are already too late on finishing the facets (and
>>> Pagelets) integration. Personally, I don't have a strong opinion on either
>>> option. But prefer the second approach as well.
>>>
>>> In regards to widening the feature gap for a host ux redesign: We have
>>> to provide extension points anyways. The Foreman community gains a lot of
>>> value from the rich plugin ecosystem and the possibility to extend Foreman
>>> fairly easy.
>>> When we redo the host ux pages, we have to provide extension points.
>>> This is not a nice-to-have feature, but a must-have in my opinion.
>>>
>>> - Timo
>>>
>>> --
>>> 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/d/optout.
>>>
>>
>>
> 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.
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:
Make the UI flexible - create enough extension points in the form/wizard
so each facet will get the opportunity to be shown everywhere.
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.
I think these screenshots illustrate that pure option 2 can have negative
impact on usability. If I'm a puppet user, the puppet environment is one of
the most important thing to set. Having it in last tab completely separate
from hostgroup does not feel right. If some field of facet is part of
provisioning workflow, it should be extending provisioning UI/facet.
Another example from content management, the content source is definitely a
part provisioning, I want to be able to choose content view as an
installation medium.
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can be
enabled and disabled based on user’s preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or gif)
of the new UI to make it easier for people to visualize who don’t have the
code checked out?
Assuming I’m understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very difficult
to ensure a good UI since some other plugin could just put whatever they
want wherever in the UI.
Thanks,
Walden
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel <ma...@timogoebel.name >> <javascript:>> wrote:
I have been playing with Facets the last few weeks and must say, that
they are really great. It’s pretty easy to add dedicated functionality to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim mentions.
What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d really
appreciate if there were easy and tested hooks for common areas like the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points. This
is not a nice-to-have feature, but a must-have in my opinion.
Timo
–
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 <javascript:>.
For more options, visit https://groups.google.com/d/optout.
I think we have to distinguish two things here - there are workflows (such
as provisioning, config management, fact reporting) and there are
information aspects.
An information aspect is a set of properties that describe a host in
different system. For example puppet facet would store all properties that
are needed to describe a host in puppet. Ovirt facet would store all
properties that describe the host in ovirt system.
Workflow, on the other hand, is a set of actions that needed to be taken in
a certain order to achieve some operational goal. Examples to that would be
provisioning - a set of actions that involve different systems (dhcp, dns,
vm infrastructure and OS installer) that result in a fully operational
server. Another example would be monitoring - in this case we will want
multiple systems (like puppet's facter, vm's power status e.t.c.) to report
to the user.
Now, once we have those concepts, we can try and translate this into the
UI: In my opinion, data entry should be done from screens centered on
information aspects, regardless of the workflows where this information
could be used. On the other hand each workflow deserves a "summary" read
only screen, where we will combine data from multiple facets to show which
data would be used for that particular workflow.
From a more practical point of view, our current screens serve both
workflows and data entry. It means that we have to establish for each
screen what it tries to achieve - either it's a data entry page, such as
host's new\edit form or it's a workflow preview/result page such as host
show page. Data entry pages should be rigidly grouped by facets, but
workflow pages should be extensible, so each facet will be able to show
relevant information on the same page.
How does this sound to you?
Roxanne, does it fit with your vision of form's next generation?
···
On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
>
> I think these screenshots illustrate that pure option 2 can have negative
> impact on usability. If I'm a puppet user, the puppet environment is one
> of
> the most important thing to set. Having it in last tab completely separate
> from hostgroup does not feel right. If some field of facet is part of
> provisioning workflow, it should be extending provisioning UI/facet.
> Another example from content management, the content source is definitely
> a
> part provisioning, I want to be able to choose content view as an
> installation medium.
>
> --
> Marek
>
> --
> Marek
>
>
>
> On November 12, 2017 19:36:14 ssh...@redhat.com wrote:
>
> >
> > OK, I have managed to create some screenshots of the before and after
> > state. Please don't judge the styling - it's more about the technical
> > abilities than the styling.
> >
> > I will take Puppet as an example. Let's say we have puppet facet that
> has
> > the following data: puppet environment, puppet proxy and puppet ca proxy
> > fields plus a list of puppet classes assigned to the host.
> >
> > Before:
> > The information is spread on multiple screens:
> > Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
> this
> > information is currently located on the main tab.
> > This screenshot: https://ibb.co/ksuaoG shows the detailed puppet
> classes
> > view.
> >
> > After:
> > Everything related to puppet is presented on a single tab. This tab can
> be
> > enabled and disabled based on user's preference - the user can decide to
> > turn puppet management on or off for this host.
> > https://ibb.co/bNnd8G shows the tab when the fields are enabled, and
> > https://ibb.co/eCJ72b shows all the fields disabled.
> >
> > I hope it helps to visualize both options.
> >
> >
> > On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines > wrote:
> >>
> >> Hey Shim,
> >>
> >> Can you please include screenshots (or, even better, a quick video or
> gif)
> >> of the new UI to make it easier for people to visualize who don't have
> the
> >> code checked out?
> >>
> >> Assuming I'm understanding your description of the two options, I would
> >> also vote for option #2 as option #1 sounds like it would be very
> difficult
> >> to ensure a good UI since some other plugin could just put whatever
> they
> >> want wherever in the UI.
> >>
> >> Thanks,
> >> Walden
> >>
> >>
> >>
> >> On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel >> > wrote:
> >>
> >>> I have been playing with Facets the last few weeks and must say, that
> >>> they are really great. It's pretty easy to add dedicated functionality
> to
> >>> the host model and I want to use that for some of my plugins (Omaha,
> >>> Monitoring, something new, ...).
> >>> Everything is great so far except for the missing UI hooks Shim
> mentions.
> >>>
> >>> What I want to do are mostly easy thing, like adding a new tab to the
> >>> host form or host show page. Currently, the only way to do this is
> using
> >>> deface.
> >>> But this feels pretty hacky to me and isn't good to maintain. I'd
> really
> >>> appreciate if there were easy and tested hooks for common areas like
> the
> >>> host show page.
> >>>
> >>> In my opinion, we are already too late on finishing the facets (and
> >>> Pagelets) integration. Personally, I don't have a strong opinion on
> either
> >>> option. But prefer the second approach as well.
> >>>
> >>> In regards to widening the feature gap for a host ux redesign: We have
> to
> >>> provide extension points anyways. The Foreman community gains a lot of
> >>> value from the rich plugin ecosystem and the possibility to extend
> Foreman
> >>> fairly easy.
> >>> When we redo the host ux pages, we have to provide extension points.
> This
> >>> is not a nice-to-have feature, but a must-have in my opinion.
> >>>
> >>> - Timo
> >>>
> >>> --
> >>> 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/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...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
You're right, there are cases where it's better to separate facets and cases
where it's better to combine them. While we can define what page belongs to
which category I think more natural approach is simply say that we need to
allow both. For me, provisioning a host is a combination of workflow and data
entry based on how you defined it. Even if we change it to kind of a wizard,
some steps should be extended from facets.
But that's nothing that would contradict anything you said, I just think we
need to have solution for both.
I think we have to distinguish two things here - there are workflows (such
as provisioning, config management, fact reporting) and there are
information aspects.
An information aspect is a set of properties that describe a host in
different system. For example puppet facet would store all properties that
are needed to describe a host in puppet. Ovirt facet would store all
properties that describe the host in ovirt system.
Workflow, on the other hand, is a set of actions that needed to be taken in
a certain order to achieve some operational goal. Examples to that would be
provisioning - a set of actions that involve different systems (dhcp, dns,
vm infrastructure and OS installer) that result in a fully operational
server. Another example would be monitoring - in this case we will want
multiple systems (like puppet’s facter, vm’s power status e.t.c.) to report
to the user.
Now, once we have those concepts, we can try and translate this into the
UI: In my opinion, data entry should be done from screens centered on
information aspects, regardless of the workflows where this information
could be used. On the other hand each workflow deserves a “summary” read
only screen, where we will combine data from multiple facets to show which
data would be used for that particular workflow.
From a more practical point of view, our current screens serve both
workflows and data entry. It means that we have to establish for each
screen what it tries to achieve - either it’s a data entry page, such as
host’s new\edit form or it’s a workflow preview/result page such as host
show page. Data entry pages should be rigidly grouped by facets, but
workflow pages should be extensible, so each facet will be able to show
relevant information on the same page.
How does this sound to you?
Roxanne, does it fit with your vision of form’s next generation?
On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
I think these screenshots illustrate that pure option 2 can have negative
impact on usability. If I’m a puppet user, the puppet environment is one
of
the most important thing to set. Having it in last tab completely separate
from hostgroup does not feel right. If some field of facet is part of
provisioning workflow, it should be extending provisioning UI/facet.
Another example from content management, the content source is definitely
a
part provisioning, I want to be able to choose content view as an
installation medium.
On November 12, 2017 19:36:14 ssh...@redhat.com <javascript:> wrote:
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that
has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet
classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can
be
enabled and disabled based on user’s preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines > > > > wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or
gif)
of the new UI to make it easier for people to visualize who don’t have
the
code checked out?
Assuming I’m understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very
difficult
to ensure a good UI since some other plugin could just put whatever
they
want wherever in the UI.
Thanks,
Walden
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel <ma...@timogoebel.name > > >> > > >> <javascript:>> wrote:
I have been playing with Facets the last few weeks and must say, that
they are really great. It’s pretty easy to add dedicated functionality
to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim
mentions.
What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is
using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d
really
appreciate if there were easy and tested hooks for common areas like
the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on
either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have
to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend
Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points.
This
is not a nice-to-have feature, but a must-have in my opinion.
Timo
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
>
> Marek, you lead me to an interesting conclusion:
>
> I think we have to distinguish two things here - there are workflows (such
> as provisioning, config management, fact reporting) and there are
> information aspects.
> An information aspect is a set of properties that describe a host in
> different system. For example puppet facet would store all properties that
> are needed to describe a host in puppet. Ovirt facet would store all
> properties that describe the host in ovirt system.
> Workflow, on the other hand, is a set of actions that needed to be taken in
> a certain order to achieve some operational goal. Examples to that would be
> provisioning - a set of actions that involve different systems (dhcp, dns,
> vm infrastructure and OS installer) that result in a fully operational
> server. Another example would be monitoring - in this case we will want
> multiple systems (like puppet's facter, vm's power status e.t.c.) to report
> to the user.
>
> Now, once we have those concepts, we can try and translate this into the UI:
> In my opinion, data entry should be done from screens centered on
> information aspects, regardless of the workflows where this information
> could be used. On the other hand each workflow deserves a "summary" read
> only screen, where we will combine data from multiple facets to show which
> data would be used for that particular workflow.
I have to disagree on this point. Users shouldn't care about the
"behind the scenes" of Foreman. They want a host provisioned in their
environment and don't care if we store the data needed for that in 1
table or 10. The most important point is that the user's workflow is
easy as possible for the majority of cases, with ability to add more
information if needed in special cases. Entering a lot of info that
may or may not be needed before they can take any action with that
info feels to me like more complication, not less.
···
On Wed, Nov 15, 2017 at 2:23 PM, wrote:
From a more practical point of view, our current screens serve both
workflows and data entry. It means that we have to establish for each screen
what it tries to achieve - either it’s a data entry page, such as host’s
new\edit form or it’s a workflow preview/result page such as host show page.
Data entry pages should be rigidly grouped by facets, but workflow pages
should be extensible, so each facet will be able to show relevant
information on the same page.
How does this sound to you?
Roxanne, does it fit with your vision of form’s next generation?
On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
I think these screenshots illustrate that pure option 2 can have negative
impact on usability. If I’m a puppet user, the puppet environment is one
of
the most important thing to set. Having it in last tab completely separate
from hostgroup does not feel right. If some field of facet is part of
provisioning workflow, it should be extending provisioning UI/facet.
Another example from content management, the content source is definitely
a
part provisioning, I want to be able to choose content view as an
installation medium.
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that
has
the following data: puppet environment, puppet proxy and puppet ca proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet classes
view.
After:
Everything related to puppet is presented on a single tab. This tab can
be
enabled and disabled based on user’s preference - the user can decide to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines >> > wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or
gif)
of the new UI to make it easier for people to visualize who don’t have
the
code checked out?
Assuming I’m understanding your description of the two options, I would
also vote for option #2 as option #1 sounds like it would be very
difficult
to ensure a good UI since some other plugin could just put whatever
they
want wherever in the UI.
Thanks,
Walden
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel <ma...@timogoebel.name >> >> <javascript:>> wrote:
I have been playing with Facets the last few weeks and must say, that
they are really great. It’s pretty easy to add dedicated functionality
to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim
mentions.
What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is
using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d
really
appreciate if there were easy and tested hooks for common areas like
the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on
either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We have
to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend
Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points.
This
is not a nice-to-have feature, but a must-have in my opinion.
Timo
–
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 <javascript:>.
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Perhaps another (or additional) approach to consider is having different
"views" of the objects.
Consider hosts currently. Depending on the user's role for that moment, the
information and flows needed will be vastly different. The first engineer
may, for example, be the provisioning one. Perhaps the puppet flow is
paramount, or perhaps it's ansible, or whatever. This engineer doesn't need
or care about the other flavors. Next task for this engineer, or a
different one, is to confirm subscriptions. Another task is to check on
package versions. If I could choose which "view" I wanted for the
particular task of the day, that would be great.
The implementation could simply be that the main table had different view
choices (which columns to show) which would then lead to different
click-through pages.
As a plugin writer, I may wish to provide a view entirely my own.
Alternatively, I may wish to be included in details on other views. To me
both inline (deface style) and additional tabs (easier) are needed but
cramming every aspect of a host into a single view is not ideal.
···
On Wed, Nov 15, 2017 at 8:24 AM, Tomer Brisker wrote:
I think we have to distinguish two things here - there are workflows
(such
as provisioning, config management, fact reporting) and there are
information aspects.
An information aspect is a set of properties that describe a host in
different system. For example puppet facet would store all properties
that
are needed to describe a host in puppet. Ovirt facet would store all
properties that describe the host in ovirt system.
Workflow, on the other hand, is a set of actions that needed to be taken
in
a certain order to achieve some operational goal. Examples to that would
be
provisioning - a set of actions that involve different systems (dhcp,
dns,
vm infrastructure and OS installer) that result in a fully operational
server. Another example would be monitoring - in this case we will want
multiple systems (like puppet’s facter, vm’s power status e.t.c.) to
report
to the user.
Now, once we have those concepts, we can try and translate this into the
UI:
In my opinion, data entry should be done from screens centered on
information aspects, regardless of the workflows where this information
could be used. On the other hand each workflow deserves a “summary” read
only screen, where we will combine data from multiple facets to show
which
data would be used for that particular workflow.
I have to disagree on this point. Users shouldn’t care about the
"behind the scenes" of Foreman. They want a host provisioned in their
environment and don’t care if we store the data needed for that in 1
table or 10. The most important point is that the user’s workflow is
easy as possible for the majority of cases, with ability to add more
information if needed in special cases. Entering a lot of info that
may or may not be needed before they can take any action with that
info feels to me like more complication, not less.
From a more practical point of view, our current screens serve both
workflows and data entry. It means that we have to establish for each
screen
what it tries to achieve - either it’s a data entry page, such as host’s
new\edit form or it’s a workflow preview/result page such as host show
page.
Data entry pages should be rigidly grouped by facets, but workflow pages
should be extensible, so each facet will be able to show relevant
information on the same page.
How does this sound to you?
Roxanne, does it fit with your vision of form’s next generation?
On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
I think these screenshots illustrate that pure option 2 can have
negative
impact on usability. If I’m a puppet user, the puppet environment is one
of
the most important thing to set. Having it in last tab completely
separate
from hostgroup does not feel right. If some field of facet is part of
provisioning workflow, it should be extending provisioning UI/facet.
Another example from content management, the content source is
definitely
a
part provisioning, I want to be able to choose content view as an
installation medium.
OK, I have managed to create some screenshots of the before and after
state. Please don’t judge the styling - it’s more about the technical
abilities than the styling.
I will take Puppet as an example. Let’s say we have puppet facet that
has
the following data: puppet environment, puppet proxy and puppet ca
proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet
classes
view.
After:
Everything related to puppet is presented on a single tab. This tab
can
be
enabled and disabled based on user’s preference - the user can decide
to
turn puppet management on or off for this host. https://ibb.co/bNnd8G shows the tab when the fields are enabled, and https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines > >> > wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video or
gif)
of the new UI to make it easier for people to visualize who don’t
have
the
code checked out?
Assuming I’m understanding your description of the two options, I
would
also vote for option #2 as option #1 sounds like it would be very
difficult
to ensure a good UI since some other plugin could just put whatever
they
want wherever in the UI.
Thanks,
Walden
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel <ma...@timogoebel.name > >> >> <javascript:>> wrote:
I have been playing with Facets the last few weeks and must say,
that
they are really great. It’s pretty easy to add dedicated
functionality
to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, …).
Everything is great so far except for the missing UI hooks Shim
mentions.
What I want to do are mostly easy thing, like adding a new tab to
the
host form or host show page. Currently, the only way to do this is
using
deface.
But this feels pretty hacky to me and isn’t good to maintain. I’d
really
appreciate if there were easy and tested hooks for common areas like
the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don’t have a strong opinion on
either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We
have
to
provide extension points anyways. The Foreman community gains a lot
of
value from the rich plugin ecosystem and the possibility to extend
Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points.
This
is not a nice-to-have feature, but a must-have in my opinion.
Timo
–
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
–
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/d/optout.
Specifically talking to the new host wizard, it was designed to allow users
to basically choose a certain type of workflow which would populate the
wizard with the relevant data entry forms. This obviously only addresses
the creation of things, not necessarily the editing or viewing of them. I
don't think this type of interaction is in contrast with anything that's
been said as it's really just a delivery vehicle.
To Tom's point about customizable tables - The Host Merge design I am
currently working on will introduce this type of table.
···
On Wed, Nov 15, 2017 at 8:43 AM, Tom McKay <thomasmckay@redhat.com> wrote:
Perhaps another (or additional) approach to consider is having different
"views" of the objects.
Consider hosts currently. Depending on the user's role for that moment,
the information and flows needed will be vastly different. The first
engineer may, for example, be the provisioning one. Perhaps the puppet flow
is paramount, or perhaps it's ansible, or whatever. This engineer doesn't
need or care about the other flavors. Next task for this engineer, or a
different one, is to confirm subscriptions. Another task is to check on
package versions. If I could choose which "view" I wanted for the
particular task of the day, that would be great.
The implementation could simply be that the main table had different view
choices (which columns to show) which would then lead to different
click-through pages.
As a plugin writer, I may wish to provide a view entirely my own.
Alternatively, I may wish to be included in details on other views. To me
both inline (deface style) and additional tabs (easier) are needed but
cramming every aspect of a host into a single view is not ideal.
On Wed, Nov 15, 2017 at 8:24 AM, Tomer Brisker <tbrisker@redhat.com> > wrote:
On Wed, Nov 15, 2017 at 2:23 PM, <sshtein@redhat.com> wrote:
Marek, you lead me to an interesting conclusion:
I think we have to distinguish two things here - there are workflows
(such
as provisioning, config management, fact reporting) and there are
information aspects.
An information aspect is a set of properties that describe a host in
different system. For example puppet facet would store all properties
that
are needed to describe a host in puppet. Ovirt facet would store all
properties that describe the host in ovirt system.
Workflow, on the other hand, is a set of actions that needed to be
taken in
a certain order to achieve some operational goal. Examples to that
would be
provisioning - a set of actions that involve different systems (dhcp,
dns,
vm infrastructure and OS installer) that result in a fully operational
server. Another example would be monitoring - in this case we will want
multiple systems (like puppet's facter, vm's power status e.t.c.) to
report
to the user.
Now, once we have those concepts, we can try and translate this into
the UI:
In my opinion, data entry should be done from screens centered on
information aspects, regardless of the workflows where this information
could be used. On the other hand each workflow deserves a "summary" read
only screen, where we will combine data from multiple facets to show
which
data would be used for that particular workflow.
I have to disagree on this point. Users shouldn't care about the
"behind the scenes" of Foreman. They want a host provisioned in their
environment and don't care if we store the data needed for that in 1
table or 10. The most important point is that the user's workflow is
easy as possible for the majority of cases, with ability to add more
information if needed in special cases. Entering a lot of info that
may or may not be needed before they can take any action with that
info feels to me like more complication, not less.
From a more practical point of view, our current screens serve both
workflows and data entry. It means that we have to establish for each
screen
what it tries to achieve - either it's a data entry page, such as host's
new\edit form or it's a workflow preview/result page such as host show
page.
Data entry pages should be rigidly grouped by facets, but workflow pages
should be extensible, so each facet will be able to show relevant
information on the same page.
How does this sound to you?
Roxanne, does it fit with your vision of form's next generation?
On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
I think these screenshots illustrate that pure option 2 can have
negative
impact on usability. If I'm a puppet user, the puppet environment is
one
of
the most important thing to set. Having it in last tab completely
separate
from hostgroup does not feel right. If some field of facet is part of
provisioning workflow, it should be extending provisioning UI/facet.
Another example from content management, the content source is
definitely
a
part provisioning, I want to be able to choose content view as an
installation medium.
--
Marek
--
Marek
On November 12, 2017 19:36:14 ssh...@redhat.com wrote:
OK, I have managed to create some screenshots of the before and after
state. Please don't judge the styling - it's more about the technical
abilities than the styling.
I will take Puppet as an example. Let's say we have puppet facet that
has
the following data: puppet environment, puppet proxy and puppet ca
proxy
fields plus a list of puppet classes assigned to the host.
Before:
The information is spread on multiple screens:
Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
this
information is currently located on the main tab.
This screenshot: https://ibb.co/ksuaoG shows the detailed puppet
classes
view.
After:
Everything related to puppet is presented on a single tab. This tab
can
be
enabled and disabled based on user's preference - the user can
decide to
turn puppet management on or off for this host.
https://ibb.co/bNnd8G shows the tab when the fields are enabled, and
https://ibb.co/eCJ72b shows all the fields disabled.
I hope it helps to visualize both options.
On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines >> >> > wrote:
Hey Shim,
Can you please include screenshots (or, even better, a quick video
or
gif)
of the new UI to make it easier for people to visualize who don't
have
the
code checked out?
Assuming I'm understanding your description of the two options, I
would
also vote for option #2 as option #1 sounds like it would be very
difficult
to ensure a good UI since some other plugin could just put whatever
they
want wherever in the UI.
Thanks,
Walden
On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel <ma...@timogoebel.name >> >> >> <javascript:>> wrote:
I have been playing with Facets the last few weeks and must say,
that
they are really great. It's pretty easy to add dedicated
functionality
to
the host model and I want to use that for some of my plugins
(Omaha,
Monitoring, something new, ...).
Everything is great so far except for the missing UI hooks Shim
mentions.
What I want to do are mostly easy thing, like adding a new tab to
the
host form or host show page. Currently, the only way to do this is
using
deface.
But this feels pretty hacky to me and isn't good to maintain. I'd
really
appreciate if there were easy and tested hooks for common areas
like
the
host show page.
In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don't have a strong opinion on
either
option. But prefer the second approach as well.
In regards to widening the feature gap for a host ux redesign: We
have
to
provide extension points anyways. The Foreman community gains a
lot of
value from the rich plugin ecosystem and the possibility to extend
Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension
points.
This
is not a nice-to-have feature, but a must-have in my opinion.
- Timo
--
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 <javascript:>.
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...@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.
--
Have a nice day,
Tomer Brisker
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/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "foreman-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/ topic/foreman-dev/oqbkuOAkISc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
