Canonical Voices

Posts tagged with 'notes'

Joseph Williams

Working to make Juju more accessible

In the middle of July the Juju team got together to work towards making Juju more accessible. For now the aim was to reach Level AA compliant, with the intention of reaching AAA in the future.

We started by reading through the W3C accessibility guidelines and distilling each principle into sentences that made sense to us as a team and documenting this into a spreadsheet.

We then created separate columns as to how this would affect the main areas across Juju as a product. Namely static pages on jujucharms.com, the GUI and the inspector element within the GUI.

 

 

image02

GUI live on jujucharms.com

 

 

image04

Inspector within the GUI

 

 

image03

Example of static page content from the homepage

 

 

image00

The Juju team working through the accessibility guidelines

 

 

Tackling this as a team meant that we were all on the same page as to which areas of the Juju GUI were affected by not being AA compliant and how we could work to improve it.

We also discussed the amount of design effort needed for each of the areas that isn’t AA compliant and how long we thought it would take to make improvements.

You can have a look at the spreadsheet we created to help us track the changes that we need to make to Juju to make more accessible:

 

 

image01

Spreadsheet created to track changes and improvements needed to be done

 

 

This workflow has helped us manage and scope the tasks ahead and clear up uncertainties that we had about which tasks done or which requirements need to be met to achieve the level of accessibility we are aiming for.

 

 

Read more
Inayaili de León Persson

September’s reading list

Here are the best links shared by the design team during the month of September:

  1. Empty States
  2. It’s ok to say what’s ok
  3. Sully – 208 Seconds Experience
  4. Google Allo
  5. Tech Giants Team Up to Fix Typography’s Biggest Problem
  6. Redesigning Chrome desktop
  7. Clarity Conference videos

Thank you to Alejandra, Jamie, Joe and me for the links this month!

Read more
Inayaili de León Persson

August’s reading list

August has been a quiet month, as many of team have taken some time off to enjoy the unusually lovely London summer weather, but we have a few great links to share with you that were shared by the design team this month:

  1. Developing a Crisis Communication Strategy
  2. Accessibility Guidelines
  3. An Evening with Cult Sensation – Randall Munroe
  4. Clearleft Public Speaking Workshop in Brighton
  5. Hello Color
  6. The best and worst Olympic logo designs throughout the ages, according to the man who created I <3 NY
  7. Readability Test Tool
  8. Breadcrumbs For Web Sites: What, When and How

Thank you to Joe, Peter, Steph and me for the links this month!

Read more
Rae Shambrook

Recently I have been working on the visual design for RCS (which stands for rich communications service) group chat. While working on the “Group Info” screen, we found ourselves wondering what the best way to display an online/offline status. Some of us thought text would be more explicit but others thought  it adds more noise to the screen. We decided that we needed some real data in order to make the best decision.

Usually our user testing is done by a designated Researcher but usually their plates are full and projects bigger, so I decided to make my first foray into user testing. I got some tips from designers who had more experience with user testing on our cloud team; Maria  Vrachni, Carla Berkers and Luca Paulina.

I then set about finding my user testing group. I chose 5 people to start with because you can uncover up to 80% of usability issues from speaking to 5 people. I tried to recruit a range of people to test with and they were:

  1. Billy: software engineer, very tech savvy and tech enthusiast.
  2. Magda: Our former PM and very familiar with our product and designs.
  3. Stefanie: Our Office Manager who knows our products but not so familiar with our designs.
  4. Rodney: Our IS Associate who is tech savvy but not familiar with our design work
  5. Ben: A copyeditor who has no background in tech or design and a light phone user.

The tool I decided to use was Invision. It has a lot of good features and I already had some experience creating lightweight prototypes with it. I made four minimal prototypes where the group info screen had a mixture of dots vs text to represent online status and variations on placement.  I then put these on my phone so my test subjects could interact with it and feel like they were looking at a full fledged app and have the same expectations.

group_chat_testing

During testing, I made sure not to ask my subjects any leading questions. I only asked them very broad questions like “Do you see everything you expect to on this page?” “Is anything unclear?” etc. When testing, it’s important not to lead the test subjects so they can be as objective as possible. Keeping this in mind, it was interesting to to see what the testers noticed and brought up on their own and what patterns arise.

My findings were as follows:

Online status: Text or Green Dot

Unanimously they all preferred online status to be depicted with colour and 4 out of 5 preferred the green dot rather than text because of its scannability.

Online status placement:

This one was close but having the green dot next to the avatar had the edge, again because of its scannability. One tester preferred the dot next to the arrow and another didn’t have a preference on placement.

Pending status:

What was also interesting is that three out of the four thought “pending” had the wrong placement. They felt it should have the same placement as online and offline status.

Overall, it was very interesting to collect real data to support our work and looking forward to the next time which will hopefully be bigger in scope.

group_chat_final

The finished design

Read more
Jouni Helminen

We have been looking at ways of making the Terminal app more pleasing, in terms of the user experience, as well as the visuals.

I would like to share the work so far, invite users of the app to comment on the new designs, and share ideas on what other new features would be desirable.

On the visual side, we have brought the app in line with our Suru visual language. We have also adopted the very nice Solarized palette as the default palette – though this will of course be completely customisable by the user.

On the functionality side we are proposing a number of improvements:

-Keyboard shortcuts
-Ability to completely customise touch/keyboard shortcuts
-Ability to split the screen horizontally/vertically (similar to Terminator)
-Ability to easily customise the palette colours, and window transparency (on desktop)
-Unlimited history/scrollback
-Adding a “find” action for searching the history

email-desktop

Tabs and split screen

On larger screens tabs will be visually persistent. In addition it’s desirable to be able split a panel horizontally and vertically, and use keyboard shortcuts or focusing with a mouse/touch to move between the focused panel.

On mobile, the tabs will be accessed through the bottom edge, as on the browser app.

terminal-blog-phone

Quick mobile access to shortcuts and commands

We are discussing the option of having modifier (Ctrl, Alt etc) keys working together with the on-screen keyboard on touch – which would be a very welcome addition. While this is possible to do in theory with our on-screen keyboard, it’s something that won’t land in the immediate near future. In the interim modifier key combinations will still be accessible on touch via the shortcuts at the bottom of the screen. We also want to make these shortcuts ordered by recency, and have the ability to add your own custom key shortcuts and commands.

We are also discussing with the on-screen keyboard devs about adding an app specific auto-correct dictionary – in this case terminal commands – that together with a swipe keyboard should make a much nicer mobile terminal user experience.

email-desktop

More themability

We would like the user to be able to define their own custom themes more easily, either via in-app settings with colour picker and theme import, or by editing a JSON configuration file. We would also like to be able to choose the window transparency (in windowed mode), as some users want a see-through terminal.

We need your help!

These visuals are work in progress – we would love to hear what kind of features you would like to see in your favourite terminal app!

Also, as Terminal app is a fully community developed project, we are looking for one or two experienced Qt/QML developers with time to contribute to lead the implementation of these designs. Please reach out to alan.pope@canonical.com or jouni.helminen@canonical.com to discuss details!

EDIT: To clarify – these proposed visuals are improvements for the community developed terminal app currently available for the phone and tablet. We hope to improve it, but it is still not as mature as older terminal apps. You should still be able to run your current favourite terminal (like gnome-terminal, Terminator etc) in Unity8.

Read more
karlwaghorn-moyce

Vancouver sprint recap: MAAS and Juju

This was my first cycle sprint within the Cloud design team and my first time to Vancouver, Canada #winner

Having only been with Canonical for 8 weeks and working closely my fellow design colleagues, it was a great opportunity for me meet and collaborate with product engineers working around the world.

Not only was it great to meet engineers but also to sit in meetings with them and learn more about our products, giving me further insight and understanding into MAAS. Discussing new features, sketching, presenting and planning during the week really helped us to evolve our thinking about what we plan to deliver in the next few months. I also had the chance to showcase recent designs and get feedback from a variety of people across different areas of the business.

An exciting new project I worked on whilst at the sprint was Snapcraft.io, a tool that enables you to deliver and package your app to any Linux desktop or cloud server. I was given the task of creating a micro website promoting this tool and showcasing how easy it is to use to setup your app.

But it wasn’t just all #workworkwork… as the evenings gave us opportunity to socialise and get to know different people and explore the city of Vancouver.

It’s an exciting time to be at Canonical with big product releases on the horizon. I’m looking forward to our releases of MAAS 2.0 and Juju 2.0!

Below are some photos of our week in Vancouver. Enjoy :)

Vancouver sprint

Vancouver sprint

Vancouver sprint

Read more
Joseph Williams

Juju Lithuania sprint recap

Last month the Juju design team was away in Lithuania, Vilnius on a working sprint. We met up with the distributed development team to help tackle technical and design issues.

These sprints take away the barrier of time zones — which usually make it harder to ask engineers questions about features that are being designed.

13616221_10209952745325460_1919613808_o

Everyday started with a run down of the workshops and discussions that would happen on that day. This made sure everyone was aware and welcome (and very much encouraged) to join the sessions and give their valuable insight or just widen their knowledge of the product.

13589133_10209952745245458_1275611017_o

The day would then play out in an enjoyable whirlwind of knowledge, clarity and alarming amounts of progress as queries would be answered in real time without the assistance of an email client or a hangout session.

At lunch time the Juju team took the fantastic opportunity to explore the city. Walking the cobbled streets and enjoying the vast range of foods from a variety of different cultures. While we were there we ate everything from classic Lithuanian cuisine to a big shared spread of Mexican food.

13616195_10209952745285459_595293251_o

At the end of the day we would go through all of the things which were accomplished and have lightning talks (short presentations of work to the rest of the team) about the work that had been completed. This is a fantastic exercise for design as it lets us show wireframes, prototypes, research or just flat visuals for the features that are being implemented within Juju and gives the engineers a chance to see and discuss the work directly with the designers. Lightning talks are also great for engineering as they can show features that are under development or just talk through the back end of the solution.

This has been my fourth sprint with Canonical and they never cease to be valuable as they promote collaboration, forward thinking and team bonding. I look forward to the team’s next adventure and the challenges that we will conquer.

Read more
Carla Berkers

OpenStack is the leading open cloud platform, and Ubuntu is the world’s most popular operating system for OpenStack. Over the past two years we have created a tool that allows users to build an Ubuntu OpenStack cloud on their own hardware in a few simple steps: Autopilot.

This post covers the design process we followed on our journey from alpha to beta to release.

Alpha release: getting the basics right

We started by mapping out a basic Autopilot journey based on stakeholder requirements and designed a first cut of all the necessary steps to build a cloud:

  1. Choose the cloud configuration from a range of OpenStack optionsChoose cloud configuration
  1. Select the hardware the cloud should be built on
    Select the hardware
  1. View deployment status while the cloud is being built
    View deployment status
  1. Monitor the status and usage of the cloud
    Monitor Cloud

After the initial design phase Autopilot was developed and released as an alpha and a beta. This means that for over a year, there was a product to play around with, test and improve before it was made generally available.

Beta release: feedback and improvements

Providing a better overview: increased clarity in the dashboard

Almost immediately after the engineering team started building our new designs, we discovered that we needed to display an additional set of data on the storage graphs. On top of that, some guerilla testing sessions with Canonical engineers brought to light that the CPU and the storage graphs were easily misinterpreted.

dashboard-sketches

After some more competitive research and exploratory sketching, we decided to merge the graphs for each section by putting the utilisation on a vertical axis and the time on the horizontal axis. This seemed to improve the experience for our engineers, but we also wanted to validate with users in usability testing, so we tested the designs with eight participants that were potential Autopilot users. From this testing we learned to include more information on the axes and to include detailed information on hover.

The current graphs are quite an evolution compared to what we started with:
Improved dashboard graphs

Setting users up for success: information and help before the process begins

Before a user gets to the Autopilot wizard, they have to configure their hardware, install an application called MAAS to register machines and install Landscape to get access to Autopilot. A third tool called Juju is installed to help Autopilot behind the scenes.

All these bits of software work together to allow users to build their clouds; however, they are all developed as stand-alone products by different teams. This means that during the initial design phase, it was a challenge to map out the entire journey and get a good idea of how the different components work together.

Only when the Autopilot beta was released, was it finally possible for us to find some hardware and go through the entire journey ourselves, step by step. This really helped us to identify common roadblocks and points in the journey where more documentation or in-app explanation was required.

Increasing transparency of the process: helping users anticipate what they need and when configuration is complete

Following our walk-through, we identified a number of points in the Autopilot journey where contextual help was required. In collaboration with the engineering team we gathered definitions of technical concepts, technical requirement, and system restrictions.

Autopilot walk-through

Based on this info, we made adjustments to the UI. We designed a landing page  with a checklist and introduction copy, and we added headings, help text, and tooltips to the installation and dashboard page. We also included a summary panel on the configuration page, to guide users through the journey and provide instant feedback.

BR_step-by-step

GA release: getting Autopilot ready for the general public

Perhaps the most rewarding type of feedback we gathered from the beta release — our early customers liked Autopilot but wanted more features. From the first designs Autopilot has aimed to help users quickly set up a test cloud. But to use Autopilot to build a production cloud, additional features were required.

Testing without the hardware: try Autopilot on VMware

One of the biggest improvements for GA release was making it easy to try Autopilot, even for people that don’t have enough spare hardware to build a cloud. Our solution: try Autopilot using VMware!

Supporting customisation:  user-defined roles for selected hardware

In the alpha version a user could already select nodes, but in most enterprises users want more flexibility. Often there are different types of hardware for different roles in the cloud, so users don’t always want to automatically distribute all the OpenStack services over all the machines. We designed the ability to choose specific roles like storage or compute for machines, to allow users to make the most of their hardware.

Machine roles

Allowing users more control: a scalable cloud on monitored hardware

The first feature we added was the ability to add hardware to the cloud. This makes it possible to grow a small test cloud into a production sized solution. We also added the ability to integrate the cloud with Nagios, a common monitoring tool. This means if something happens on any of the cloud hardware, users would receive a notification through their existing monitoring system.

BR-Nagios

The benefits of early release

This month we are celebrating another  release of OpenStack Autopilot. In the two years since we started designing Autopilot, we have been able to add many improvements and it has been a great experience for us as designers to contribute to a maturing product.

We will continue to iterate and refine the features that are launched and we’re currently mapping the roadmap for the months ahead. Our goal remains for Autopilot to be a tool for users to maintain and upgrade an enterprise grade cloud that can be at the core of their operations.

 

Read more