Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
Hi Travis, Thanks very much for passing this information along. It would be great to sync up on the changes and concepts that you’ve worked on regarding the launch instance workflow. I will plan to be at the majority of the Graffiti session to learn more and then I will be headed to a session that we are having around User Experience as a whole and how we move forward as a team @ 2:50 on Tuesday. If you’d like to chat more specifically about the launch instance workflow design, please feel free to attend the Usability Testing session we are doing where we will talk through our proposed design and give your thoughts! If you don’t have a chance to attend this, definitely try to track down either Jacki or I this week to chat informally :) Best, Liz On May 12, 2014, at 12:34 AM, Tripp, Travis S wrote: > Hello Horizon team, > > We’ve been working on some concepts that we’d like to see be incorporated in > the launch instance workflow new UI or existing UI. We have a related design > session at the summit and would love to get feedback! We’ll be showing some > early prototyping work that we’ve been doing. > > http://junodesignsummit.sched.org/event/61439e8187a25985473ea53cc078#.U2-w3ldLpT5 > > https://etherpad.openstack.org/p/juno-summit-graffiti > > Thanks, > Travis > > From: Liz Blanchard [mailto:lsure...@redhat.com] > Sent: Friday, May 09, 2014 3:42 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability > Testing and plan for Summit session > > One last addition, I promise :) > > Another item that we would like to tackle in Juno based on the Usability > Testing results is to make some improvements to the way we give our users > inline help in forms. I’ve put together a doc that includes our current > solution and some suggestions for improvements. If there is time, we will be > discussing this during the session as well: > http://people.redhat.com/~lsurette/OpenStack/ImprovementstoInlineHelpinHorizon.pdf > > See you all next week! > > Liz > On May 7, 2014, at 3:50 PM, Liz Blanchard wrote: > > > Hi All, > > Another topic on the agenda for this session is to talk a bit about creating > some guidelines around Error messaging in Horizon, and hopefully this will > trickle through other components as needed. I’ve put together some initial > thoughts around this topic and want to get it out to the list so folks might > have some time to take a look before discussing at the session. If you have > any feedback, feel free to respond before summit and I can update this doc. > > http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf > > Thanks, > Liz > On Apr 30, 2014, at 2:50 PM, Jacki Bauer wrote: > > > Hi everyone, > As Liz mentioned, we did some testing and one of the big findings was that > the Launch Instance form had some usability issues. I took a stab at mocking > up a launch instance process that addresses some of these issues. You can > read the usability findings here. > > So, I know some of you will ask about work that is already being done around > improving the launch instance form - here and here. That work is represented > here too! I took what I felt to be what was best about the current form and > best about the new work, addressed the usability issues, and tried to come up > with something that wasn’t too different from either of these. > > If you are interested in any of the design thinking/reasoning behind the > mockups, go ahead and keep reading below, otherwise, just take a look at the > attachment. Feedback is welcome! > > Cheers, > Jacki > > Why I did things the way I did: > I used a multi-step form for a few reasons. 1-The Horizon people are > interested in wizard patterns that could be used for launching instances and > other step by step workflows. 2-The current launch instance divides the > config options into tabs, but users often didn’t notice the tabs until they > tried to launch the instance and got an error. The “*” indicating required > fields on each tab confused users as well. Since all but one tab contained > required fields, the tabs didn’t do anything to reduce the number of clicks a > user had to make in order to complete the form. > A best practice for wizards is to never reveal specific steps to the user if > the number or names of those steps can change. So, I settled on four steps. > Some users might not want to visit all these steps, and this is maybe a flaw. > Maybe we can think about a way to allow users to skip steps. > I decided to stack all fields vertically with labels to the left. I did this >
Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
Hello Horizon team, We've been working on some concepts that we'd like to see be incorporated in the launch instance workflow new UI or existing UI. We have a related design session at the summit and would love to get feedback! We'll be showing some early prototyping work that we've been doing. http://junodesignsummit.sched.org/event/61439e8187a25985473ea53cc078#.U2-w3ldLpT5 https://etherpad.openstack.org/p/juno-summit-graffiti Thanks, Travis From: Liz Blanchard [mailto:lsure...@redhat.com] Sent: Friday, May 09, 2014 3:42 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session One last addition, I promise :) Another item that we would like to tackle in Juno based on the Usability Testing results is to make some improvements to the way we give our users inline help in forms. I've put together a doc that includes our current solution and some suggestions for improvements. If there is time, we will be discussing this during the session as well: http://people.redhat.com/~lsurette/OpenStack/ImprovementstoInlineHelpinHorizon.pdf See you all next week! Liz On May 7, 2014, at 3:50 PM, Liz Blanchard mailto:lsure...@redhat.com>> wrote: Hi All, Another topic on the agenda for this session is to talk a bit about creating some guidelines around Error messaging in Horizon, and hopefully this will trickle through other components as needed. I've put together some initial thoughts around this topic and want to get it out to the list so folks might have some time to take a look before discussing at the session. If you have any feedback, feel free to respond before summit and I can update this doc. http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf Thanks, Liz On Apr 30, 2014, at 2:50 PM, Jacki Bauer mailto:jacki.ba...@rackspace.com>> wrote: Hi everyone, As Liz mentioned, we did some testing and one of the big findings was that the Launch Instance form had some usability issues. I took a stab at mocking up a launch instance process that addresses some of these issues. You can read the usability findings here<https://wiki.openstack.org/wiki/Horizon-usability-test-findings>. So, I know some of you will ask about work that is already being done around improving the launch instance form - here<https://www.youtube.com/watch?v=CO62UUQPTCM> and here<https://blueprints.launchpad.net/horizon/+spec/launch-instance-ux-enhancement>. That work is represented here too! I took what I felt to be what was best about the current form and best about the new work, addressed the usability issues, and tried to come up with something that wasn't too different from either of these. If you are interested in any of the design thinking/reasoning behind the mockups, go ahead and keep reading below, otherwise, just take a look at the attachment. Feedback is welcome! Cheers, Jacki Why I did things the way I did: * I used a multi-step form for a few reasons. 1-The Horizon people are interested in wizard patterns that could be used for launching instances and other step by step workflows. 2-The current launch instance divides the config options into tabs, but users often didn't notice the tabs until they tried to launch the instance and got an error. The "*" indicating required fields on each tab confused users as well. Since all but one tab contained required fields, the tabs didn't do anything to reduce the number of clicks a user had to make in order to complete the form. * A best practice for wizards is to never reveal specific steps to the user if the number or names of those steps can change. So, I settled on four steps. Some users might not want to visit all these steps, and this is maybe a flaw. Maybe we can think about a way to allow users to skip steps. * I decided to stack all fields vertically with labels to the left. I did this because I wanted the layout of form fields to be consistent throughout. This layout is very readable and pretty standard. It saves vertical space too. * I changed the network selection to checkboxes. Users thought the drag and drop style control was inconsistent with the rest of Horizon. * Users really liked the graphs that show their quota when they are selecting a flavor. But this didn't really work with the new layout, so I settled on a different way of presenting the same information. It's not as visually appealing as the graphs were, but it's more flexible - could be used throughout Horizon to show quota information on demand and in context. * I added the ability to create key pairs. This was a big finding from the usability study. * I did not add the ability to create a network on the fly. Another big finding from the usability study was that users w
Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
One last addition, I promise :) Another item that we would like to tackle in Juno based on the Usability Testing results is to make some improvements to the way we give our users inline help in forms. I’ve put together a doc that includes our current solution and some suggestions for improvements. If there is time, we will be discussing this during the session as well: http://people.redhat.com/~lsurette/OpenStack/ImprovementstoInlineHelpinHorizon.pdf See you all next week! Liz On May 7, 2014, at 3:50 PM, Liz Blanchard wrote: > Hi All, > > Another topic on the agenda for this session is to talk a bit about creating > some guidelines around Error messaging in Horizon, and hopefully this will > trickle through other components as needed. I’ve put together some initial > thoughts around this topic and want to get it out to the list so folks might > have some time to take a look before discussing at the session. If you have > any feedback, feel free to respond before summit and I can update this doc. > > http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf > > Thanks, > Liz > On Apr 30, 2014, at 2:50 PM, Jacki Bauer wrote: > >> Hi everyone, >> As Liz mentioned, we did some testing and one of the big findings was that >> the Launch Instance form had some usability issues. I took a stab at mocking >> up a launch instance process that addresses some of these issues. You can >> read the usability findings here. >> >> So, I know some of you will ask about work that is already being done around >> improving the launch instance form - here and here. That work is >> represented here too! I took what I felt to be what was best about the >> current form and best about the new work, addressed the usability issues, >> and tried to come up with something that wasn’t too different from either of >> these. >> >> If you are interested in any of the design thinking/reasoning behind the >> mockups, go ahead and keep reading below, otherwise, just take a look at the >> attachment. Feedback is welcome! >> >> Cheers, >> Jacki >> >> Why I did things the way I did: >> I used a multi-step form for a few reasons. 1-The Horizon people are >> interested in wizard patterns that could be used for launching instances and >> other step by step workflows. 2-The current launch instance divides the >> config options into tabs, but users often didn’t notice the tabs until they >> tried to launch the instance and got an error. The “*” indicating required >> fields on each tab confused users as well. Since all but one tab contained >> required fields, the tabs didn’t do anything to reduce the number of clicks >> a user had to make in order to complete the form. >> A best practice for wizards is to never reveal specific steps to the user if >> the number or names of those steps can change. So, I settled on four steps. >> Some users might not want to visit all these steps, and this is maybe a >> flaw. Maybe we can think about a way to allow users to skip steps. >> I decided to stack all fields vertically with labels to the left. I did this >> because I wanted the layout of form fields to be consistent throughout. This >> layout is very readable and pretty standard. It saves vertical space too. >> I changed the network selection to checkboxes. Users thought the drag and >> drop style control was inconsistent with the rest of Horizon. >> Users really liked the graphs that show their quota when they are selecting >> a flavor. But this didn’t really work with the new layout, so I settled on a >> different way of presenting the same information. It’s not as visually >> appealing as the graphs were, but it’s more flexible - could be used >> throughout Horizon to show quota information on demand and in context. >> I added the ability to create key pairs. This was a big finding from the >> usability study. >> I did not add the ability to create a network on the fly. Another big >> finding from the usability study was that users were frustrated by the fact >> that they had to have at least one network created to launch an instance. >> However, we know that creating networks is largely an admin task, not an >> end-user one. So instead, I made it impossible for a user to open up the >> launch instance form when there are no networks. >> There are more items selected for the user by default. >> Defaults have some advantages: they allow users to progress more quickly >> through forms. They also reduce the need for complex logic and error >> messages, because it becomes harder for users to leave something blank. >> The disadvantage to defaults is that the user may not notice a field. Since >> there will be no validation message forcing their attention onto the field, >> they might wonder how their instance came to have the configuration that it >> does. >> Defaults could be problematic for admins who do not want to encourage users >> to select a pre-defined default
Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
Hi All, Another topic on the agenda for this session is to talk a bit about creating some guidelines around Error messaging in Horizon, and hopefully this will trickle through other components as needed. I’ve put together some initial thoughts around this topic and want to get it out to the list so folks might have some time to take a look before discussing at the session. If you have any feedback, feel free to respond before summit and I can update this doc. http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf Thanks, Liz On Apr 30, 2014, at 2:50 PM, Jacki Bauer wrote: > Hi everyone, > As Liz mentioned, we did some testing and one of the big findings was that > the Launch Instance form had some usability issues. I took a stab at mocking > up a launch instance process that addresses some of these issues. You can > read the usability findings here. > > So, I know some of you will ask about work that is already being done around > improving the launch instance form - here and here. That work is represented > here too! I took what I felt to be what was best about the current form and > best about the new work, addressed the usability issues, and tried to come up > with something that wasn’t too different from either of these. > > If you are interested in any of the design thinking/reasoning behind the > mockups, go ahead and keep reading below, otherwise, just take a look at the > attachment. Feedback is welcome! > > Cheers, > Jacki > > Why I did things the way I did: > I used a multi-step form for a few reasons. 1-The Horizon people are > interested in wizard patterns that could be used for launching instances and > other step by step workflows. 2-The current launch instance divides the > config options into tabs, but users often didn’t notice the tabs until they > tried to launch the instance and got an error. The “*” indicating required > fields on each tab confused users as well. Since all but one tab contained > required fields, the tabs didn’t do anything to reduce the number of clicks > a user had to make in order to complete the form. > A best practice for wizards is to never reveal specific steps to the user if > the number or names of those steps can change. So, I settled on four steps. > Some users might not want to visit all these steps, and this is maybe a flaw. > Maybe we can think about a way to allow users to skip steps. > I decided to stack all fields vertically with labels to the left. I did this > because I wanted the layout of form fields to be consistent throughout. This > layout is very readable and pretty standard. It saves vertical space too. > I changed the network selection to checkboxes. Users thought the drag and > drop style control was inconsistent with the rest of Horizon. > Users really liked the graphs that show their quota when they are selecting a > flavor. But this didn’t really work with the new layout, so I settled on a > different way of presenting the same information. It’s not as visually > appealing as the graphs were, but it’s more flexible - could be used > throughout Horizon to show quota information on demand and in context. > I added the ability to create key pairs. This was a big finding from the > usability study. > I did not add the ability to create a network on the fly. Another big finding > from the usability study was that users were frustrated by the fact that they > had to have at least one network created to launch an instance. However, we > know that creating networks is largely an admin task, not an end-user one. So > instead, I made it impossible for a user to open up the launch instance form > when there are no networks. > There are more items selected for the user by default. > Defaults have some advantages: they allow users to progress more quickly > through forms. They also reduce the need for complex logic and error > messages, because it becomes harder for users to leave something blank. > The disadvantage to defaults is that the user may not notice a field. Since > there will be no validation message forcing their attention onto the field, > they might wonder how their instance came to have the configuration that it > does. > Defaults could be problematic for admins who do not want to encourage users > to select a pre-defined default. It might mean that we need to allow admins > to specify these default values for their environment. > The flavor selection has been expanded from a drop down to a list with > details about the resources associated with each flavor, because we have some > indication that users want more details about flavors when they are selecting > them. In the current launch instance form, flavor information is available > but it’s somewhat disconnected from the flavor selector itself. > > > > > On 04/24/2014 09:10 AM, Liz Blanchard wrote: >> Hi All, >> >> One of the sessions that I proposed for the Horizon track is to review th
Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
Hi Liz, Thank you for sharing this, it'd really interesting and suggestive. Also this activity is really important for improving UI/UX matter of Horizon in a right direction. I think Horizon's UI still needs more improvement for production or commercial uses, it is really efficient way to going forward. I really looking forward to hear this session. Thanks, Toshi On Fri, Apr 25, 2014 at 2:04 PM, Jason Rist wrote: > On 04/24/2014 09:10 AM, Liz Blanchard wrote: >> Hi All, >> >> One of the sessions that I proposed for the Horizon track is to review the >> results that we got from the Usability Test that was run on Horizon in early >> March. I wanted to share some of the background of this test and the high >> level results with you all so that we can start the conversation on this >> list and then continue with agreeing on next steps during Summit. There will >> be a few follow-ups to this e-mail from myself and Jacki Bauer which will >> propose some potential solutions to the high priority findings, so be on the >> look out for those :) >> >> ---Quick overview of Usability Testing...What is it? Why do it?--- >> Usability testing is a technique used in user-centered interaction design to >> evaluate a product by testing it on users. This can be seen as an >> irreplaceable usability practice, since it gives direct input on how real >> users use the system. >> >> ---Who was involved? What did we need to do to prepare?--- >> A number of user experience engineers from a bunch of different companies >> got together and helped plan for a usability test that would focus on >> self-service end users and the ease of use of the Horizon Dashboard as it >> exists for the Icehouse release. This effort spun off from the Persona work >> that we've been doing together. Some folks in the group are just getting >> into contributing to the design of OpenStack and doing a baseline usability >> test of Horizon was a great introduction to how the usability of the Horizon >> UI could continue to be improved based on user's direct feedback. >> >> What we needed to get done before actually jumping into the testing: >> 1) Agree on the goals of the testing. >> 2) Create a screener and send out to the OpenStack community. >> 3) Create a list of tasks that the user would complete and give feedback >> on during the testing. >> >> ---Who we tested?--- >> 6 people who we considered to be "self-service end users" based on their >> screener responses. >> >> ---What were the tasks that were tested?--- >> >> Scenario 1: Launching an instance >> Individual Tasks: >> -Create a security key pair. >> -Create a network. >> -Boot from cirros image. >> -Confirm that instance was launched successfully. >> >> Scenario 2: Understand how many vCPUs are currently in use vs. how much >> quota is left. >> Individual Tasks: >> -Check out Overview Page to review current quota use/limit details. >> >> Scenario 3: Take a snapshot of an Instance to save for later use. >> Individual Tasks: >> -Either Launch an instance successfully, or identify a running instance in >> the instance view. >> -Choose to take a snapshot of that instance. >> -Confirm that the snapshot was successful. >> >> Scenario 4: Launch an instance from a snapshot. >> Individual Tasks: >> -Choose to either create an instance and boot from a snapshot, or identify a >> snapshot to create an instance from. >> -Confirm that the instance was started successfully. >> >> Scenario 5: Launch an instance that boots from a specific volume. >> Individual Tasks: >> -Create a volume. >> -Launch an instance using Volume X as a boot source. >> >> ---When and how we ran the tests?--- >> These hour long tests were run over the first two weeks of March 2014. We >> focused on the latest bits that could be seen in the Icehouse release. The >> moderator (a UX researcher from HP) would ask the questions and the rest of >> the group would vigourously take notes :) After all of the testing was >> complete, we spent some time together debriefing and agreeing on the >> prioritized list of updates that would be best to make to the Horizon UI >> based on user feedback. >> >> ---What were the findings?--- >> >> High Priority >> * Improve error messages and error message catalog. >> * Fix Launch Instance workflow for end user and power user. >> * Improve informational help information about form fields. >> * Fix terminology. (e.g. launch instance, boot, shutoff, shutdown, etc.) >> * Show details for key pair and network in Launch Instance workflow. >> * Recommend a new Information Architecture. >> >> Medium Priority >> * Create UI guidelines (of best practices) for Developers to use. >> * Improve Online Help. >> * Provide clearer indication the application is working after clicking a >> button and the application doesn't respond immediately. >> * Ensure consistency of network selection. (Drag and drop of networks very >> inconsistent from the other pieces of the launch instance m
Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
On 04/24/2014 09:10 AM, Liz Blanchard wrote: > Hi All, > > One of the sessions that I proposed for the Horizon track is to review the > results that we got from the Usability Test that was run on Horizon in early > March. I wanted to share some of the background of this test and the high > level results with you all so that we can start the conversation on this list > and then continue with agreeing on next steps during Summit. There will be a > few follow-ups to this e-mail from myself and Jacki Bauer which will propose > some potential solutions to the high priority findings, so be on the look out > for those :) > > ---Quick overview of Usability Testing...What is it? Why do it?--- > Usability testing is a technique used in user-centered interaction design to > evaluate a product by testing it on users. This can be seen as an > irreplaceable usability practice, since it gives direct input on how real > users use the system. > > ---Who was involved? What did we need to do to prepare?--- > A number of user experience engineers from a bunch of different companies got > together and helped plan for a usability test that would focus on > self-service end users and the ease of use of the Horizon Dashboard as it > exists for the Icehouse release. This effort spun off from the Persona work > that we've been doing together. Some folks in the group are just getting into > contributing to the design of OpenStack and doing a baseline usability test > of Horizon was a great introduction to how the usability of the Horizon UI > could continue to be improved based on user's direct feedback. > > What we needed to get done before actually jumping into the testing: > 1) Agree on the goals of the testing. > 2) Create a screener and send out to the OpenStack community. > 3) Create a list of tasks that the user would complete and give feedback > on during the testing. > > ---Who we tested?--- > 6 people who we considered to be "self-service end users" based on their > screener responses. > > ---What were the tasks that were tested?--- > > Scenario 1: Launching an instance > Individual Tasks: > -Create a security key pair. > -Create a network. > -Boot from cirros image. > -Confirm that instance was launched successfully. > > Scenario 2: Understand how many vCPUs are currently in use vs. how much quota > is left. > Individual Tasks: > -Check out Overview Page to review current quota use/limit details. > > Scenario 3: Take a snapshot of an Instance to save for later use. > Individual Tasks: > -Either Launch an instance successfully, or identify a running instance in > the instance view. > -Choose to take a snapshot of that instance. > -Confirm that the snapshot was successful. > > Scenario 4: Launch an instance from a snapshot. > Individual Tasks: > -Choose to either create an instance and boot from a snapshot, or identify a > snapshot to create an instance from. > -Confirm that the instance was started successfully. > > Scenario 5: Launch an instance that boots from a specific volume. > Individual Tasks: > -Create a volume. > -Launch an instance using Volume X as a boot source. > > ---When and how we ran the tests?--- > These hour long tests were run over the first two weeks of March 2014. We > focused on the latest bits that could be seen in the Icehouse release. The > moderator (a UX researcher from HP) would ask the questions and the rest of > the group would vigourously take notes :) After all of the testing was > complete, we spent some time together debriefing and agreeing on the > prioritized list of updates that would be best to make to the Horizon UI > based on user feedback. > > ---What were the findings?--- > > High Priority > * Improve error messages and error message catalog. > * Fix Launch Instance workflow for end user and power user. > * Improve informational help information about form fields. > * Fix terminology. (e.g. launch instance, boot, shutoff, shutdown, etc.) > * Show details for key pair and network in Launch Instance workflow. > * Recommend a new Information Architecture. > > Medium Priority > * Create UI guidelines (of best practices) for Developers to use. > * Improve Online Help. > * Provide clearer indication the application is working after clicking a > button and the application doesn’t respond immediately. > * Ensure consistency of network selection. (Drag and drop of networks very > inconsistent from the other pieces of the launch instance modal) > * Create consistency of visualizations and section of action button > recommendations on Instance table. > * Suggest defaults for the forms entry fields. > * Provide Image information details during image selection. > > Low Priority > * Allow users to edit the network an instance after launching instance. > * Resolve confusion around the split inline actions button. > * Explain what the Instance Boot Source field in Create Instance modal. > * Provide description/high level information
[openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session
Hi All, One of the sessions that I proposed for the Horizon track is to review the results that we got from the Usability Test that was run on Horizon in early March. I wanted to share some of the background of this test and the high level results with you all so that we can start the conversation on this list and then continue with agreeing on next steps during Summit. There will be a few follow-ups to this e-mail from myself and Jacki Bauer which will propose some potential solutions to the high priority findings, so be on the look out for those :) ---Quick overview of Usability Testing...What is it? Why do it?--- Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. ---Who was involved? What did we need to do to prepare?--- A number of user experience engineers from a bunch of different companies got together and helped plan for a usability test that would focus on self-service end users and the ease of use of the Horizon Dashboard as it exists for the Icehouse release. This effort spun off from the Persona work that we've been doing together. Some folks in the group are just getting into contributing to the design of OpenStack and doing a baseline usability test of Horizon was a great introduction to how the usability of the Horizon UI could continue to be improved based on user's direct feedback. What we needed to get done before actually jumping into the testing: 1) Agree on the goals of the testing. 2) Create a screener and send out to the OpenStack community. 3) Create a list of tasks that the user would complete and give feedback on during the testing. ---Who we tested?--- 6 people who we considered to be "self-service end users" based on their screener responses. ---What were the tasks that were tested?--- Scenario 1: Launching an instance Individual Tasks: -Create a security key pair. -Create a network. -Boot from cirros image. -Confirm that instance was launched successfully. Scenario 2: Understand how many vCPUs are currently in use vs. how much quota is left. Individual Tasks: -Check out Overview Page to review current quota use/limit details. Scenario 3: Take a snapshot of an Instance to save for later use. Individual Tasks: -Either Launch an instance successfully, or identify a running instance in the instance view. -Choose to take a snapshot of that instance. -Confirm that the snapshot was successful. Scenario 4: Launch an instance from a snapshot. Individual Tasks: -Choose to either create an instance and boot from a snapshot, or identify a snapshot to create an instance from. -Confirm that the instance was started successfully. Scenario 5: Launch an instance that boots from a specific volume. Individual Tasks: -Create a volume. -Launch an instance using Volume X as a boot source. ---When and how we ran the tests?--- These hour long tests were run over the first two weeks of March 2014. We focused on the latest bits that could be seen in the Icehouse release. The moderator (a UX researcher from HP) would ask the questions and the rest of the group would vigourously take notes :) After all of the testing was complete, we spent some time together debriefing and agreeing on the prioritized list of updates that would be best to make to the Horizon UI based on user feedback. ---What were the findings?--- High Priority * Improve error messages and error message catalog. * Fix Launch Instance workflow for end user and power user. * Improve informational help information about form fields. * Fix terminology. (e.g. launch instance, boot, shutoff, shutdown, etc.) * Show details for key pair and network in Launch Instance workflow. * Recommend a new Information Architecture. Medium Priority * Create UI guidelines (of best practices) for Developers to use. * Improve Online Help. * Provide clearer indication the application is working after clicking a button and the application doesn’t respond immediately. * Ensure consistency of network selection. (Drag and drop of networks very inconsistent from the other pieces of the launch instance modal) * Create consistency of visualizations and section of action button recommendations on Instance table. * Suggest defaults for the forms entry fields. * Provide Image information details during image selection. Low Priority * Allow users to edit the network an instance after launching instance. * Resolve confusion around the split inline actions button. * Explain what the Instance Boot Source field in Create Instance modal. * Provide description/high level information about flavors for flavor selection. * Make sorting clearer visually. * Provide solution for subnet checkbox to improve usability. Nice to Have * Provide “Save as Draft” option in the wizard. * Change security group default name to “Default security grou
