Posts tagged with 'notes'

If you’re a regular visitor to Snapcraft.io or any of its associated sites, you will have noticed a change recently to the logo and overall branding which has been in development over the past few months. We have developed a stand-alone brand for Snapcraft, the command line tool for writing and publishing software as a snap. One of the challenges we faced was how to create a brand for Snapcraft that stands out in its own right yet fitted in with the existing Ubuntu brand and be a part of the extended family. To achieve this, we took reference from the Suru visual language. The Suru philosophy stems from our brand values alluding to Japanese culture. Working with paper metaphors we were inspired by origami as a solid and tangible foundation.

We identified the key attributes of:

Simple – to package leveraging your existing tools

Integrated – easily with build and CL infrastructure

Effortless – roll back versions

Easy – integrate with build and CI infrastructures

We worked with these whilst keeping with the overall Ubuntu brand values of:

Freedom

Reliable

Precise

Collaborative

We started exploring the Origami language and felt the idea of a bird fitted well with the attributes. We worked at simplifying the design until we had it at it’s most minimal we could whilst retaining the elegance of a bird in flight.

A new colour scheme was developed to have a clean fresh look while sitting comfortably with the primary and secondary Ubuntu colour palette. We used the Ubuntu font for consistency with the overall parent brand, and in this instance we used the thin weight along side the light to create a dynamic word mark reflecting the values of Freedom, Precision, Collaboration and Reliable.

Colour Palette

Lock-up

We have a number of different Lock-ups we can use for different circumstances

Recently a number of new designers and developers joined our team – welcome Caleb, Lyubomir, Michael, Thomas and Shivam!

As part of the introduction to Canonical and the Design team, each member of the team gives an overview of the products we design for. As the Lead UX designer for MAAS I did so by explaining the functionality of MAAS on a high level, which was inevitably followed by a lot of questions for more details. In order to provide a complete MAAS introduction I put together a small list of resources that would help the newcomers but also the veterans in our team dig deeper into this metal world..

I am now sharing this list with you and hope that it will help you get started with MAAS.

Happy reading!

Introduction

There are various sources where you can get information about MAAS and the concepts it involves; the Ubuntu websites, Wikipedia, youtube and blogs are all places you can find bits and pieces that will help you understand more about MAAS.

Then there are also a lot of people working on MAAS; myself and the other designers and of course the MAAS engineering team would be happy to help with any questions you might have. You can reach MAAS-ters on the public IRC channel (Freenode #maas) and the Ask Ubuntu website.

Here is a list that I think might be a good start to understand what MAAS does, its features and concepts as well as some of the functionality. It is sorted from high to low-level information and it allows you to go as deep as you want.

Chapter I – MAAS and server provisioning

If you are a server provisioning novice, you can start with some sources for understanding what server provisioning is, which is the main thing that MAAS is used for. If you already know about server provisioning you can move to the next section that explains what MAAS is.

A recent Webinartakes you through the steps of how to get cloud-ready servers in minutes with MAAS. By Dariush Marsh-Mossadeghi (Consulting Architect) and Chris Wilder (Cloud Content).

Canonical’s e-book on What you need to know about server provisioning is also quite insightful. It contains a lot of content from the maas.io homepage and the How it works page and some additional information.

Take a look at the tour page to get an overview of the functionality and pick up terms that you can search further to find out what they mean.

And here is a couple of videos explaining what MAAS is

Metal As A Service – the model (you can jump to 2:13 where the model starts getting explained)

Now that you are more familiar with MAAS’s basics, how about seeing it in action? MAAS is free and open source and you can install it in 6 simple steps. The maas.io install page will guide you through them or if you prefer this video shows the installation process. Happy provisioning!

We’ve all seen the annoying cookie notification which website owners are legally obliged to include on their sites. We can’t avoid them, so let’s have some fun with them.

Previously, for Canonical’s sites, the cookie notification was a shared CSS file and JavaScript file that we injected into the head of each site. This resulted in a cookie policy notification appearing at the bottom of the site.

Job done, I hear you say. But the styling of the notification was becoming dated and after the redesign of the Vanilla notification pattern we wanted to align them. So we decided to create a small service/component to serve cookie notifications in a consistent and more manageable way.

The JavaScript

We started by developing a small JavaScript function in ES6 that took an optional object to set two options: a custom notification message and an auto destroy timeout value in milliseconds.

To initialise the cookie notification component you simply add the following to your site’s footer.

var options = {
'content': 'We use cookies to improve your experience. By your continued use of this site you accept such use.
This notice will disappear by itself. To change your settings please see our policy.',
'duration': 3000
}
ubuntu.cookiePolicy.setup(options);

The styling

We wanted to use Vanilla’s notification styling as the base for the cookie message. We could simply copy the SCSS or even the compiled CSS into the component and call it a day. But that would get out of date quickly.

To avoid this, we made Vanilla framework an npm dependency of the cookie project and include just the notification styling. Importantly, this gave us a version of Vanilla that we could use to indicate if the package needs to be updated and the effects of the update. We could also update the project’s styling simply by running npm update.

Serving the cookie notification

We decided to deliver this project with Bower as our package manager of choice, as we wanted to dictate the location that the Bower components are installed, which is defined in our .bowerrc file.

One tradeoff of using Bower as a package manager is that the built CSS and JS need to be committed into the GitHub repository. This is due to the way in which Bower installs packages: it effectivity clones the project into the components directory. Therefore the pull requests are not as clean but it can be worked around by mentioning which files to ignore in the pull request description.

This means we don’t need the target site or app to support Sass or ES6 compilation. Simply embed the built CSS and JS file into the head of the site or app.

Conclusion

This process has helped to make our small components much more manageable, by splitting them into their own small project, giving them a home and a test HTML file which can run locally to see the development of component on its own.

We plan to continue to split out components into their own projects when it makes sense and delivers them in this fashion.

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:

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.

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:

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:

Billy: software engineer, very tech savvy and tech enthusiast.

Magda: Our former PM and very familiar with our product and designs.

Stefanie: Our Office Manager who knows our products but not so familiar with our designs.

Rodney: Our IS Associate who is tech savvy but not familiar with our design work

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.

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.

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.

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.

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.

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!

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!

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.

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.

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.

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.