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.
--
ROXANNE HOOVER
VISUAL & INTERACTION DESIGN
Red Hat
<https://www.redhat.com/>
rohoover@redhat.com M: 919-609-5300
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>