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 [email protected] 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 [email protected] <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 <[email protected] > > >> > > >> <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 > > > > an > > > > >>> email to [email protected] <javascript:>. > > >>> For more options, visit https://groups.google.com/d/optout. > > > > Groups > > > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > > email to [email protected] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
