Jump to: navigation, search

Difference between revisions of "Heat/UI"

Line 3: Line 3:
 
=== Summary ===
 
=== Summary ===
 
This is a proposal for an additional field, "keywords", to be added to the HOT specification. This field will contain a list of keywords related to the Stack that generally describe the purpose of the Stack.
 
This is a proposal for an additional field, "keywords", to be added to the HOT specification. This field will contain a list of keywords related to the Stack that generally describe the purpose of the Stack.
 
  
 
=== Use Case ===
 
=== Use Case ===
Line 30: Line 29:
 
page. Putting the stack-description in the stack-list table would take up
 
page. Putting the stack-description in the stack-list table would take up
 
too much room from a design standpoint.
 
too much room from a design standpoint.
 
  
 
=== Specification ===
 
=== Specification ===
Line 37: Line 35:
 
   - mysql
 
   - mysql
 
   - lamp
 
   - lamp
 
  
 
=== Implementation ===
 
=== Implementation ===
 
In order for the keywords to be searchable, the ideal implementation would include adding a child table to the stacks table in the heat database, then adding an option to the stacks_list API endpoint to query stacks by keywords and to return all keywords per stack in the stacks_list and stack_show API endpoints.
 
In order for the keywords to be searchable, the ideal implementation would include adding a child table to the stacks table in the heat database, then adding an option to the stacks_list API endpoint to query stacks by keywords and to return all keywords per stack in the stacks_list and stack_show API endpoints.
 
  
  
 
== Help Text ==
 
== Help Text ==
 
  
 
=== Summary ===
 
=== Summary ===
 
Currently each parameter in the HOT syntax has a field called "description" that describes the purpose of the parameter. I am proposing an additional field called "help" that can further explain a parameter.
 
Currently each parameter in the HOT syntax has a field called "description" that describes the purpose of the parameter. I am proposing an additional field called "help" that can further explain a parameter.
 
  
 
=== Use Case ===
 
=== Use Case ===
Line 70: Line 64:
 
compute instance." A help string for this same parameter would be, "To
 
compute instance." A help string for this same parameter would be, "To
 
learn more about nova keypairs visit this help article: http://www.learnsomething.com/keypairs"
 
learn more about nova keypairs visit this help article: http://www.learnsomething.com/keypairs"
 
  
 
=== Specification ===
 
=== Specification ===
Line 77: Line 70:
 
             description: This is the name of a nova key pair that will be used to ssh to the compute instance.
 
             description: This is the name of a nova key pair that will be used to ssh to the compute instance.
 
             help: To learn more about nova key pairs visit this help article: http://www.learnsomething.com/keypairs
 
             help: To learn more about nova key pairs visit this help article: http://www.learnsomething.com/keypairs
 
  
 
=== Implementation ===
 
=== Implementation ===
 
Adding Help text to the HOT syntax should only require an update to the HOT specification and guide. There are no other known code changes required.
 
Adding Help text to the HOT syntax should only require an update to the HOT specification and guide. There are no other known code changes required.

Revision as of 19:15, 4 December 2013

Stack Keywords

Summary

This is a proposal for an additional field, "keywords", to be added to the HOT specification. This field will contain a list of keywords related to the Stack that generally describe the purpose of the Stack.

Use Case

Assume that an end-user of Heat has spun up 20 stacks and has now requested help from a Support Operator of heat. In this case, the end-user did not have a solid naming convention for naming his stacks, they are all named "tim1", "tim2", etcŠ And also his request to the Support Operator was really vague, like "My Wordpress stack is broken."

The first thing that the Support Operator would do, would be to pull up end-user's stacks in either Horizon or via the heat client api. In both cases, at the moment, he would then have to either stack-show on each stack to look at the description of the stack or ask the end-user for a stack-id/stack-name. This currently gets the job done but a better experience would be for stack-list to already display some keywords about each stack so the Support Operator would have to do less digging or to allow the Support Operator to query lists of stacks by keyword.

In this case the end-user only has one Wordpress stack so he would have been annoyed if the Support Operator requested more information from him. (Or maybe he has more than one wordpress stack, but only one currently in CREATE_FAILED state).

As a team, we have already encountered this exact situation just doing team testing so I imagine that others would find value in a consistent way to determine at least a general purpose of a stack, from the stack-list page. Putting the stack-description in the stack-list table would take up too much room from a design standpoint.

Specification

 keywords: 
 - wordpress
 - mysql
 - lamp

Implementation

In order for the keywords to be searchable, the ideal implementation would include adding a child table to the stacks table in the heat database, then adding an option to the stacks_list API endpoint to query stacks by keywords and to return all keywords per stack in the stacks_list and stack_show API endpoints.


Help Text

Summary

Currently each parameter in the HOT syntax has a field called "description" that describes the purpose of the parameter. I am proposing an additional field called "help" that can further explain a parameter.

Use Case

Description and help are separate things from a UI perspective. A description might be displayed as a label in a form or in a paragraph somewhere around the input. A help string is typically displayed as hover text when focusing on the input or hovering/clicking on a question mark icon next to the field. We could technically separate these things in the code but because they serve separate purposes I would prefer to have them be defined explicitly.

Example: An example where this use case originated was with Nova Keypairs. The description of a keypair parameter might be something like, "This is the name of a nova key pair that will be used to ssh to the compute instance." A help string for this same parameter would be, "To learn more about nova keypairs visit this help article: http://www.learnsomething.com/keypairs"

Specification

   Parameters:
       <parameter name>:
           description: This is the name of a nova key pair that will be used to ssh to the compute instance.
           help: To learn more about nova key pairs visit this help article: http://www.learnsomething.com/keypairs

Implementation

Adding Help text to the HOT syntax should only require an update to the HOT specification and guide. There are no other known code changes required.