Canonical Voices

Posts tagged with 'featured'

Robin Winslow

I’ve been thinking about the usability of command-line terminals a lot recently.

Command-line interfaces remain mystifying to many people. Usability hobbyists seem as inclined to ask why the terminal exists, as how to optimise it. I’ve also had it suggested to me that the discipline of User Experience (UX) has little to offer the Command-Line Interface (CLI), because the habits of terminal users are too inherent or instinctive to be defined and optimised by usability experts.

As an experienced terminal user with a keen interest in usability, I disagree that usability has little to offer the CLI experience. I believe that the experience can be improved through the application of usability principles just as much as for more graphical domains.

Steps to learn a new CLI tool

To help demystify the command-line experience, I’m going to lay out some of the patterns of thinking and behaviour that define my use of the CLI.

New CLI tools I’ve learned recently include snap, kubectl and nghttp2, and I’ve also dabbled in writing command-line tools myself.

Below I’ll map out an example of the steps I might go through when discovering a new command-line tool, as a basis for exploring how these tools could be optimised for CLI users.

  1. Install the tool
    • First, I might try apt install {tool} (or brew install {tool} on a mac)
    • If that fails, I’ll probably search the internet for “Install {tool}” and hope to find the official documentation
  2. Check it is installed, and if tab-complete works
    • Type the first few characters of the command name (sna for snap) followed by <tab> <tab>, to see if the command name auto-completes, signifying that the system is aware of its existence
    • Hit space, and then <tab> <tab> again, to see if it shows me a list of available sub-commands, indicating that tab completion is set up correctly for the tool
  3. Try my first command
    • I’m probably following some documentation at this point, which will be telling me the first command to run (e.g. snap install {something}), so I’ll try that out and expect prompt succinct feedback to show me that it’s working
    • For basic tools, this may complete my initial interaction with the tool. For more complex tools like kubectl or git I may continue playing with it
  4. Try to do something more complex
    • Now I’m likely no longer following a tutorial, instead I’m experimenting on my own, trying to discover more about the tool
    • If what I want to do seems complex, I’ll straight away search the internet for how to do it
    • If it seems more simple, I’ll start looking for a list of subcommands to achieve my goal
    • I start with {tool} <tab> <tab> to see if it gives me a list of subcommands, in case it will be obvious what to do next from that list
    • If that fails I’ll try, in order, {tool} <enter>, {tool} -h, {tool} --help, {tool} help or {tool} /?
    • If none of those work then I’ll try man {tool}, looking for a Unix manual entry
    • If that fails then I’ll fall back to searching the internet again

UX recommendations

Considering my own experience of CLI tools, I am reasonably confident the following recommendations make good general practice guidelines:

  • Always implement a --help option on the main command and all subcommands, and if appropriate print out some help when no options are provided ({tool} <enter>)
  • Provide both short- (e.g. -h) and long- (e.g. --help) form options, and make them guessable
  • Carefully consider the naming of all subcommands and options, use familiar words where possible (e.g. help, clean, create)
  • Be consistent with your naming – have a clear philosophy behind your use of subcommands vs options, verbs vs nouns etc.
  • Provide helpful, readable output at all times – especially when there’s an error (npm I’m looking at you)
  • Use long-form options in documentation, to make commands more self-explanatory
  • Make the tool easy to install with common software management systems (snap, apt, Homebrew, or sometimes NPM or pip)
  • Provide tab-completion. If it can’t be installed with the tool, make it easy to install and document how to set it up in your installation guide
  • Command outputs should use the appropriate output streams (STDOUT and STDERR) and should be as user-friendly and succinct as possible, and ideally make use of terminal colours

Some of these recommendations are easier to implement than others. Ideally every command should consider their subcommands and options carefully, and implement --help. But writing auto-complete scripts is a significant undertaking.

Similarly, packaging your tool as a snap is significantly easier than, for example, adding software to the official Ubuntu software sources.

Although I believe all of the above to be good general advice, I would very much welcome research to highlight the relative importance of addressing each concern.

Outstanding questions

There are a number of further questions for which the answers don’t seem obvious to me, but I’d love to somehow find out the answers:

  • Once users have learned the short-form options (e.g. -h) do they ever use the long-form (e.g. --help)?
  • Do users prefer subcommands (mytool create {something}) or options (mytool --create {something})?
  • For multi-level commands, do users prefer {tool} {object} {verb} (e.g. git remote add {remote_name}), or {tool} {verb} {object} (e.g. kubectl get pod {pod_name}), or perhaps {tool} {verb}-{object} (e.g. juju remove-application {app_name})?
  • What patterns exist for formatting command output? What’s the optimal length for users to read, and what types of formatting do users find easiest to understand?

If you know of either authoritative recommendations or existing research on these topics, please let me know in the comments below.

I’ll try to write a more in-depth follow-up to this post when I’ve explored a bit further on some of these topics.

Read more
Inayaili de León Persson

Vanilla Framework has a new website

We’re happy to announce the long overdue Vanilla Framework website, where you can find all the relevant links and resources needed to start using Vanilla.

 

vanillaframework.io homepageThe homepage of vanillaframework.io

 

When you visit the new site, you will also see the new Vanilla logo, which follows the same visual principles as other logos within the Ubuntu family, like Juju, MAAS and Landscape.

We wanted to make sure that the Vanilla site showcased what you can do with the framework, so we kept it nice and clean, using only Vanilla patterns.

We plan on extending it to include more information about Vanilla and how it works, how to prototype using Vanilla, and the design principles that are behind it, so keep tuned.

And remember you can follow Vanilla on Twitter, ask questions on Slack and file new pattern proposals and issues on GitHub.

Read more
Robin Winslow

Canonical’s webteam manage over 18 websites as well as many supporting projects and frameworks. These projects are built with any combination of Python, Ruby, NodeJS, Go, PostgreSQL, MongoDB or OpenStack Swift.

We have 9 full-time developers – half the number of websites we have. And naturally some of our projects get a lot of time spent on them (like www.ubuntu.com), and others only get worked on once every few months. Most devs will touch most projects at some point, and some may work on a few of them in any given day.

Before any developer can start a new piece of work, they need to get the project running on their computer. These computers may be running any flavour of Linux or macOS (thankfully we don’t yet need to support Windows).

A focus on tooling

If you’ve ever tried to get up and running on a new software project, you’ll certainly appreciate how difficult that can be. Sometimes developers can spend days simply working out how to install a dependency.

XKCD 1742: Will it work?

Given the number and diversity of our projects, and how often we switch between them, this is a delay we simply cannot afford.

This is why we’ve invested a lot of time into refining and standardising the local development tooling, making it as easy as possible for any of our devs, or any contributors, to get up and running as simply as possible.

The standard interface

We needed a simple, standardised set of commands that could be run across all projects, to achieve predictable results. We didn’t want our developers to have to dig into the README or other documentation every time they wanted to get a new project running.

This is the standard interface we chose to implement in all our projects, to cover the basic functions common to almost all our projects:

./run        # An alias for "./run serve"
./run serve  # Prepare the project and run the local server
./run build  # Build the project, ready for distribution or release
./run watch  # Watch local files for changes and rebuild as necessary
./run test   # Check code syntax and run unit tests
./run clean  # Remove any temporary or built files or local databases

We decided on using a single run executable as our single entry-point into all our projects only after previously trying and eventually rejecting a number of alternatives:

  • A Makefile: The syntax can be confusing. Makefiles are really made for compiling system binaries, which doesn’t usually apply to our projects
  • gulp, or NPM scripts: Not all our projects need NodeJS, and NodeJS isn’t always available on a developer’s system
  • docker-compose: Although we do ultimately run everything through Docker (see below), the docker-compose entrypoint alone wasn’t powerful enough to achieve everything we needed

In contrast to all these options, the run script allows us to perform whatever actions we choose, using any interpreter that’s available on the local system. The script is currently written in Bash because it’s available on all Linux and macOS systems. As an additional bonus, ./run is quicker to type than the other options, saving our devs crucial nanoseconds.

The single dependency that developers need to install to run the script is Docker, for reasons outlines below.

Knowing we can run or build our projects through this standard interface is not only useful for humans, but also for supporting services – like our build jobs and automated tests. We can write general solutions, and know they’ll be able to work with any of our projects.

Using ./run is optional

All our website projects are openly available on GitHub. While we believe the ./run script offers a nice easy way of running our projects, we are mindful that people from outside our team may want to run the project without installing Docker, want to have more fine-grained control over how the project is run, or just not trust our script.

For this reason, we have tried to keep the addition of the ./run script from affecting the wider shape of our projects. It remains possible to run each of our projects using standard methods, without ever knowing or caring about the ./run script or Docker.

  • Django projects can still be run with pip install -r requirements.txt; ./manage.py runserver
  • Jekyll projects can still be run with bundle install; bundle exec jekyll serve
  • NodeJS projects can still be run with npm install; npm run serve

While the documentation in our READMEs recommend the ./run script, we also try to mention the alternatives, e.g. www.ubuntu.com’s HACKING.md.

Using Docker for encapsulation

Although we strive to keep our projects as simple as possible, every software project relies on dependent libraries and programs. These dependencies pose 2 problems for us:

  • We need to install and run these dependencies in a predictable way – which may be difficult in some operating systems
  • We must keep these dependencies from affecting the developer’s wider system – there’s nothing worse than having a project break your computer

For a while now, developers have been solving this problem by running applications within virtual machines running Linux (e.g. with VirtualBox and Vagrant), which is a great way of encapsulating software within a predictable environment.

Linux containers offer light-weight encapsulation

More recently, containers have entered the scene.

containers

A container is a part of the existing system with carefully controlled permissions and an encapsulated filesystem, to make it appear and behave like a separate operating system. Containers are much lighter and quicker to run than a full virtual machine, and yet provide similar benefits.

The easiest and most direct way to run containers is probably LXD, but unfortunately there’s no easy way to run LXD on macOS. By contrast, Docker CE is trivial to install and use on macOS, and so this became our container manager of choice. When it becomes easier to run LXD on macOS, we’ll revisit this decision.

Each project uses a number of Docker images

docker cat

Running containers through Docker helps us to carefully manage our projects’ dependencies, by:

  • Keeping all our software, from Python modules to databases, from affecting the wider system
  • Logically grouping our dependencies into separate light-weight containers: one for the database, and a separate one for each technology stack (Python, Ruby, Node etc.)
  • Easily cleaning up a project by simply deleting its associated containers

So the ./run script in each project will run the necessary commands to start the project by running the relevant commands inside the relevant Docker images. For example, in partners.ubuntu.com, the ./run command will:

Docker is the only dependency

By using Docker images in this way, the developer doesn’t need to install any of the project dependencies on their local system (NodeJS, Python, PostgreSQL etc.). Docker – which should be trivial to install on both Linux and macOS – is the single dependency they need to run any of our projects.

Keeping the ./run script up-to-date across projects

A key feature of this our solution is to provide a consistent interface in all of our projects. However, the script itself will vary between projects, as different projects have different requirements. So we needed a way of sharing relevant parts of the script while keeping the ability to customise it locally.

It is also important that we don’t add significant bloat to the project’s dependencies. This script is just meant to be a useful shorthand way of running the project, but we don’t want it to affect the shape of the project at large, or add too much extra complexity.

However, we still need a way of making improvements to the script in a centralised way and easily updating the script in existing projects.

A yeoman generator

To achieve these goals, we maintain a yeoman generator called canonical-webteam. This generator contains a few ways of adding the ./run architecture, for some common types of projects we use:

$ yo canonical-webteam:run            # Add ./run for a basic node-only project
$ yo canonical-webteam:run-django     # Add ./run for a databaseless Django project
$ yo canonical-webteam:run-django-db  # Add ./run for a Django project with a database
$ yo canonical-webteam:run-jekyll     # Add ./run for a Jekyll project

These generator scripts can be used either to add the ./run script to a project that doesn’t have it, or to replace an existing ./run script with the latest version. It will also optionally update .gitignore and package.json with some of our standard settings for our projects.

Try it out!

To see this ./run tooling in action, first install Docker by following the official instructions.

Run the www.ubuntu.com website

You should now be able to run a version of the www.ubuntu.com website on your computer:

  • Download the www.ubuntu.com codebase, E.g.:

    curl -L https://github.com/canonical-websites/www.ubuntu.com/archive/master.zip > www.ubuntu.com-master.zip
    unzip www.ubuntu.com-master.zip
    cd www.ubuntu.com-master
    
  • Run the site!

    $ ./run
    # Wait a while (the first time) for it to download and install dependencies. Until:
    Starting development server at http://0.0.0.0:8001/
    Quit the server with CONTROL-C.
    
  • Visit http://127.0.0.1:8001 in your browser, and you should see the latest version of the https://www.ubuntu.com website.

Forking or improving our work

We have documented this standard interface in our team practices repository, and we keep the central code in our canonical-webteam Yeoman generator.

Feel free to fork our code, or if you’d like to suggest improvements please submit an issue or pull-request against either repository.


Also published on Medium.

Read more
Matthew Paul Thomas

Designing build.snapcraft.io

In January, I was presented with a design challenge. Many open-source software developers use GitHub. Let’s make it as easy as possible for them to build and release their code automatically, as a snap software package for Ubuntu and other Linux systems. The result is now available to the world: build.snapcraft.io.

My first task was to interview project stakeholders, getting an understanding of the data and technical constraints involved. That gave me enough information to draw a basic user flow diagram for the app.

This include a front page, a “Dashboard”, a settings page, repo and build pages, and steps for adding repos, adding YAML, and registering a name, which would require Ubuntu One sign-in.

Next, I worked with visual designer Jamie Young to produce a “competitor analysis” of software CI (continuous integration) services, such as Travis, AppVeyor, and CircleCI. These are not actually competitors — our app works alongside whichever CI service you use, and we use Travis ourselves. But we weren’t aware of any existing service doing auto-building and distribution together. And CI services were useful comparisons because they have many of the same user flows.

Our summary of good and not-so-good details in those services became the basis for a design workshop in February, where designers, engineers, and managers worked together on sketching the pages we’d need.

My design colleague Paty Davila distilled these sketches into initial wireframes. I then drew detailed wireframes that included marketing and instructional text. Whether wireframing and copywriting are done by the same person or different people, doing them in tandem can reveal ways to shorten or eliminate text by improving layout or visual elements. I also wrote a functional specification describing the presence, contents, and behavior of each element in the site.

A sketch of the front page, one of several produced during the workshop. My minimal wireframe, including text. Several iterations later, a mockup from Jamie Young. The front page as it is today.

The design patterns in Canonical’s Vanilla CSS framework, for basic components like headings and buttons, made it possible for engineers to lay out pages based directly on the wireframes and functional spec with little need for visual design. But in a few cases, visual designers produced mockups where we had good reason to diverge from existing patterns. And the front page in particular benefited from illustrations by graphics whiz Matthieu James.

The most challenging part of designing this service has been that it communicates with four external systems: not just GitHub, but also the Launchpad build service, the snap store, and the Ubuntu One sign-on service. This has required special emphasis on handling error cases — where any of the external sites behave unexpectedly or provide incomplete information — and communicating progress through the overall flow.

Since launching the site, we’ve added the ability to build organization repos, making the service more useful for teams of developers. Once a repo admin adds the repo to build.snapcraft.io, it will show up automatically for their colleagues as well.

I continue maintaining the specification, designing planned features and addressing new constraints. As well as improving design consistency, the spec helps smooth the on-ramp for new developers joining the project. Engineers are working on integrating the site better with the Vanilla framework. And at the same time, we’re planning a project that will use build.snapcraft.io as the foundation of something much bigger. Good design never sleeps.

Meanwhile, if you have code on GitHub yourself, and this snap thing sounds intriguing, try it out.

Read more
Robin Winslow

Nowadays free software is everywhere – from browsers to encryption software to operating systems.

Even so, it is still relatively rare for the code behind websites and services to be opened up.

Stepping into the open

Three years ago we started to move our website projects to Github, and we also took this opportunity to start making them public. We started with the www.ubuntu.com codebase, and over the next couple of years almost all our team’s other sites have followed suit.

canonical-websites org

At this point practically all the web team’s sites are open source, and you can find the code for each site in our canonical-websites organisation.

www.ubuntu.com developer.ubuntu.com www.canonical.com
partners.ubuntu.com design.ubuntu.com maas.io
tour.ubuntu.com snapcraft.io build.snapcraft.io
cn.ubuntu.com jp.ubuntu.com conjure-up.io
docs.ubuntu.com tutorials.ubuntu.com cloud-init.io
assets.ubuntu.com manager.assets.ubuntu.com vanillaframework.io

We’ve tried to make it as easy as possible to get them up and running, with accurate and simple README files. Each of our projects can be run in much the same way, and should work the same across Linux and macOs systems. I’ll elaborate more on how we manage this in a future post.

README example

We also have many supporting projects – Django modules, snap packages, Docker images etc. – which are all openly available in our canonical-webteam organisation.

Reaping the benefits

Opening up our sites in this way means that anyone can help out by making suggestions in issues or directly submitting fixes as pull requests. Both are hugely valuable to our team.

Another significant benefit of opening up our code is that it’s actually much easier to manage:

  • It’s trivial to connect third party services, like Travis, Waffle or Percy;
  • Similarly, our own systems – such as our Jenkins server – don’t need special permissions to access the code;
  • And we don’t need to worry about carefully managing user permissions for read access inside the organisation.

All of these tasks were previously surprisingly time-consuming.

Designing in the open

Shortly after we opened up the www.ubuntu.com codebase, the design team also started designing in the open, as Anthony Dillon recently explained.

Read more
Tom Macfarlane

Our stand occupied the same space as last year with a couple of major
changes this time around – the closure of a previously adjacent aisle
resulting in an increase in overall stand space (from 380 to 456 square
metres). With the stand now open on just two sides, this presented the
design team with some difficult challenges:

  • Maximising site lines and impact upon approach
  • Utilising our existing components – hanging banners, display units,
    alcoves, meeting rooms – to work effectively within a larger space
  • Directing the flow of visitors around the stand

Design solution

Some key design decisions and smaller details:

  • Rotating the hanging fabric banners 90 degrees and moving them
    to the very front of the stand
  • Repositioning the welcome desk to maximise visibility from
    all approaches
  • Improved lighting throughout – from overhead banner illumination
    to alcoves and within all meeting rooms
  • Store room end wall angled 45 degrees to increase initial site line
  • Raised LED screens for increased visibility
  • Four new alcoves with discrete fixings for all 10x alcove screens
  • Bespoke acrylic display units for AR helmets and developer boards
  • Streamlined meeting room tables with new cable management
  • Separate store and staff rooms

Result

With thoughtful planning and attention to detail, our brand presence
at this years MWC was the strongest yet.

Initial design sketches

Plan and site line 3D render

 


Design intent drawings

 

 

 

 

 

3D lettering and stand graphics

 

 

 

 

 

Read more
Anthony Dillon

The Vanilla team needed to solve two issues which have been paining the development of Vanilla Framework for some time.

Firstly we needed to improve our workflow for testing and QAing components on our local machines. Up until now, we have been using npm link on our local branches of Vanilla with our local website branch, then reviewing the examples in the components page of the documentation. This caused a lot of extra overhead to reviewing Vanilla.

Secondly, since we actually build the docs.vanillaframework.io site using the Documentation theme (vanilla-docs-theme), the Vanilla pattern examples we ended up reviewing were no longer purely styled by Vanilla Framework, but as they were extended by the theme.

The documentation of the matrix pattern in Vanilla

The documentation of the matrix pattern in Vanilla

The solution

To solve both these issues, we decided to decouple the examples from the documentation. This change allowed us to move the coded examples of the patterns into a separate “examples” directory of the codebase and remove the hard-coded examples from the documentation.

As the examples were a part of the Vanilla Framework code we simply linked each example page with the Vanilla built from the same branch. This means all examples are only styled by Vanilla and nothing else.

Another benefit that came from this change was that now we have an easy way to find an example of a pattern when reviewing or QAing a pull request. Whereas previously we had to do the npm link dance. Now we simply check out the branch and run the internal Jekyll site to build Vanilla giving us a directory of pattern pages.

Examples in the docs

So we were happy with these changes: we had solved the issues at hand and were ready to head off and have a celebratory coffee.  But, we couldn’t leave the documentation without examples and code snippets.

To solve this issue, we used an embedding paradigm like on Codepen.

Example of a Codepen embed

Example of a Codepen embed

We set about creating a small JavaScript project that would find a link to the page with a specific class and grab the href attribute from it, replacing the link with an iframe of the link. This gave us a nice progressively enhanced experience:

Example of progressive enhancement - on the left is an example with JavaScript enabled, right is an example is JavaScript disabled.

An example of progressive enhancement – on the left is an example with JavaScript enabled, right is an example is JavaScript disabled.

We were still lacking the code snippets, so we made the script also pull the HTML source of the linked page into the example, then display the contents of the body in a code block appended after the iframe.

The wrap-up

And that was it. The solution gives us:

  • A single place for example code
  • Examples only displayed using Vanilla
  • A local testing environment
  • Documentation examples that are automatically up to date

We named this mini project example-js. Please feel free to fork it, use it or file any issues you may find.

Read more
Robin Winslow

We’ve been making an effort to secure all our websites with HTTPS. While some Canonical sites have enforced HTTPS for a while (e.g.: landscape.canonical.com, jujucharms.com, launchpad.net), it’s been missing from our other sites until now.

Why HTTPS?

The HTTPS movement has been building for years to help secure internet users against black-hat hackers and spies. The movement became more urgent after Edward Snowden revealed significant efforts by government agencies to spy on the world population.

The EFF have helped create two projects: LetsEncrypt – which massively simplifies the free installation of HTTPS certificates; and HTTPS Everywhere – a browser plugin to help you use HTTPS whenever it’s available. The advent of HTTP/2 has helped negate performance concerns when moving to HTTPS.

Google have also made efforts to encourage websites to enable HTTPS: First announcing in 2014 that they would consider HTTPS support in their search ranking algorithm; and last year, that Google Chrome would start visually warning users of “insecure” (non-HTTPS) websites.

Our sites

We made https://www.ubuntu.com HTTPS-only in October of last year, and have since done so on 10 more sites:

We hope to enable HTTPS on our other sites in the coming months.

Although enabling HTTPS can be relatively simple there were a number of specific challenges we had to overcome for some of our websites. I hope to write more about these in a follow-up post.

Read more
Tom Macfarlane

Yakkety Yak

The Yakkety Yak 16.10 release animal artwork is now available to download here.

16.10 release animal

db_yak_logo-artwork

Origami Yak

img_7731

Initial design exploration

Design development – head detail

db_yak_heads

Final Yak

Colourways

T-shirt design

db_yak_t-shirt

Read more
Grazina Borosko

The Yakkety Yak 16.10 is released and now you can download the new wallpaper by clicking here. It’s the latest part of the set for the Ubuntu 2016 releases following Xenial Xerus. You can read about our wallpaper visual design process here.

Ubuntu 16.10 Yakkety Yak

yakkety_yak_wallpaper_4096x2304

Ubuntu 16.10 Yakkety Yak (light version)

yakkety_yak_wallpaper_4096x2304_grey_version

Read more
Tom Macfarlane

Ubuntu Core

Recently the brand team designed new logos for Core and Ubuntu Core. Both of which will replace the existing Snappy logo and bring consistency across all Ubuntu Core branding, online and in print.

 

db_core_logo-aw

 

Guidelines for use

Core

Use the Core logo when the Ubuntu logo or the word Ubuntu appears within the same field of vision. For example: web pages, exhibition stands, brochure text.

Ubuntu Core

Use the Ubuntu Core logo in stand alone circumstances where there is no existing or supporting Ubuntu branding or any mention of Ubuntu within text. For example: third-party websites or print collateral, social media sites, roll-up banners.

The Ubuntu Core logo is also used for third-party branding.

The design process

Extensive design exploration was undertaken considering: logotype arrangement, font weight, roundel designs – exploring the ‘core’ idea, concentric circles and the letter ‘C’ – and how all the elements came together as a logo.

Logotype

Options for how the logotype/wordmark is presented:

  • Following the design style set when creating the Ubuntu brandmark
  • Core in a lighter weight, reduced space between Ubuntu and Core
  • Ubuntu in the lighter weight, emphasis on Core
  • Core on its own

 

db_core_logotype

 

Roundels

Core, circles and the letter ‘C’

 


Design exploration using concentric circles of varying line numbers, spacing and line weights. Some options incorporating the Circle of Friends as an underlying grid to determine specific angles.

Circle of Friends

 

Design exploration using the Circle of Friends – in its entirety and stripped down.

Lock-up

 

db_core_lock-up

How the logotype and roundel design sit together.

Artwork

Full sets of Core and Ubuntu Core logo artwork are now available at design.ubuntu.com/downloads.

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
Anthony Dillon

Web team hack day

Last week the developers in the web team swapped the office for the lobby of the hotel across the street. The day was geared up to allow us to leave our daily tasks in the office and think of ideas that we would like to work on.

The morning started with coffee and sitting in sofas brainstorming ideas. We collected a list of ideas from each person would like to work on. The ideas ranged from IRC bots to a performance audit of a few of our sites.

Choosing ideas

We wrote all the ideas on post it notes and lay them out on the table. Then each of us chose the idea we were most interested in working on by putting our hand on it. I worked out an almost perfect split of two people per idea, so we broke up into our teams and got to work.

Here are the things we worked on during this “hack day”.

IRC bots

These are bots that can listen to an action and report it to our IRC channel. For example, the creator of a pull request wouldn’t have to paste a link to their PR into our channel to be picked up for review.

This task was picked up by Karl and Will, who started by setting up a Hubot on Heroku. They attached a webhook to all projects under the ubuntudesign to listen for pull requests and report this in the web team channel.

This bot can be used for many other things like reporting deployments, CI failures, etc. We also discussed a method of subscribing to the notifications you are interested in, instead of the whole team being notified about everything.

Asset manager search improvements

Our asset manager and server acts as an internal asset storage. By storing an asset here we get a link to it which can be used by any website. As there are many assets stored in the asset manager we usually need to search existing assets to see if one already exists before making a new one.

Graham and myself picked this task and started by working out how to setup both the manager and server locally.

Previously the search would return results that contained either of a two-word query, but now the result has to contain all search terms to return.

We added our Vanilla framework to the front end, as it is obviously good to use our framework for all internal and external projects.

We have also implemented filtering results by file type, which makes it easy to go through what can sometimes be dozens of search results.

GitHub CMS

GitHub CMS is a nicer and more restricted interface that the marketing team can use to edit the GitHub repository containing page content for example, www.ubuntu.com.

Rich and Robin picked this task and began work on it straight away, by discussing the best approach and list of possible features.

Even though Robin was also helping out with. setting up the asset manager and server locally for Graham and me, he still managed to investigate the best Python framework to use and selected one. Rich on the other hand went ahead with the front end and developed a bunch of page templates using the new MAAS GUI Vanilla theme.

Commit linting

Commit linting is a service that gives a committer to a project a nice step by step wizard to build a high quality commit message.

Barry picked up this task and got the service up and running, and working, but hit a blocker at the point of choosing between different methods of committing. For instance, Tower would bypass this step and also we do not necessarily want to dictate to contributors which way they should commit code. This is something we will leave as an investigation for the time being.

Conclusion

Our hack day went well, in fact better than I imagined it would. We all had fun, got to work on things we found important but struggle to get prioritised in our day to day. It gave the developers a feeling of achievement and the buzz of landing and releasing something at the end of the day.

We will be attempting to do a hack day once every month or so, so watch this space!

Read more
Andrea Bernabei

Refreshed scrollbars!

You may have noticed that the scrollbars available on Ubuntu Touch and the Unity8 environment have recently received a huge overhaul in both visual appearance and user experience. More specifically, we redesigned the Scrollbar component (which is already provided in the Ubuntu UI Toolkit) and added a new ScrollView component that builds on top of it and caters for convergence.

Technical note to app developers: the Scrollbar component is still available for compatibility purposes, but we recommend transitioning to the new and convergent ScrollView.

How did we do it?

The process was as follows:

  • Interaction design was specified
  • Applied visual style to the component
  • Prototyped the component
  • Iterated over design and performed user testing
  • Sent for review to the SDK team and integrated into the UI toolkit.

We started by researching the field, exploring the possibilities and thoroughly analyzing the history of the scrollbar component. The output of this step was an interaction specification. The visual design team picked that up and applied our visual style to the component, ensuring a consistent visual language across all the elements provided by the UI Toolkit.

Once we had a first draft of the interaction and visual specs, we created a prototype of the component.
We then iterated over the design choices and refined the prototype. While iterating we also took into account the results of the user testing research that we conducted in the meanwhile. The testers found the new scrollbars easy to use and visually appealing. The only pain point highlighted by the research were the stepper buttons, that were deemed a bit small. We refined them by creating a new crispier graphic asset and by tweaking their size as well as the visual feedback they provided, especially when being hovered with a mouse.

Once we were happy with the result, we submitted our work to be reviewed by the SDK team. The SDK team are the final gatekeeper and decide whether the implementation of a component is ready to be merged to the UI Toolkit or not. The review process can be lengthy, but it is of great help in ensuring a higher code quality, less bugs and clearer documentation. Once the SDK team gave the green light, the component was merged to the next release of the UI Toolkit.

What did we change?

A critical requirement of the new solution was to be “convergence-ready”. Convergence means implementing a UI that scales not just across form factors, but also across different input devices. This is particularly important in the case of scrolling, as it must be responsive to all input devices.

The new ScrollView can be interacted with using the touchscreen of your phone or tablet, but thanks to convergence, now your tablet can turn into a full fledged computing device with a hardware keyboard and a pointer device, such as a mouse. The component must be up to the task and adapt to the capabilities provided by the input device which is currently in use.

At any time, the new scrollbar can be in one of the 3 following modes:

  • Indicator mode, where the scrollbar is a non-interactive visual aid;
  • Thumb mode, that allows quick scrolling using a touch screen;
  • Steppers mode, optimized for pointer devices interactions.

Let’s go through the modes in more detail.

Indicator mode

Whenever the user scrolls content without directly interacting with the scrollbar, i.e. he or she performs a flick or uses the mouse wheel or keyboard keys, the scrollbar gently fades in as an overlay on top of the content. In this mode the scrollbar is not interactive, and just acts as a visual aid to provide information about the position of the content. The indicator gently fades out following a short timeout after the surface stops scrolling.

Please note: we will be replacing these images with GIFs soon.

scrollview-touch

 

Thumb mode

Imagine you want to send a picture to a friend of yours, but the file is somewhere down the very lengthy grid of pictures. Let’s also suppose you’re using a smartphone or tablet and you have no mouse or keyboard connected to it. Wouldn’t it be handy to have a way to quickly scroll a long distance without having to repeatedly flick the list? We designed Thumb mode to address that use case.

When the content on screen reaches a length of 10 or more pages, the thin indicator provided by the indicator mode grows thicker into an interactive thumb. That marks the transition to the Thumb mode. While the scrollbar is in Thumb mode you can drag the thumb using touchscreen to quickly scroll the content.

The component still fades out when the user stops interacting with the surface and the surface stops scrolling, in order to leave as much real estate to the application content as possible.

Stepper mode

scrollview-pointer

When the user is interacting with the UI using a pointer device, they expect a different experience than a touchscreen. Pointer devices allow for much more precise interactions and also provide different ways of interacting with the UI components, such as hovering. A good convergent component exploits those additional capabilities to provide the best user experience for the input device which is currently in use.

When the user hovers over the area occupied by the (initially hidden) scrollbar, the bar reveals itself, this time in what we call Stepper mode.

This mode is optimized for pointer device interactions, although it can be interacted with using touchscreen as well. More generally, for a component to be defined convergent the user must be able to start interacting with it using one input device (in this case, a mouse) and switch to another (e.g. touch screen) whenever they wish to. That transition must be effortless and non disruptive.

When in Stepper mode, the scrollbar has a thick and interactive thumb. This is similar to the Thumb mode we presented in the previous section. However, Stepper mode also provides a semi-transparent background and the two clickable stepper buttons desktop users are already accustomed to. The steppers buttons can be clicked to scroll a short distance. Holding a stepper button pressed will scroll multiple times.

The areas above and below the thumb are also interactive. You can click/tap or press-and-hold to scrolling by one or more pages.

Once the user moves the pointer away from the scrollbar area and the surface stops scrolling, the component elegantly fades out, just like in the other modes.

Visual convergence

We put a lot of efforts into making the transitions between the different modes as smooth and visually pleasing as possible. The alignment of the sub components (the thumb, its background, the stepper buttons), their sizes, their colours have been carefully chosen to achieve that goal.

When the bar grows from Indicator to Thumb modes and vice versa, it does so by anchoring one side and expanding only the opposite one. This minimizes unexpected movements and produces a simple yet crisp animated transition. Those same principles also apply to the transitions from thumb to stepper modes and indicator to stepper and vice versa. We wanted to create transitions that would look elegant but not distrustful.

The new scrollbar also provides visual aids to indicate when a pointer device is hovering over any of the sub components. Both the stepper buttons and the thumb react to hovering by adjusting their colours.

Scroller variations

Interaction handling convergence

A lot of effort has gone into tweaking the interactions to provide an effortless interaction model. Here’s a summary of how we handle touch screen and pointer devices:

  • Thumb mode features a thicker interactive thumb to allow quick scrolling using touch screen;
  • Press-and-holding the steppers buttons provides an effortless way to perform multiple short scrolls;
  • Press-and-holding the areas above and below the thumb makes provides easy multiple page scrolling;
  • Mouse hovering is exploited to reveal or hide the scrollbar;
  • Visual feedback on press/tap;
  • Visual feedback on pointer device hover.

It is a lot of small (and sometimes trivial!) details that make up for a great user experience.

Some of you might be wondering: “what about keyboard input?”

I’m glad you asked! That is an important feature to realize full convergence. The ScrollView components handles that transparently for you. Scrolling content using the keyboard is just as easy as scrolling using the touchscreen or any pointer device:

  • Arrow keys trigger a short scroll;
  • PageUp/PageDown trigger a page scroll;
  • Home/End keys trigger scrolling to the top/bottom of the content, respectively
  • Holding a key down triggers multiple scrolls;

What did we achieve?

The new scrollbars fully implement our vision of convergence. The user can interact with any of the input device he has available and switch from one to the other at any time. The interactions feel snappy and we think the component looks great too!

We can’t wait for you to try it and let us know your opinion!

What does the future hold?

The focus so far has been on getting the right visual appearance and user experience.

However, in order to have a complete solution, we also need to make sure adding such a feature as scrollbars to the applications does not come with a big performance drawback. Ideally, all the scrollable surfaces (images, text fields, etc) should include a scrollbar and that means it’s very important to provide a component that is not just easy to use and visually appealing but also extremely performant.

There are two main aspects where the performance of this component comes into play: the performance of interactions, so that they happen immediately and without unexpected delays. I believe we’re in a very good shape there. The second is: the time it takes to create a scrollbar when an application needs one; this affects application startup time and the time it takes to load a new view that holds scrollable content.

A few changes have already been implemented, which has resulted in a speed-up of about 25%. These changes should be released with OTA13.

If you have ideas or want to provide any feedback, here are the contact details of the people who worked on this project.

IRC: #ubuntu-touch channel on FreeNode server

Alternatively, start a thread on the ubuntu-phone mailing list.

Read more
Steph Wilson

Last week we released phase 1 of the new App Design Guides, which included Get started and Building blocks. Now we have just released phase 2: Patterns. This includes handy guidance on gestures, navigation and layout possibilities to provide a great user experience in your app.

Navigation: user journeys

Find guidance for utilizing components for effective and natural user journeys within your UI.

750w_Navigation_UserJourney (2)

Layouts: using Grid Units

Use the Grid Unit System to help visualise how much space you have in order to create a consistent and proportionate UI.

750w_Layouts_GridUnitSystem

More to come…

More sections will be added to patterns in the future, such as search, accessibility and communication.

Up next is phase 3: System integration; which includes the number of a touchpoints your app can plug into inside the Ubuntu operating system shell, such as the launcher, notifications and indicators.

If you want to help us improve these guides, join our mailing list. We’d love to hear from you!

Read more
Elvi

Over the past few months, the Juju team has been working on a whole redesign of the Juju store </><style=”font-weight: 400;”>homepage</><style=”font-weight: 400;”> and we’re very happy to announce that it is now live!

Juju is an application and service modelling tool that enables you to quickly model, configure, deploy and manage applications in the cloud. Juju comes with ready-made solutions for everything you need – these solutions are encapsulated in Charms and Bundles:

  • Charms contain all the instructions necessary to deploy, manage and scale cloud applications.
  • Bundles are collections of charms that work together, deploying an entire application or chunk of infrastructure in one go.

The new Juju Charm store allows you to explore the growing ecosystem of over 300 charms and bundles – everything you need to build your app.

You can now get started with the featured charms and bundles at the top or explore the whole collection of categories:

Screen Shot 2016-07-18 at 12.53.40

 

We’ve surfaced key categories and highlighted their most popular services:

Screen Shot 2016-07-18 at 12.54.36

Screen Shot 2016-07-18 at 12.55.28

 

The search stays the same for now, but we’re working on improvements which will be released in the near future:

 

Screen Shot 2016-07-18 at 12.59.10

 

You can explore bundles and view charm details:

Screenshot 2016-07-10 14.10.08

Screenshot 2016-07-10 14.11.20

 

And deploy your chosen charm, using the GUI or CLI:

 

Screenshot 2016-07-10 14.13.20

 

Check it out at:https://jujucharms.com/store

 

How did we arrive at this solution?

We’ve summarised four of the most important stages of the project for you to get an insight into our design process.

  1. Defining the problem

You may want a shiny new design, but if you don’t understand the problems that you are trying to solve you’ll probably find yourself having to redesign the whole page again in no time. We therefore began by identifying the issues that we wanted this new design to tackle,  and laying out the new store requirements.

This is what the store homepage looked like before the redesign:

 

Screen Shot 2016-07-11 at 13.36.52
Screen Shot 2016-07-11 at 13.37.10

 

The original goal of this page was to feature the breadth of the software available for Juju. However, there were a number of elements in our previous design that didn’t facilitate a smooth browsing experience. As the Juju ecosystem grew, we found the need to increase the store’s performance by:

  • Providing a more curated selection to users when they arrive at the store
  • Highlighting the most popular and interesting charms and bundles for users to get started
  • Providing better discovery methods for browsing
  • Encouraging exploration
  • Reducing cognitive load
  • Helping visitors find what they’re looking for with the least amount of friction.

 

  1. Understanding our audience

Before making any design decisions we:

  • Conducted a round of user testing to uncover friction points and reveal insights into our users’ behaviour and needs.
  • Dived into our site’s analytics to learn more about how current users are moving across the store.
  • Looked at conversion, bounce rate and page views.
  • Identified what search terms are used most and what terms and categories were the most popular.
  • Tagged our content to increase findability.

It’s a surprisingly large amount of prep work but absolutely essential – all this research enabled us to gain some insight into our audience and allowed the definition of use cases which we then used as a basis for our designs.

 

  1. Researching our competitors

We also undertook a competitor benchmarking project with the aim of:

  • Comparing our general practices and performance with that of our competitors
  • Identifying the strengths and weaknesses of our competitors and review that against our own.
  • Identifying pitfalls to avoid and ways in which we could improve our page.

IMG_2367_4352b

 

  1. Test the performance

Testing the design enabled us to continuously iterate towards a solution that, when finalised, was very well received by the community. We love conducting user testing sessions to see how our designs are performing, and it’s hard to over-emphasise the importance of watching actual people interact with your design!

We’ve enjoyed every stage of this process and are very happy it is now available to the public. We’d welcome any feedback, please don’t hesitate to share it here. Check it out here

 

Read more
Grazina Borosko

Every year since 2001, creatives from different design disciplines meet and share their ideas and innovations about digital, interaction and print design in the design festival called OFFF.

This festival was previously held in different countries, but has now found its home in Barcelona at the Design Museum. For three days the festival was jam-packed full of inspirational ideas and speakers such as Paula Scher, Tony Brook, Joshua Davis and many more.

 

IMG_4973

OFFF  space in the Design Musem

OFFF

OFFF 2016 book and program

What is the festival about?

The festival gives a great overview of design trends, work processes and implementation practices, as well as generating ideas and inspiration from around the world. A festival organizer claimed that: “it is more than just a Festival hosting innovative and international speakers, it is more than a meeting point for all talents around the world to collaborate, it is more than feeding the future. OFFF is a community inviting all those who are eager to learn to participate and get inspired by a three-day journey of conferences, workshops, activities, and performances.”

 

Ustwo

Ustwo

Hey studio

Hey studio

A word of advice…

Before coming to the festival make sure you have a list of speakers you would like to hear, because there are 50 different talks taking place covering a wide scope of topics. It was interesting to hear designers sharing their experiences in design, such as self-initiated projects, dealing with clients, social life versus private, time management and working in a team and solo difficulties.

 

Nonformat

Non-Format

Joshua Davis deisgn

Joshua Davis design

Why you should go to the festival

Being surrounded by creative people for a three days helps you look at your work from the different perspectives. It is always healthy to leave your comfort zone and talk to other creators to see what kind of issues other people have, and how they are solving them. There’s no wrong or right way in the creative process. There are different ways which might work for you, and some that don’t. Inspiring talks give you energy and make you believe that anything is possible to achieve; you just need to do it!

 

Mark Adamson

Danny Sangra

 

 

Read more
Luca Paulina

Juju GUI 2.0

Juju is a cloud orchestration tool which enables users to build models to run applications. You can just as easily use it to deploy a simple WordPress blog or a complex big data platform. Juju is a command line tool but also has a graphical user interface (GUI) where users can choose services from a store, assemble them visually in the GUI, build relations and configure them with the service inspector.

Juju GUI allows users to

  • Add charms and bundles from the charm store
  • Configure services
  • Deploy applications to a cloud of their choice
  • Manage charm settings
  • Monitor model health

Over the last year we’ve been working on a redesign of the Juju GUI. This redesign project focused on improving four key areas, which also acted as our guiding design principles.

1. Improve the functionality of the core features of the GUI

  • Organised similar areas of the core navigation to create a better UI model.
  • Reduced the visual noise of the canvas and the inspector to help users navigate complex models.
  • Introduced a better flow between the store and the canvas to aid adding services without losing context.
Hero before
Hero after

‹ ›

Empty state of the canvas

 

Hero before
Hero after

‹ ›

Integrated store

 

Hero before
Hero after

‹ ›

Apache charm details

 

2. Reduce cognitive load and pace the user

  • Reduced the amount of interaction patterns to minimise the amount of visual translation.
  • Added animation to core features to inform users of the navigation model in an effort to build a stronger concept of home.
  • Created a symbiotic relationship between the canvas and the inspector to help navigation of complex models.
Hero before
Hero after

‹ ›

Mediawiki deployment

 

3. Provide an at-a-glance understanding of model health

  • Prioritised the hierarchy of status so users are always aware of the most pressing issues and can discern which part of the application is effected.
  • Easier navigation to units with a negative status to aid the user in triaging issues.
  • Used the same visual patterns throughout the web app so users can spot problematic issues.
Hero before
Hero after

‹ ›

Mediawiki deployment with errors

 

4. Surface functions and facilitate task-driven navigation

  • Established a new hierarchy based on key tasks to create a more familiar navigation model.
  • Redesigned the inspector from the ground up to increase discoverability of inspector led functions.
  • Simplified the visual language and interaction patterns to help users navigate at-a-glance and with speed to triage errors, configure or scale out.
  • Surfaced relevant actions at the right time to avoid cluttering the UI.
Hero before
Hero after

‹ ›

Inspector home view

 

Hero before
Hero after

‹ ›

Inspector errors view

 

Hero before
Hero after

‹ ›

Inspector config view

 

The project has been amazing, we’re really happy to see that it’s launched and are already planning the next updates.



<>

Read more
James Mulholland

We’re very happy to announce the return of the Ubuntu App Design Clinics.

The first session is planned for 4.00PM BST on Friday the 17th of June, with subsequent sessions occurring at 4.00PM BST on Thursdays.

We’ll be on camera talking to Dan Wood regarding his work on the OwnCloud App. Feel free to drop in and join the discussion via IRC:
http://ubuntuonair.com/

image

For more information regarding Dan Wood and his work, be sure to stop by his Google Plus. You can also stop by Dan’s Owncloud Telegram Group anytime and talk about the application with its creator.

We look forward to seeing you there!

Read more
Grazina Borosko

Last year we were working on OOBE redesign with the aim to improve first user experience with Ubuntu phone. Now the Design Team is working on the second part of this project which we call Edge Education.

The purpose of Edge Education is to aid discoverability and to educate users into using them naturally. For example, did you know what you can access the whole system by swiping from the edges of the screen.

How many edges Ubuntu phone has?

At the moment, the Ubuntu phone has four edges that can be interacted with in six ways.

Left short swipe

If you short swipe across the left edge you will open the launcher.

Left long swipe

You can quickly come back from any app to the Dash by a long left swipe.

Top swipe

Swiping from the top edge will give you access to indicator menus.

Right long swipe

Long swipe from the right edge will open the switcher to let you move between open apps.

Right short swipe

Swiping from the right edge you will switch between your current and previous app (ALT-TAB interaction).

Bottom swipe (app specific)

Swiping from the bottom edge brings you different functionality depending if you are in app or scope. Not all apps has a bottom edge. If an app has a bottom edge you will know this by seeing a bottom edge hint. For example, you can add a new contact by swiping from the bottom edge in the Contacts app. By doing bottom edge swipe in the scopes you can quickly favourite and unfavorite your scopes.

Read more