Before I jump into blog posts about OpenStack user experience requirements, designs, and user testing, I wanted to start with some level setting and explain some of the groups that have been a focus in the user experience space.
To start, let me give a quick introduction to the way user experience design currently works within OpenStack. How do we as user experience professionals work within the OpenStack community? Today, we work very closely with the Horizon and TripleO/Tuskar teams. We attend the weekly IRC meetings, participate in feature requirement discussions, register blueprints, report bugs, design wireframes for new features, and test existing features with users.
User experience isn’t an official program in OpenStack, but a few of us have started to form a team around the efforts in the UX space. We now have an Ask OpenStack UX site where we house design discussions. Weekly, we send out an update to the mailing list on the current topics that are being discussed. As a group we are continuously improving our processes. We are discussing the option of moving to and using the StoryBoard tool that Thierry Carrez proposed at the Hong Kong summit.
How could you contribute to the user experience effort in OpenStack? Join us in discussions on Ask OpenStack UX, share your wireframes, give your feedback as an OpenStack user, or simply give your thoughts on how we could improve our way of working. You can find us in #openstack-ux on Freenode if you’d like to chat.
As I mentioned in my first blog post, Horizon is where I jumped into the OpenStack world. This is the only user interface that is currently shipped with the core OpenStack product and it seems obvious to me that others will have the same experience. The Horizon Dashboard gives the user a visual way to perform basic OpenStack tasks like spinning up an Instance and assigning that instance a floating IP. Of course, the user can do these things from the command line interface (CLI), but the UI is where most of the user experience work that has been done so far has been focused.
The Horizon development team is a great bunch to work with and are extremely supportive of making sure this component has great user experience design. Currently, Horizon only supports the other core components, but develoeprs are welcomed to add plugins to Horizon for components they are working on outside of the core.
There are a few options that I know about for quickly getting access to a running version of Horizon if you’d like to poke around and test things out.
1. trystack.org – You can get a free account by joining their Facebook group. Once you’ve been added to the group, simply use your Facebook credentials for authentication and you’ll be able to view the Horizon UI.
2. stacklab.org – This is another quick way to get access to Horizon to poke around.
3. If you are feeling brave and would like to get your own environment up and running — Spin up a RHEL-based Linux distro in a VM and run through the RDO Quick Start guide.
4. Another way to get a development environment up and running would be to use DevStack.
If you are interested in jumping into the development or review side of Horizon, feel free to come to one of our weekly meetings on IRC to get a feel for what we are working on today. Also, getting started with Horizon can be done by following the quick start instructions.
In my introductory post, I mentioned that I quickly realized that installation and deployment are big areas in which the usability of OpenStack could be improved. TripleO and Tuskar work together to tackle just this.
TripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack’s own cloud facilities as the foundations – building on nova, neutron and heat to automate fleet management at data center scale. (https://wiki.openstack.org/wiki/TripleO)
It’s a bit of a mind bending concept, but I highly recommend watching Robert Collins’ talk from the Portland OpenStack Summit. Although TripleO continues to evolve with each release, I found this talk to be a great introduction.
We haven’t worked on any user experience designs specifically for TripleO, but this is where Tuskar comes into play.
Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the data center. Using Tuskar, administrators divide hardware into “resource classes” that allow predictable elastic scaling as cloud demands grow. This resource orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the data center. (https://wiki.openstack.org/wiki/TripleO/Tuskar)
Tuskar has recently combined efforts with the TripleO program and is bringing a user interface into the mix. Although there are huge discussions currently taking place about the requirements for the Icehouse release of Tuskar working with TripleO, a demo of the initial concepts shown at the Hong Kong Summit can be seen here.
Ultimately, TripleO and Tuskar will work together to provide a community solution for installing and deploying an OpenStack environment solving a huge need for the end users of OpenStack!
I should start off with an introduction. I’m Liz and I’ve been working for Red Hat for just over a year. I work on the User Experience Design team with a focus on the OpenStack project. I’ve added more information to my About page, so feel free to jump over there to read more about me.
Since I started working at Red Hat I’ve been working on the OpenStack project. That means I’ve been involved with the project for almost a year now. So why has it taken me a year to decide to start this blog? Well, there has definitely been a learning curve. With everything that I’ve done in the OpenStack space, I’ve tried to take the view point of the OpenStack customer or end user. I started off very small in the OpenStack world by installing the latest release (which was Folsom at the time). I realized that there wasn’t one solid way to go about installing OpenStack, so I spent a lot of my days hacking around and getting something up and running. Ultimately, I ended up getting a development environment running on Fedora 19 using DevStack. As many other people in the OpenStack community have already done, I came to the conclusion that installation and deployment should be high on the priority list when it comes to improving the usability of OpenStack.
Once I got access to a running version of OpenStack, I spent time reviewing the Horizon Dashboard. Although the usability field doesn’t have to be limited to user interfaces, it was a great place for me to start. I needed to get familiar with what features were offered in OpenStack and what better way to do this than to try the features out myself. Come to find out later that there are actually features in OpenStack that aren’t surfaced in the UI. I had no idea they even existed at this point. I went about reviewing the dashboard and I logged a fair amount of bugs in Launchpad. Most of the bugs were small, but a few were for some larger usability issues that would be great to solve. I was so excited to see a few of these bugs get picked up and fixed right away.
I was lucky enough to be able to attend my first OpenStack Summit as we planned for the Grizzly release in Portland, OR. Getting to meet the majority of the Horizon community in person was awesome. I realized during this Summit just how passionate and supportive this group of people are working together on OpenStack. I was so happy to be a part of this. As I’ve continued my work on OpenStack and have become more familiar with the processes, I’ve stepped up the amount of work that I’ve been able to contribute to the project. I’ve done work on creating use cases, developing personas, sketching, wireframing, and user testing. I’ve shared my work via e-mails, conversations over IRC, or documents and spreadsheets that have been created.
As I look back over the last year’s worth of work, I realize that I’ve influenced a lot of small features, but it takes some time to compile the list of items I’ve completed. As I move forward with my OpenStack work, I’d like to make sure that I take some time with each of the tasks I work on to do a small write up of what I’m working on and why it’s important to the OpenStack community. I hope this blog will generate further discussion and help improve the usability of OpenStack even more than if I simply share my work via e-mail and IRC.
Another goal of this blog is for it to serve as a history of some of the usability topics that have been discussed in the OpenStack community. It would be great if my posts sparked some conversations about moving certain features forward. I definitely won’t confine my posts to just UI topics, so as I start to explore some of the ways that user experience professionals can influence things like APIs and the command line, I hope others find my discoveries helpful.