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 <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 > >>> > >>> -- > >>> 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 <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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
