Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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 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 > wrote: > >> On Wed, Nov 15, 2017 at 2:23 PM, 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
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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: > On Wed, Nov 15, 2017 at 2:23 PM, 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
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
On Wed, Nov 15, 2017 at 2:23 PM, 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 >> >>
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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. -- Marek On středa 15. listopadu 2017 13:23:17 CET ssht...@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. > > 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 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
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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. >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. Curren
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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 ssht...@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+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.
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
Thanks for the screenshots! 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. >>> >> >> -- 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.
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
I prefer 2 with adding new extension points for the individual cases where necessary. M. On Tue, Nov 14, 2017 at 12:45 AM, Walden Raines wrote: > 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. >>> >>> 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+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.
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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. >> >> 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+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.
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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+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.
[foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
