Design and Implementation of a Cloud Tenant UI

Louis Weitzman
VMware, Inc.

Alister Lewis-Bowen
VMware, Inc.

Elizabeth Li
Carnegie Mellon University

Jason Fedor
Brown University


This paper documents the design and implementation of SilverLining, a student intern project to create a simplified user experience to the cloud. vCloud Director® (vCD) provides a full-featured interface for system administrators and others to configure and control their cloud computing resources. The SilverLining project streamlines user workflows and interactions, making it easier to find virtualized applications and add them into a personal workspace. To support this effort, we created a JavaScript SDK to communicate with vCD through its API.

1. Introduction

The current vCloud Director interface allows a user to work with VMs in a very sophisticated way, enabling the management of storage, networks and compute resources. However, this can be very challenging for end users doing straightforward tasks. SilverLining is an implementation of an interface designed for an end user with minimal requirements who just wants to create and start predefined virtualized applications.As a summer project, we had very specific objectives to create a simple interface in the short period of an internship. To accomplish these goals, we needed to make some basic assumptions that could be relaxed going forward.


Typically, a user would search a library of application templates and add them to their workspace. This process of instantiating templates creates working virtual applications (vApps). vCloud Director places these workloads into virtual datacenters (VDCs) where the appropriate resources, for example, CPU, storage and networks, are available to run the vApp. Unfortunately, this process can be complex for the casual user. SilverLining provides the basic functionality to find, instantiate and manage these cloud workloads in a simple and effective manner appropriate for a consumer.

The main objectives of SilverLining are two-fold; 1) demonstrate how easy it could be for a consumer to use the cloud, and 2) provide a JavaScript SDK that helps web developers build customized browser applications that communicate with VMware’s cloud implementation using familiar technologies.

The interface should not only be easy to use, but also should demonstrate a responsive design that automatically adapts to different display devices and output formats. This makes it possible to show the same information at different resolutions and in different layouts as dictated by the device on which it is rendered.

The JavaScript SDK enables developers to exercise standard web technologies at a lower cost of entry. This allows them to easily create their own branded interface to the cloud. Hopefully, through this process, we can demonstrate concepts and guidance for the future development of VMware consumer UIs.


We made a few assumptions to simplify the end-user interaction. To scope the amount of work for this summer project and provide simplified workflows, we assumed reasonable defaults for user interactions. These defaults, including which virtual datacenter and networks to use in the organization, are saved as user preferences in local storage on the client-side. This allowed us to create the option of a 1-click instantiation instead of forcing the user through a more complicated wizard workflow. Also, we added a setting to automatically power on templates when they are added to the workspace. A long-term solution might be to save these user preferences in server storage so that these become available to the user across workstations.

We started the project by assuming one VM per vApp but later relaxed this restriction to allow multiple VMs, adding a bit more flexibility. We wanted to create interactions that make the abstractions of the vApp layer simpler to the end-user. To further simplify the user interface, we hid the internal states of vApps and VMs that could confuse the user.

vCloud Director’s User Interface

The current vCloud Director’s interface presents three primary areas to end users: Home, My Cloud and Catalogs. Home shows a ‘card view’ of the vApps available to the user and appropriate vApp actions. My Cloud, also referred to as the workspace, does the same using a ‘list view’ adding navigation to all VMs within these vApps and logs of tasks performed by the user. The Catalog area provides a way to navigate through libraries of available templates that can be instantiated into the user’s workspace. Figure 1 shows the current My Cloud page listing all of the user’s vApps.


Figure 1. Current vCloud Director showing the My Cloud view, a workspace where users manage vApps and VMs.

2. User Workflows

For our summer project, we focused on a reduced set of workflows that provide the end user with the basic functionality to find, instantiate and manage vApps in their Cloud workspace. These include:

  • Authenticate with vCD to gain access to an account within a predefined organization on a VMware Cloud installation.
  • Browse a library, choose a template, instantiate it, and power it on. Do this by one-click with a limited number of customized user settings.
  • Navigate through the user interface revealing different representations of vApps and Library templates.
  • Perform power operations on vApps and VMs.
  • Sort/Filter/Search vApps and templates by attributes in a faceted search.
  • Show VM console thumbnails and provide console access.
  • Use extremely simplified workflows for network configuration and VDC selection.
  • Utilize tagging with metadata.
  • Handle long running tasks and display notifications to the user.

3. User Experience Design

A few design principles guided us through this project. As we iterated over design solutions, we focused on the end-user workflows. Starting with sketches and wireframe mockups, we produced working examples of our design and refined these implementations, iterating to continually improve our solution.

Design Principles

Some basic design principles informed our decision making throughout the project, including the following:

  • Keep it simple – Keep it as simple as possible but no simpler.
  • Use direct manipulation – Objects are represented in the interface and the user should take actions directly on those objects.
  • Use simple hierarchies – Reduce complexity, but allow future implementations the capability to drill into more detail as needed. For example, use search/filtering to find appropriate templates rather than digging deep into libraries. Also allow implementations on different devices to take advantage of similar navigation.
  • Simplify the workflows – Limit the use of confirmation dialogs, use undo where appropriate, don’t allow the user to get into dead-end or error conditions, and use strong defaults to avoid unnecessary user input.
  • Provide a ‘sense of place’ – For both the cloud workspace and library, create a unique look to distinguish the space and the tasks to be done there.

Design Iterations

Initially, our designs were highly influenced by the existing interface. We began with sketches and refined them in low-resolution wireframes.

In our first implementation, we recycled the notion of representing vApps using cards, but added a “card flip” interaction as a means of showing more details. We also planned other interactions such as sorting and drag-and-drop. Each vApp was represented as a distinct object that could be directly manipulated. Any information not needed right away could be accessed in a single click (Figures 2 and 3).


Figure 2. Initial sketches exploring card and list views of vApps and templates similar to what exists in the current UI.


Figure 3. Wireframe mockup of the My Cloud as cards.

We designed templates to be displayed in a simple table that can be filtered using a powerful, faceted search syntax (Figure 4). For example, to find vApps with a name containing the string “windows”, the user could type “name:windows” and immediately filter the view. An early implementation of this design allowed the user to specify searchable values for several object attributes. We expanded this capability in the final implementation to include non-string attributes, such as memory size, as well. This search is very quick and effective, and after using it to narrow down options, templates could quickly be scanned down the list for comparison.


Figure 4. Wireframe mockup of the Library displayed as a list with faceted search.

4. User Feedback

To get feedback on the initial designs, we conducted a small focus group and demonstrated SilverLining to the vCD team in Cambridge. From these sessions we gained two key insights. First, there needed to be better representation and navigation of the object hierarchy. The vApp cards did not suggest an intuitive way to drill into details about vApps and VMs and their associated resources.

Second, choosing library templates needed to be more of a shopping experience; template descriptions, ratings, number of instantiations and cost information should be shown in a way that helps users make informed decisions about what to choose.

Also, it became obvious that our original designs did not provide for different layouts while maintaining a common interaction pattern. So we went back to the drawing board to focus on how the UI would behave in various situations (Figures 5 and 6).


Figure 5. Back to the drawing board (literally) with a focus on the dynamic interaction between outline and detail views.


Figure 6. More sketches with expanding cards and multi-view layouts using a left navigation pane.

5. Design Implementation

After exploring many alternatives, we converged on an implementation utilizing sliding panels. This design maintains context, enables drag and drop between the library and the cloud, and supports layouts in other devices while maintaining the application’s interaction pattern. The panels are divided into two columns, with a list of vApps on the left and details on the right. The panels slide left and right to navigate linearly through the hierarchy and can be extended to drill deeper through any number of levels (Figures 7 and 8).


Figure 7. SilverLining’s home page showing vApps, general status and recent tasks.


Figure 8. Navigating into the details of a vApp displays all its VMs and other associated metadata.

The template library was designed as a separate, distinctly branded layout for browsing with a shopping catalog feel, showing featured templates and information about popularity (Figure 9). The library slides open next to the user’s list of vApps so that the user knows what context they are in and how to go back. These sliding panels provide an affordance that worked well with the ‘swipe’ gesture on touch devices. Figure 10 shows an interaction in the library filtering the content with a faceted search. Figure 11 illustrates an instantiation workflow allowing the user to customize a few parameters. In comparison, the instantiation workflow in the current vCloud Director presents a multi-step wizard requiring the user to choose many options, some of which they may not understand or even care about.


Figure 9. With vApps still visible, the Library displays all templates in a distinctive layout, promoting featured ones.


Figure 10. Exploring the Library with faceted search filtering templates to view those owned by “system”.


Figure 11. One-click instantiation immediately adds the template to your workspace while the customize option, shown here, provides the ability to override the default values.

Testing our implementation using the panel layouts on the different standard device sizes validated this last design iteration. As the screen real estate was reduced, the layout degraded gracefully but still maintained the same interaction pattern. The layout for a mobile phone can be seen in Figure 12. In the end we had a fully functional application written in HTML5, CSS3 and JavaScript.


Figure 12. Alternative layout of the same content for smartphones illustrates responsive design organizing information in tabs when limited space is available.

6. Implementation and Technology

Our versatile JavaScript SDK powers the SilverLining project. This library communicates with VMware vCloud Director (vCD) v5.1 through its API. It assumes that a vCD Organization and a user account already exist. This latest version of vCloud Director includes enhanced metadata support and access to server side support for an HTML5 console to VMs. We limited the scope of the SDK development to provide just the functionality that our defined end user would require. This scoping effort helped encapsulate the requirements to produce a demonstrable deliverable for our summer project.

The SDK functions can fetch information on a certain object from vCD, or parse information already stored in the local cache. After authentication, the SDK fetches basic information about the user’s workloads—the list of vApps and their corresponding VMs, basic network and VDC info, catalogs of vApp templates, and user information. Then, based on these starting objects, the web developer can pull specific details based on what they want to display. For example, to learn about metadata for a certain vApp, you call a function, ‘cloud.metadata.get(vAppObject)’, and the SDK will perform the sequence of calls necessary to learn about the metadata for that vApp. Prefetching provides some speed benefit and allows the rendering logic to operate independently from the SDK.

Using the credentials after logging in, the JavaScript SDK has full access to vCloud Director’s REST API. It performs a number of AJAX calls in order to navigate the object hierarchy. If the SDK ran on the user’s local host or some other website, it could trigger browser security measures designed to prevent cross-site scripting (XSS) when talking to a remote server [9]. Initially, we remedied the situation by running each request through a local proxy server, which then relayed the calls through HTTPS to the vCD instance and back. However, this additional proxy code added to the size
of the SDK and limits the ability for this library to be dropped into existing web applications. We decided to install this SDK directly into the vCD cell thus increasing the likelihood that the API’s IP address and the resulting web application’s IP address are the same, thus thereby eliminating any cross-site scripting limitations.


We used the powerful metadata feature in vCD 5.1 to extend the functionality in useful ways. Metadata provides typed, key-value pairs for various vCD objects including vApps, VMs and templates. Once defined, objects can be filtered and sorted to identify important aspects of these objects.

This metadata feature created many new possibilities for our design, several of which we implemented. For example, for the notion of a shopping experience, we labeled some templates as featured to allow the rendering logic to display those templates more prominently in the Library section. In an actual use-case, we could imagine the vCD Organization Admin role promoting some particular templates for a specific project. We also provide live data about the number of downloads with a counter that is incremented on every instantiation. Favorites is another metric stored as metadata for an individual user. Once tagged, the user can then filter for these metadata enhanced vApps or templates. Socializing the popularity of shared objects, in this case templates, provides users with ways to gauge which templates might be best to add to their workspace.

Local Storage

Network latency can occasionally cause the vCD cell to take a very long time to respond to requests. To make our system more responsive, we decided to use a caching system so we could display data immediately at startup. Since the rendering logic is decoupled from the SDKs logic to fetch the data, the UI can display cached information while the live data loads. Then, once the SDK has live data, it can present this to the UI seamlessly. As a result, the user has immediate access to their data as soon as they log in, even though it might be a little old. They can navigate around the hierarchy, even queue up instantiation requests or power something on before any information has even transferred to the client. In effect, this is an implicit Offline Mode, creating the illusion of connectivity before it has been established. To store the cache, we are compressing the cloud’s data, and storing it as a JSON object in local storage, an HTML5 feature. This approach is appropriate for the type of user we have in mind for this design. But we are aware that storing data this way could become un-scalable when managing one or several vCD organizations or an entire cloud.


To support long running operations, the SDK takes advantage of the Task system within the vCloud API. Whenever an action is submitted, a task object is returned. This object can be polled to get the current status until completion. This ensures that the SDK only pulls information as needed. If any task results in an error while the user is logged in, a notification is issued and noted in the task log. Also, the data model maintains the status of all objects, including any errors, thereby allowing the interface to render object status as it sees fit.

Separation of Form and Content

As mentioned earlier, we decoupled fetching data and the presentation of that data when rendering the UI. To do this we used a Model-View-View Model (MVVM) architecture through a popular JavaScript library plugin called Knockout.js [7]. With this separation, we can use the same responsive CSS3 design to provide a polished presentation and adaptive layout depending on the device used.

7. Intern Coordination

Having two summer interns created some challenges as well as opportunities for SilverLining. We needed to plan the project and provide some groundwork before they arrived, and, once onboard, bring them up to speed on the problem and current system. Also, we needed to clearly separate responsibilities and deliverables. Luckily, a separation around JavaScript SDK development, UI design, and implementation was straightforward. The design helped create the requirements for the SDK, and the UI implementation provided a testing harness for SDK development.

Recognizing that communication is a critical part of any successful project, we made it a priority. Throughout the summer we met regularly to discover any roadblocks and to map current progress. Also, we made an effort to communicate our results to other interested parties, including the key product drivers within the organization. The timely feedback received helped move the design and implementation forward. Specifically, we created and maintained a wiki with sections for requirements, schedules, processes, and results for all to view, including video screen-casts showing our progress. Weekly meetings reviewed past work and planned future work. Additional meetings were held to resolve on-going issues and critique the latest design iterations.

8. Conclusion

With two interns providing critical mass, we were able to make significant progress over a very short time. As a result, SilverLining was a great success and met all of our expectations. We were able to demonstrate a UI to vCloud Director that was both simple and effective for the end user we defined. The JavaScript SDK we created now provides a building block for future efforts using standard web technologies. Our responsive design provides a glimpse at how future efforts can adapt to the ever-increasing number of display devices.

We plan to solicit more user feedback beyond our immediate group to help guide our implementation. Once completed, we plan to distribute SilverLining as a Fling [3] to allow developers both inside and outside VMware to exercise the JavaScript SDK and provide us with feedback. The goal is to allow third parties to easily create custom interfaces uniquely branded for their own organizations, and scoped to the needs of specific classes of users wanting to use vCloud Director.


We would like to acknowledge and thank those who helped us along the way, including our managers: Brad Meiseles, Vinod Johnson; our colleagues: Stephen Evanchik, Jeff Moroski, Zach Shepherd, Simon Threasher; user research: Amy Grude, Peter Shepherd; our other interns: Paul Furtado, Dan Trujillo and Shivam Tiwari; our product managers: Catherine Fan, Maire Howard, and Dmitri Zimine and our reviewers: Eric Hulteen and Steve Strassmann.

VMware, vCloud Director, and VMware vCloud are registered trademarks or trademarks of VMware, Inc in the United States and other jurisdictions. Red Hat is a registered trademark of Red Hat, Inc. All other names and marks mentioned herein may be registered trademarks or trademarks of their respective organizations.


  1. CSS,
  2. Krug, S. “Don’t make me think, A Common Sense Approach to Web Usability,” Macmillan, 2000.
  3. Fling,
  4. HTML5,
  5. “HTML5 Leads a Web Revolution,” Anthes, G., Communication of the ACM, Vol 55, No. 7, July 2012.
  6. jQuery,
  7. Knockout,
  8. VMware vCloud® API.,
  9. XSS,