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 <tbris...@redhat.com> wrote: > On Wed, Nov 15, 2017 at 2:23 PM, <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. > > 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+unsubscr...@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+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.
