Open Stack

Hey Ju,

thanks for your feedback, I don't think there is anything to hide and I 
would love to have everything discussed in open way. I hope you don't 
mind me cc-ing the answer to upstream list.

Furthermore what I need to stress is:
* Purpose of these wireframes was to start discussion around underlying 
concepts
* It is very first draft of wireframes, where the work is in progress 
and is not finished, I want to get feedback from the community before 
handing out next versions. I believe it's broadly understood.
* I was not focusing much on big details, more on what user can see on 
the screen in which step
* So yes, it needs to be polished, but I am very happy to gather all 
notes from anybody about some missing details so I can reflect them

On 2013/04/10 22:32, Ju Lim wrote:
>
> Jarda:
>
> I'm putting my comments / feedback here in internal email and not 
> upstream as there are so many comments including comments related to 
> general UX best practices that should have been in the design but are 
> not in there right now.  I'll explain more my reasons when we talk on 
> Monday / next week.
>
> In the meantime, here are my comments/feedback for the Logical Group 
> and Resource Class creation wireframes:
>
> *Logical Group Creation*
>
> Logical Group (aka Rack) Creation: 
> http://people.redhat.com/~jcoufal/openstack/tuskar/2013-09-30_tuskar_l-group_creation_wireframes.pdf 
> <http://people.redhat.com/%7Ejcoufal/openstack/tuskar/2013-09-30_tuskar_l-group_creation_wireframes.pdf>
>
> Page / Slide 2:
>
> (1) L-Group term is confusing.  Why not just call it out as Logical Group?
>
L-Group term is working name and nobody agreed on it, it is just 
something general, what I used for this purpose by shortening 'logical 
group'. But based on feedback until now, community really like it.

> (2) Terminology inconsistency.  Specifically, I'm referring to the 
> word Setup.  I've also seen words used in other places, such as 
> Create, Add, Configure, Setup.  In this particular slide, the 
> header/label reads "Create L-Group" but Step 1 in the workflow says 
> "L-Group Setup."
>
I agree with being consistent. But I don't see the arguments with 
Create, Add, Configure and Setup. Create is very different from Setup. 
'Setup' means configuring and 'Create' means creating the object in 
database. The whole workflow is about creating the class. In the first 
step, you do general setup. Can you please be more specific in that 
inconsistency? Or what would you suggest?

Furthermore, it's also very different Add and Create, add means add 
something existing, by importing to the list, create means creating objects.

> (3) Should IP Subnet be an open text field?  Should we try to reduce 
> erroneous typing by providing a clearer text entry field.
>
Can you give an example? Because the best user experience by operators 
is to have open field for that. You can find it in any advanced network 
setup.

> (4) We need to indicate which fields are mandatory, e.g. IP Subnet, 
> Management Node.  Note: This comment applies all the other pages / 
> slides (so I don't have to call out each item that is mandatory).
>
Yes, I agree, I was not focusing on it yet.

> (5) It should include a L-Group Name field for entry as the first 
> field where all the other fields are.  I didn't notice at all L-Group 
> Name field until I got to the next page/slide as the visuals (light 
> grey) made it hard for me to see it, and the inline editing while nice 
> was not consistent with the other fields to be entered.  Would we 
> consider suggesting a default name if a user does not type a label / 
> display name, e.g. LogicalGroup01, LogicalGroup02, etc.?  Also, why do 
> you need "…" at all?
>
Agree with regular label and text field, it's already fixed in newer 
version, but I am still working on that so it's not sent yet.
No default names, please, this doesn't make any sense and you can't 
predict anything here.

> (6) Order of the buttons at the bottom are strange.  I would think the 
> Nodes Definition should be on the left, and Back and Cancel be on the 
> right, or perhaps together.
>
I strongly disagree at this point. In any workflow the right side means 
forward and left side means back.

> (7) Why show a Back button if it's disabled?  Specifically, have we 
> decided if a function / action is not allowed whether to grey it out 
> vs. hiding it in the UI?
>
Because of consistency of 'cancel' button position.

> (8) Can user save this task if he/she gets interrupted while he/she is 
> trying to create the logical group [Save button]?
>
Nope.

> (9) Why does the "Add Node…" need a "…?"
>
The indication was there to show, that there is more options hidden 
under the label. We can find better visualization for this.

> (10) Choosing the Provisioning image does not belong in the main 
> section of Step  It should be part of adding/editing the Management 
> Node.  In current location, it's breaking the user's mental model on 
> the flow of setting up a management node.  I think you were trying to 
> find something that would allow the User to apply the image to 
> multiple management nodes.  It can easily be addressed in the widget 
> on the right with maybe a checkbox next to the image selection of "Use 
> same image for all other management nodes in this logical group" or 
> something to that effect.
>
It's not possible to choose various images to multiple Management Nodes. 
User can select only one image for all nodes (if there are more).

> (11) "Nodes Definition" button should be "Define Nodes" - per UX best 
> practices it should be a verb of what you're going to do.
>
I disagree. There were various researches and some of them were 
contradictory because it very depends on the context.

If there is 'Define Nodes' on the button, user would think, that at the 
moment when he clicks the button, he triggers some action, which is not 
true, because he only goes to next step where he need to define the 
nodes. Therefor I see more practical to have 'Nodes Definition' instead 
of 'Define Nodes'.

Very well you can see the point at provisioning step, if you label the 
button 'Provision', when user hits the button, he expects that 
provisioning will start - not true, he only goes to provisioning setup page.

> (12) I think the arrow labels should be either be nouns or actions / 
> verbs, e.g. Configure Logical Group, Configure or Add Nodes, Provision
>
Currently they are all nouns.

> (13) Can you define what user is doing in Provision? Should it be part 
> of this flow?  Reason I ask is that maybe it's part of another user's 
> function.  That's one point, and secondly the term "Provision" can 
> mean different things to different users within IT organizations / 
> operators.  I'd like to make sure also that the term Provision used 
> here by the Infrastructure Admin is indeed what Provision means to 
> him/her.
>
Admin is experienced user and if he is in workflow where he deals with 
hardware nodes, I would expect him to know, what provisioning means.
Provisioning is applying image to node, getting it ready for operation.

> (14) Should we consider a vertical navigate for the workflow vs. 
> horizon to show the 3-step process?  Specifically, if the top 
> navigation bar is going to have 3-4 levels of navigation, this will 
> potentially look a little cluttered at the top and may make it complex 
> to look at in the UI.  I might suggest trying a vertical 3 step on the 
> left.  I think it might also be nice to consider some help text in the 
> UI to help explain to the User what each step is going to do and what 
> the purpose is.  Here's are some other wizard examples to consider:
>
> (1) 
> http://www.uxmatters.com/mt/archives/2013/05/images/Fig1_mint_getstarted.png
>
> (2) http://i1.ytimg.com/vi/tuDMzLFTzzA/maxresdefault.jpg
>
> (3) 
> http://virtualswede.files.wordpress.com/2013/05/mylab_add_physcial_datastore_step2.png
>
> (4) http://www.radiusbob.com/blog/wp-content/uploads/2010/12/Picture-4.png
>
> (5) http://www.serverwatch.com/imagesvr_ce/1522/win8server%20-%203.jpg
>
This is basic bootstrap approach and I don't expect to implement 
something completely different at the moment.

Furthermore, we should make sure, that it is visualized correctly and 
that number of steps is regulated and appropriate. I don't see problem 
with horizontal approach.

> Page / Slide 5:
>
> (1) Does one assume that "Name…" uses inline-editing for typing in the 
> name?  If the checkbox says "Use IP address as a name," why not show 
> the IP address/subnet in place of the "Name…: and have a little pencil 
> icon/indicator that it's editable?  Additionally, shouldn't it say 
> (for the checkbox) "Use IP Subnet as the name" or did you mean the 
> Management IP address?
>
Name would be separate text field.
Agree with the label, I will add 'Management' to be more clear.

> (2) What unit is CPUs?  It's not consistent with Memory (MB) and Local 
> Disk (GB) which includes unit being used.
>
I need to add the unit there, missed it, thanks.

> (3) Whenever a user is prompted to put in a password, user should be 
> asked to re-enter the password.  This is a common best practice for 
> entering password information.  I'll assume this information is 
> encrypted somehow.
>
No he shouldn't. User is entering already existing password. It's like 
asking re-enter password on e-mail login.

> Page / Slide 8:
>
> (1) How do you handle deleting a Management Node if you fat fingered 
> the entry?
>
Yes, that's good point. Already answered on Liz's feedback, I added edit 
and delete icons.

> Page / Slide 12:
>
> (1) What is the "Choose from List" option?  There's no flow that 
> covers what this radio button option does.  Is it a way for someone to 
> import the nodes?  Ideally, if user is going to be manually adding 
> nodes, they should have the option to either Add Node manually or Add 
> Nodes from an external file.
>
User already has the manual way - that's what we are doing at the 
moment. The 'list' option is just indicator, that in the future, we 
might have auto-discovery way. Not in the scope for now though.

> (2) The "Create and go to Provisioning" button needs to be be 
> something consistent, be it Add Nodes and Proceed to Provision or 
> something that is clearer.  We need to be consistent with labeling and 
> terminology.
>
Sure, we can make it clearer. But user is not adding nodes, he is 
creating L-Group at that moment. But if the label is better formulated, 
I'd be happy.

> *Resource Class Creation*
>
> Resource Class Creation: 
> http://people.redhat.com/~jcoufal/openstack/tuskar/2013-09-30_tuskar_resource_class_creation_wireframes.pdf 
> <http://people.redhat.com/%7Ejcoufal/openstack/tuskar/2013-09-30_tuskar_resource_class_creation_wireframes.pdf>
>
>
> Page / Slide 1:
>
> (1) Change "Choose Type:" to "Specify Resource Class Type" or 
> something that clearly specifies what you're asking of the user.
>
Agree, going to fix this.

> (2) There needs to be a default if you're using radio button.  This is 
> a UX best practice.
>
Answered in Liz's feedback.

> (3) I won't repeat my comments from the Logical Group creation flow as 
> the same comments made previously around mandatory fields, 
> terminology, labeling applies here as well.
>
The same answers here.

> Page / Slide 5:
>
> (1) I was *surprised* to see Flavors Definition and various entries to 
> enter.  For me, it felt like going from something simple to something 
> complex looking because of how the fields showed up on the screen and 
> they are laid out.  To make a wizard look easy, we should consider 
> either putting all the fields we are going to ask up front and not 
> surprise the user.
>
It's already fixed in newer version.

> (2) Where does one label the flavor?  Shouldn't user label the flavor 
> as the first thing before specifying what the other flavor attributes 
> are?  I came back to this comment after reading a few pages / slides 
> ahead.  Basically the mental model of the user flow is a little 
> confusing the way it is.  Here's the flow I was thinking: (1) Ask user 
> how many flavors -- let them specify the flavor names or suggest 
> default ones (2) What is the capacity that I'm going to be applying to 
> these flavors. (3) Create/Generate flavors (4) Modify flavors (5) 
> Allow user to modify the overall limits/max # with ability to recreate 
> the flavors if needed as well as add more flavors, delete an existing 
> flavor, reset and clear capabilities, etc.
>
1) I am not very sure if user wants to put the number of flavors first. 
It depends on the use case and we are not sure about the workflow. My 
thinking is based on the fact, that I know what is the biggest 
specification I want to provide and because it is halfing resources, 
then I count, up to where I want to half my resource - which is actually 
the number of flavors.

But if there are multiple opinions that flavor count needs to go first, 
I am fine with switching position of those two.

We cannot suggest default names and furthermore user still doesn't have 
possibility where to specify the names at this step, because he has no 
flavors at that moment.

4) We don't want to let user modify flavors if there is assisted setup. 
We are guiding and helping user to achieve the best performance. If you 
want to set it up manually, then switch off assistant.

5) This is not how it works, because max # of VMs is strictly bound to 
hardware.

> (3) We should avoid abbreviating "Root D.," "Eph. D," and "Swap D." -- 
> it may not be obvious to a new user.
>
Already fixed in newer version and update flavor definition workflow.

> (4) I think # of Flavors should come before the Maximum Flavor size. 
>  I also believe some text to guide the user to explain what's 
> happening and why they are being asked this information will help make 
> it easier for user to understand the flow.
>
Commented in (2), since this was mentioned there.

> (5) Change "Generate" button to "Create Flavors" or something more 
> obvious what it is as my initial impression of Generate was something 
> else other than what the intention was.
>
User is not creating flavors at that step, so it doesn't make sense to 
name the button 'Create Flavors'. It's generating list of flavors for 
user, generating values, I don't see problem in that. If there are 
multiple concerns, suggestions are welcome.

> Page / Slide 9:
>
> (1) I couldn't figure out what the paperclip like icon to the right of 
> each of the flavor attributes (vCPU, RAM, etc.) meant.
>
It's linking function and it won't be part of v1, we already discussed 
it before. Anyway, it won't appear in next version of wireframes.

> Page / Slide 13:
>
> (1) I feel the Hardware requirements entry field the way it's shown 
> should be changed to something more readable and more easy to consume 
> by a user.  This pattern does not seem to be consistent with any of 
> the other data entry patterns we used in the UI designs I've seen so far.
>
Will be simplified for v1 (because of implementation complexity), there 
will be enough time to think this pattern through then.

> (2) Change term "Property" to "Attribute" to be in align with 
> international ITIL standards, which are widely adopted by customers 
> today.  Also the word "Sign" should be "condition" and the word 
> "condition" should be expression or line.  Terminology is confusing 
> and not correct.  In general, this entry field should change as it's 
> not a good way to do it the way it is.  I can show you offline other 
> options.
>
No problem with renaming the fields. I was not aware of ITIL standards 
for this fields.

> (3) Are we sure drop down listbox for Add image will work?  I don't 
> think it is a scalable proposal.  We should consider supporting a 
> search with type ahead in the drop down listbox if we go down this path.
>
We don't need anything extra scalable here. Anyway, I am changing this 
pattern to be multiple-selection dropdown based on reviews and feedbacks.

> Page / Slide 22:
>
> (1) I'm not sure the current tree selection will scale well if you 
> have large number of logical groups in the future.  I think we need to 
> rethink this one or consider other design choices as well.
>
There needs to happen some changes, because we came into various details 
during discussions.

> (2) It's not clear what vCPUn units are.
>
Number of vCPUs.

> (3) It's not clear what Disk is.  Can we clarify what this is based on 
> the resource type selected?
>
It's normal physical disk storage of the hardware.

> (4) I also think it would be ideal to show what type of resource class 
> it is in the widget on the right.
>
OK, this is good idea.

> (5) Hardware Assignment is a strange label.  Why isn't it Assign Nodes 
> or Node Assignment (if we follow your verbiage)?
>
Yes, it would be better to name it Nodes Assignment, I will reflect that.

> (6) What is Provisioning step?  See previous reference in the Logical 
> Group feedback.
>
Already answered in previous section.

> Let's discuss further offline.
>
> Thanks,
> Ju

Thanks
-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131007/419fd9de/attachment.html>