Hello,
As part of the recent work on the usability of parameters we have attempted
to make improvements to the parameter tab in host/hostgroup edit form.
We are still considering whether to keep all the parameters in the same tab
or divide between global parameters and parameters related to puppet
classes.
Attached are 3 options we tried out:
option 1: the current situation, gives a good overview of the parameters
but is a little overwhelming to look at when you have more then 1-2 puppet
classes with 1-2 parameters.
option 2 and 3: both show the parameters by puppet class with all the
global parameters in a different tab - they let you see a clear view of
each puppet class parameters but it's harder to see a summery of all
parameters. The difference between them is the different layout of the tabs.
option 2:
option 3:
We would be glad to get feedback on which option is better and why (when do
you use the parameters tab - to see an overview or just to edit a specific
parameter? what will help you edit the host faster? what looks better?).
> Hello,
> As part of the recent work on the usability of parameters we have
> attempted to make improvements to the parameter tab in host/hostgroup
> edit form.
> We are still considering whether to keep all the parameters in the same
> tab or divide between global parameters and parameters related to puppet
> classes.
>
> Attached are 3 options we tried out:
> option 1: the current situation, gives a good overview of the parameters
> but is a little overwhelming to look at when you have more then 1-2
> puppet classes with 1-2 parameters.
This issue is just about Puppet class parameter lists, and not the
combination of global or class parameters?
If the list is overwhelming when large, how about collapsible areas per
module or class? It could let you drill down quickly if it's easy to
close/open them all at once. Equally it doesn't penalise users with
additional clicking who only have a couple of parameters.
> option 2 and 3: both show the parameters by puppet class with all the
> global parameters in a different tab - they let you see a clear view of
> each puppet class parameters but it's harder to see a summery of all
> parameters. The difference between them is the different layout of the tabs.
> option 2:
>
> option 3:
I stick by my review comments that this number of tabs was too confusing.
>> Hello,
>> As part of the recent work on the usability of parameters we have
>> attempted to make improvements to the parameter tab in host/hostgroup
>> edit form.
>> We are still considering whether to keep all the parameters in the same
>> tab or divide between global parameters and parameters related to puppet
>> classes.
>>
>> Attached are 3 options we tried out:
>> option 1: the current situation, gives a good overview of the parameters
>> but is a little overwhelming to look at when you have more then 1-2
>> puppet classes with 1-2 parameters.
>
> This issue is just about Puppet class parameter lists, and not the
> combination of global or class parameters?
>
> If the list is overwhelming when large, how about collapsible areas per
> module or class? It could let you drill down quickly if it's easy to
> close/open them all at once. Equally it doesn't penalise users with
> additional clicking who only have a couple of parameters.
I think I prefer this too. I dislike two separate tabs (I'll go into
more detail below), and feel that all the parameters should be on one
page somehow. Using collapsible areas, with everything defaulting to
collapsed would probably be fine - most of the time, you're not going
to change the defaults, and if you are, you probably know which ones
you need to change.
>> option 2 and 3: both show the parameters by puppet class with all the
>> global parameters in a different tab - they let you see a clear view of
>> each puppet class parameters but it's harder to see a summery of all
>> parameters. The difference between them is the different layout of the tabs.
>> option 2:
>>
>> option 3:
>
> I stick by my review comments that this number of tabs was too confusing.
I agree. Option 3 with a second line of tabs feels like screen estate
is being wasted for not much gain. Option 2 is ok, but is really just
an inferior version of Option-1-with-collapsible-areas.
I'd also consider putting global parameters first in Option 1, above
the puppet params. In my own experience, there's usually not many, and
they're usually important.
Greg
···
On 13 October 2015 at 14:40, Dominic Cleal wrote:
> On 13/10/15 14:31, Ori Rabin wrote:
> Hello,
> As part of the recent work on the usability of parameters we have attempted
> to make improvements to the parameter tab in host/hostgroup edit form.
> We are still considering whether to keep all the parameters in the same tab
> or divide between global parameters and parameters related to puppet
> classes.
Thanks for trying to get early feedback. I'm sure it'll ultimately help
you getting your changes merged much sooner.
>
> Attached are 3 options we tried out:
> option 1: the current situation, gives a good overview of the parameters
> but is a little overwhelming to look at when you have more then 1-2 puppet
> classes with 1-2 parameters.
As other mentioned, it might not be as bad if you could collapse some of
these tables? That aside, to me the overwhelming number of separator lines,
makes it a bit hard to read.
Doing that seems like a step in the right direction towards an easier to
understand table. At first glance 2 things go through my head:
1 - Is the UI broken? Why do I not have any of these parameters?
2 - How do I create them? What are they?
Any thoughts from someone more educated than me on these issues?
>
>
>
> option 2 and 3: both show the parameters by puppet class with all the
> global parameters in a different tab - they let you see a clear view of
> each puppet class parameters but it's harder to see a summery of all
> parameters. The difference between them is the different layout of the tabs.
> option 2:
Option 2 looks hideous in my opinion and shouldn't be considered. It's a
really strange pattern I don't recognize and it makes me think Puppet is
clickable or something. Really odd
I do agree it kind of penalizes users with few parameters.
>
>
>
> We would be glad to get feedback on which option is better and why (when do
> you use the parameters tab - to see an overview or just to edit a specific
> parameter? what will help you edit the host faster? what looks better?).
Either 3 or fixing 1 would be fine with me. Perhaps 1 allows for more incremental
fixes to a point where we all can be happy with the result. Again if you
have some research to look at about multiple-tabs in UX that'd surely be
helpful.
This may either be a brilliant idea or a dumb idea:
For the Puppet Class Parameters, has it been considered to have these
somehow in the same UI as the Included Classes on the Puppet Classes tab?
It just seems to me the workflow for seeing/overriding these parameters
would go more smoothly if they're on the same page as where you make the
selections. thanks.
That's least a three-level menu, not two though. The first is the
"Parameters" tab, the second is "Class parameters", the third is the
class name on the left. Arguably, the application menu bar is a fourth.
···
On 14/10/15 15:09, Daniel Lobato Garcia wrote:
> On 10/13, Ori Rabin wrote:
>> option 3:
>
> I don't have anything against this, in fact IMO it looks neat and UX
> people vetted it -
> https://www.patternfly.org/wikis/navigation/primary-navigation-bar/#two_level_menu
This is something which I often wish could be improved, and I've thought a
little bit about it. In my use cases, the problem is not so much that there
are too many parameters, but that there are too many parameters which have
a value which is set by a higher level (class/hostgroup/parent hostgroup),
and not intended to be modified after that.
Since Foreman allows a less experienced user to perform tasks which
required more experience before Foreman was in use, the user may not be so
knowledgeable about which parameters need to be changed when creating a
host, or they change parameters which should have been left alone.
If the parameters could be pinned at a certain level, those parameters
might be separable from the overall view in a collapsed tab or grayed out.
The opposite case could also be used – that of requiring the host to set a
parameter that would fail creation if not set at that level.
I'm not sure about the feasibility of this, but I thought I'd add my 2
cents from a Foreman administrator perspective.
···
On Wednesday, October 14, 2015 at 6:20:50 AM UTC-7, Dominic Cleal wrote:
>
> On 14/10/15 15:09, Daniel Lobato Garcia wrote:
> > On 10/13, Ori Rabin wrote:
> >> option 3:
> >
> > I don't have anything against this, in fact IMO it looks neat and UX
> > people vetted it -
> >
> https://www.patternfly.org/wikis/navigation/primary-navigation-bar/#two_level_menu
>
> That's least a three-level menu, not two though. The first is the
> "Parameters" tab, the second is "Class parameters", the third is the
> class name on the left. Arguably, the application menu bar is a fourth.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
> >> option 3:
> >
> > I don't have anything against this, in fact IMO it looks neat and UX
> > people vetted it -
> >
> https://www.patternfly.org/wikis/navigation/primary-navigation-bar/#two_level_menu
>
> That's least a three-level menu, not two though. The first is the
> "Parameters" tab, the second is "Class parameters", the third is the
> class name on the left. Arguably, the application menu bar is a fourth.
>
AFAIU the main usability problem in the current (option-1) situation is the
fact that initial value and override value are in different places on the
screen.
fixing override to be inline (e.g. you see the current value, all the other
info is in a pop over) would solve most of it imho.
regarding hiding parameters in tabs, I'm also not in favour as other
described (multiple clicks, lack of visibility etc).
I would also argue that we dont need to hide values by default, imho these
days people are very used to scroll, we could also hide all values but I
don't think it should be by default.
Ori - can you create option-4 - similar layout as in option 1 but with the
following changes:
initial and override value is inline
Optionally consider moving the global/class/smart parameters into
sections (similar to how our manual is - scrollspy afair)
bonus points ifa table with no result has some nicer explanation of why
(as Daniel said)
Thanks,
Ohad
···
On Wed, Oct 14, 2015 at 4:20 PM, Dominic Cleal wrote:
> On 14/10/15 15:09, Daniel Lobato Garcia wrote:
> > On 10/13, Ori Rabin wrote:
