The Web and design team at Canonical runs in two-week iterations building and maintaining all of the Canonical websites and product web interfaces. Here are some of the highlights of our completed work from this iteration.
We recently released a new version of our global-nav JS module, a utility that adds a dropdown menu featuring links to all of Canonical’s products in a central location.
Up to now, the global-nav has appeared as a completely separate element that sits above all other site content:
The new version, v3.0, features the same content, but is specifically designed to integrate with the recently updated Vanilla navigation pattern, where it appears as another navigation item labelled “All Canonical”:
This will be rolled out to all of Canonical’s sites in the very near future.
The Brand team develop our design strategy and create the look and feel for the company across many touch-points, from web, documents, exhibitions, logos and video.
In this iteration we interviewed some agencies to help with the new Canonical brand rollout, we will choose which one to work with very soon. We also reviewed the initial work completed on our new variable font, it’s early days but we are excited that this work is underway. We have also been looking at how our new illustrations work when required for use in animations.
BAU work this iteration has included whitepapers and datasheets, along with some new community stickers for the Jammy Jellyfish release. Finally, we have been planning and reviewing a new animation for our automotive work.
The image below shows a selection of this work.
We’ve worked on the Anbox user interface to simplify the task of updating Application settings. The new design has fewer editable fields, all changes are reflected in the current version of the application instead of creating new ones, and the APK file no longer needs to be re-uploaded.
For more information about how to get started visit the Anbox cloud website.
The UA subscribe view is where you can select and purchase your UA subscription from the website. We’re still in the design and research phase of the UA subscribe view, following multiple rounds of iteration and user testing. We’re hoping to complete this design work really soon and begin the UI build.
In preparation for the redesign of the UA subscribe view as well as to be more easily shared between marketplaces, the product selector has been written in React.
MAAS UI demos are now live. This means that a new test site demonstrating changes to MAAS UI gets automatically created and is available within minutes after creating a pull request.
This makes the QA process considerably faster giving our developers and designers extra time to focus on delivering new features.
MAAS UI demos serve a production bundle and run on a full MAAS instance making sure we’re testing as close to the “real thing” as possible.
Users of MAAS are often found to be running more than one MAAS instance at a time, with each having a different purpose e.g. production, development, and testing. Previously in the UI, the only way to distinguish between the different MAASes was to check either the URL, or the instance name in the status bar, which can be super easy to miss on large screens. This can lead to errors, since actions may be performed on one MAAS that was intended for another one. We wanted to create a way of more easily distinguishing different MAASes to help prevent these errors in the future.
To achieve this, we made three changes to the UI:
After a long time in the works, Snapcraft now supports Star Developers.
What is a Star Developer? In the blog post, Star Developers are here! Holly explains, “The idea behind this feature is to celebrate and highlight active, responsible participants of the community.”
But how do you know who a Star Developer is? In search results and snap listing pages, you’ll see a white star in an orange circle next to the publisher’s name.
We’re in the early stages of the feature so there aren’t many Star Developers yet, but if you want to find out more, or become a Star Developer read Holly’s blog post and forum post that outlines the policy. Happy snapping.
When we started working on Charmhub, the idea was to use what we learned designing and building Snapcraft as a base, reusing as many components as possible. Unfortunately, as is the case in most projects, designs, and implementations diverged to meet the specific need of each marketplace. Now, with Snapcraft being stable, and Charmhub being more fully featured, it’s time to take stock, spot patterns, and pull the two sites back together.
The work is split into various stages, the first being documentation. In this iteration, we’ve been focused on identifying features that are common or should be common, to both sites and exploring the differences and potential directions to take both sites.
Once the documentation stage is complete, we’ll move on to writing guidelines and best practices, followed by the implementation to bring both sites into alignment. This won’t be a fast process, but we’ll post updates as and when we have something to share.
We have been working on a new page template for interfaces on charmhub.io. This project request came after the work we did for the integrations tab on charm pages.
Integrations are handled through interfaces which define and test the schema two charms use to ‘talk’ to each other.
One goal of having interface pages is to help operators understand these schemas and whether the charms they want to relate will work together. The second goal is for developers to have a grab-bag of interfaces that they know will help their charm relate with others seamlessly. It is essentially a specification for how the interfaces are supposed to behave, and what charms require/provide that interface.
Sharing the decision-making on how existing interfaces should be standardised and what new interfaces are needed is critical for the cross-relation ecosystem to grow, as such community engagement is encouraged on the pages. The user will be able to contribute with content for the pages, or file bugs, through the project repository on GitHub.
This project is still a work in progress, currently under UX review.
The Workplace Engineering team builds data products that help people make better decisions about people. We work with the Human Resources department, building internal tools to make life easier for every employee at Canonical.
The User Research team works with the design and product management, to provide insights into our users’ needs and tools for teams to conduct their own research.
In this iteration, we’ve been conducting interviews and exploring analytics to better understand the experience of installing a wide range of popular and important software on the Ubuntu Desktop, via the Snap Store and other routes. We aim to understand how to improve discoverability, trust and performance.
We’ve also been validating the design of a new stepper pattern. The stepper pattern will indicate the number of steps involved in the process and which one you are currently on. This is planned to be included on our sites soon, including tutorials and installation guides, to guide and set users’ expectations through different processes.
If you would like, please join our user testing group.
This is a newly emerging team that handles the team’s tooling, process and infrastructure. Maintaining mission-critical systems such as assets, our k8s cluster, and much more.
We used to have a server docs PDF built daily from the source documentation but this cron job got lost in an update. So we needed to rebuild that. This script now downloads the source, converts the content using pandoc and uploads that to the assets server.
Our team uses a tool called “dotrun” to develop Node.js and Python projects. This tool makes use of standard `package.json` script entry points. The new version of Dotrun uses a Docker image to provide a predictable sandbox for running Node and Python projects.
If you are interested, have a look at our dotrun repository.
With ♥ from Canonical web team.