[Rdo-list] [rhos-dev] [OFI] Wireframes and UI related question

Wed Mar 5 15:15:10 UTC 2014

On Wed, Mar 05, 2014 at 09:50:31AM -0500, Liz Blanchard wrote:
> 
> On Mar 5, 2014, at 5:47 AM, Marek Hulan <mhulan at redhat.com> wrote:
> 
> > On Wednesday 05 of March 2014 10:59:53 Marek Hulan wrote:
> >> Hello,
> 
> Hi Marek,
> 
> Great questions. I will do my best to answer them.

Thanks for jumping in Liz -- more below. Taking this to rdo-list and foreman-dev...

> >> I have a few questions regarding latest wireframes I found here [1]. I think
> >> page 6 describes assignment of various services to hostgroups which would
> >> allow user to define custom layout. Is that page intended for post-April
> >> work? Is the selection of Deployment layout on page 5 only layout
> >> configuration we'll support for April drop?
> 
> Right. We decided to only allow the user to select to add optional services to host groups for this first release. This is the only thing that they can customize with respect to host groups for April.
> 
> Hugh - Would you confirm this? Should we instead just tell the user which services will be included for each host group (including optional ones)?

In fact, I would suggest we allow *no* customization of the
services-per-hostgroups for April, unless it turns out to be INCREDIBLY
EASY. We are targeting two tightly defined reference architectures
(distributed 3-node, and distributed-plus-HA 5+-node) for which the
services will be predefined. I think we need to limit the April offering
to that and plan to add limited service-per-node configuration for
June. 

> >> 
> >> Looking at page 7 and 8, do we want to display all possible configuration
> >> options (class parameters) of a given service (puppet module) to user? Or
> >> should we display just most important (probably the case) and leave rest
> >> hidden or even under some "advanced" link?
> 
> The goal of the wizard is just to display the important parameters to the user. This way they can quickly get through the wizard and have an OpenStack environment up and running. Later, they could go into the settings and update any parameter that they need to. We may need to pull in more settings than those shown in the wireframes if we identify others that are crucial for first time set-up. Also, the goal is to have smart defaults for all of these parameters so that the user would be able to just click through if they don’t want to change anything and the deployment would kick off.

Yeah, absolutely right Liz. It's an important UX exercise to get the
right set of parameters in the UI, and a further coding exercise to set
the rest via hidden defaults. We *don't* want to allow configuration of
every conceivable value right now.

> >> 
> >> Last but not least, if we have parameters which values are limited by some
> >> fixed set (e.g. hypervisor can be KVM, QEMU, VCENTER or Driver Backend) do
> >> we need to use both - radio buttons and select box instead of one field
> >> type? Is there some rule (e.g. number of possible values) for this? I'm
> >> asking because I think we should generate forms based on parameter
> >> attributes we have in DB so I'd like to know what attributes are we missing
> >> at the moment.
> 
> Great question. Typically radio buttons would be used for two values and then a drop-down would be used for 3+. I think in the example you point out (KVM, QEMU, VCENTER) this is a tricky one because if the user hasn’t selected to use Neutron networking, they won’t see the VCENTER option. So technically the wireframes should show a drop down in this case, but if there were only two options here, I’d expect a radio button. Thoughts on this?

For the moment I want to stay away from form generation, for the reasons
I described above (and in general because we have great UX designers,
who are much more capable than autogenerated forms :D). Over time, I do
think it could be useful to have metadata that describes the parameters
we want to collect and the type of widget that should be used to collect
them (the decision on that should be UX-driven, not automated), and that
metadata could be used to generate the form. But let's not attempt that
for April.
> >> 
> >> [1]
> >> http://file.bos.redhat.com/~lsurette/RHOS/2014-03-03_ofi-ui_wireframes.pdf
> > 
> > Adding [OFI] tag that I missed in subject so people using filters will see 
> > this.
> > 

Thanks for raising these questions, it's very timely.

Take care,
--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Senior Engineering Manager, Cloud Engineering                   ==
== Tuskar: Elastic Scaling for OpenStack                           ==
== http://github.com/tuskar                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey