[openstack-dev] {TripleO] UI Wireframes - close to implementation start

Liz Blanchard lsurette at redhat.com
Wed Dec 4 19:02:38 UTC 2013

On Dec 3, 2013, at 9:30 AM, Tzu-Mainn Chen <tzumainn at redhat.com> wrote:

> Hey folks,
> I opened 2 issues on UX discussion forum with TripleO UI topics:
> Resource Management:
> http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/
> - this section was already reviewed before, there is not much surprises, just smaller updates
> - we are about to implement this area
> http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/
> - these are completely new views and they need a lot of attention so that in time we don't change direction drastically
> - any feedback here is welcome
> We need to get into implementation ASAP. It doesn't mean that we have everything perfect from the very beginning, but that we have direction and we move forward by enhancements.
> Therefor implementation of above mentioned areas should start very soon.
> If all possible, I will try to record walkthrough with further explanations. If you have any questions or feedback, please follow the threads on ask-openstackux.
> Thanks
> -- Jarda
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> These wireframes look really good!  However, would it be possible to get the list of requirements driving them?  For example, something on the level of:
> 1) removal of resource classes and racks
> 2) what happens behind the scenes when deployment occurs
> 3) the purpose of "compute class"
> 4) etc
I completely agree with Mainn on this. It would be also be great to see use cases built from requirements that we can consider while reviewing wireframes. These would allow us to think in terms of how the user would come to the UI and perform the actions needed to complete their task.

Here are some additional thoughts/questions regarding the current designs:

Deployment Management

Slide 3
- I like that we are making it clear to the user which types of nodes they could add to their deployment and how many of each node will be added, but why aren't we continuing to use this method as the user may want to scale out their deployment? It seems very inconsistent to use this design just for this one use case.
- The section is labeled "Resource distribution" but the user is has a number of "unallocated nodes". I think we should try to make these terms consistent. Either "Resource distribution" and "Undistributed resources" or "Node Allocation" and "Unallocated Nodes". This would limit the terminology that a user would need to try to learn.
- Would the "More details" link bring up a description of the type of node? If so, should this just be a ? next to the title that the user could roll over? Okay. After reviewing the youtube video I understand the point of this link now. I think this should be labeled accordingly. The controller link should probably read "Controller" to match up with the navigation section. It might be better to label these both "Controller Nodes".
- Somehow, we should make it easier for the user to walk through these details steps. It's great that this initial screen allows them to just assign nodes and then quickly deploy, but when they want to dive into the details I think we need to make it much clearer how to do this without the user needing to remember that they have to select each node type section and click "Deploy". Maybe a wizard would work better?
- Would the user be able to click on the text and enter a number of nodes into the text box rather than have to click the up or down arrow?

Slide 5
- It might be a helpful hint to the user to maybe list the number of nodes that need action in each section next to the navigation item. I'm just trying to think of better ways to walk the user through if they want to look at more details on each of the nodes (or types of nodes) before deploying.
- Would there be other states that a node could be in within the "Nodes waiting for action" section? If not, this could just be the "Nodes waiting to be deployed" section.
- I like that the stacked representation of the nodes will save space, but will the user be able to perform the actions that they would need to quickly on this page? It's also inconsistent with the original first use design used in Slide 3. Maybe we could repeat this interaction and allow the user to add/remove the number of nodes quickly here? We could still use this stacked representation to monitor like nodes as you are showing in Slide 11.

Slide 6
-The addition of "Create New Compute Class" makes it seem like the user will be able to deploy these 27 nodes without being attached to a class. Or is this initial group a default resource class? How would the user move nodes from one class to another?

Slide 7
- This icon seems to be a way of telling the user that they've added all of these nodes to their "plan" and now they need to act on it. Would these notifications show as they change the number of nodes in Slide 3? I'm have a little bit of trouble following the flow of "Adding node to plan" and then "Reviewing details" and finally "Deploying". 

Slide 10
- I really like the addition of this overall status bar. Would you expect errors to pop up here too? Or would these be notifications of some sort?
- Would the user want to see the status broken out by nodes that are still deploying vs. ones that have completed? So there could be two buckets of nodes and the user could see them updating as nodes compete.
- Would clicking the "X" cancel the process of deployment? Or should there be another way to cancel?

Slide 11 
-What does the down arrow do for the user in the bottom right corner?
-When a user expands the nodes and there are more nodes that would fit on a page horizontally, would this section grow vertically? Or would the user need to scroll horizontally? How would the user then collapse these nodes again into a group?

Resource Management

Slide 3
-Would the user not be able to add a Resource Node?
-I'm not sure we need the word "Manually" on the 2nd button. Actually, should this just read "Allocate Node"?

Slide 4
-I think we should spell out "Hardware Specifications"
-I'm not sure the term "Introspect and fill for me" makes sense. Perhaps this could be "Discover default values from hardware" or something?

Slide 5
-I like that this is using the same structure as Slide 3 when there isn't any data to report. It will be a good transition for the user who comes in and deploys their first nodes.
-Should we allow the user to drill in further from here to view specific types of nodes? It seems that it would be important to match these flows up with the work being done on the Details Pages (http://ask-openstackux.rhcloud.com/question/66/tuskar-ui-node-rack-and-resource-class-details/) How would the user seamlessly navigate between these views?

> I think it'd be easier to understand the "big picture" that way.  Thanks!
> Mainn
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/dc887a65/attachment.html>

More information about the OpenStack-dev mailing list