Canonical Voices

Anthony Dillon

The Juju web resources are made up of two entities: a website and an app called Juju GUI, which can be demoed at

Applying Vanilla to

Luckily the website was already using our old style guidelines, which we refactored and improved to become Vanilla, so I removed the guidelines link from the head and the site fell to pieces. Once I NPM installed vanilla-framework and included it into the main sass file things started to look up.

A few areas of the site needed to be updated, like moving the search markup outside of the nav element. This is due to header improvements in the transition from guidelines to Vanilla. Also we renamed and BEMed our inline-list component, so I updated its markup in the process. The mobile navigation was also replaced with the new non-JavaScript version from Vanilla.

To my relief with these minor changes the site looked almost exactly as it did before. There were some padding differences, which resulted in some larger spacing between rows, but this was a purposeful update.

All in all the process of replacing guidelines with Vanilla on the website was quick and easy.

Now into the unknown…

Applying Vanilla to Juju GUI

I expected this step to be trickier as the GUI had not started life using guidelines and was using entirely bespoke CSS. So I thought: let’s install it, link the Vanilla framework and see how it looks.

To my surprise the app stayed together, apart from some element movement and overriding of input styling. We didn’t need the entire framework to be included so I selectively included only the core modules like typography, grid, etc.

The only major difference is that Vanilla applies bottom margin to lists, which did not exist on the app before, so I applied “margin-bottom: 0” to each list component as a local override.

Once I completed these changes it looked exactly as before.

What’s the benefit

You might be thinking, as I did at the beginning of the project, “that is a lot of work to have both projects look exactly the same”, when in fact it brings a number of benefits.

Now we have consistent styling across the Juju real estates, which are tied together with one single base CSS framework. This means we have exactly the same grid, buttons, typography, padding and much more. The tech debt to keep these in sync has been cut and allows designers to work from a single component list.


We’re not finished there, as Vanilla framework is a bare bones CSS framework it also has a concept of theming. The next step will be to refactor the SCSS on both projects and identify the common components. The theme itself depends on Vanilla, so we have logical layering.

In the end

It is exciting to see how versatile Vanilla is. Whether it’s a web app or web site, Vanilla helps us keep our styles consistent. The layered inheritance gives us the flexibility to selectively include modules and extend them when required.

Read more
Rae Shambrook

We previously posted about the clock app’s new look and today we are getting to know one of the developers behind the clock ( as well as other community apps.)  Bartosz Kosiorek gives us a glimpse into developing for Ubuntu and how he got started.

1) First, can you give us a bit of background about yourself and tell us how you started developing for Ubuntu?

My name is Bartosz and I’m from Poland. Currently I’m the developer for the Ubuntu Clock and Ubuntu Calculator. I started contributing to Ubuntu in 2008, by submitting bug reports into launchpad and fixing translations. Later I participated in the One Hundred Papercuts project. I made SRU verifications and eventually started developing.

My adventure with Ubuntu started from Ubuntu 8.10 (Interpid Idex). Previously I tried many different distributions (Debian, Fedora, SuSE etc.). I chose Ubuntu because it is easy to use and after installation, I have fully functional system. I like that after Ubuntu is installed, there are no duplicate applications and those already installed work perfectly with the system.

2) How long have you been working on the Clock and Calculator? How did you get involved in these projects?

I started to develop for Ubuntu about two years ago when I first heard about Ubuntu Touch and convergence. I started by contributing to Ubuntu Core Apps by testing, submitting bug reports and patches. Most commits were done for Ubuntu Calculator and Ubuntu Clock by fixing bugs which were approved by Riccardo Padovani, Mihir Soni and Nekhelesh Ramananthan. After some time, I became member of Ubuntu Core Apps. It’s very fun to work with these guys and the Ubuntu community. I’ve learned a lot about Qt/QML and user experience design.

3) How do you approach implementing a design in your apps?

Generally I follow the design document during implementation and sometimes find parts that need to be improved. After speaking with the Ubuntu UX team, we discuss various issues and agree on a final design solution. Sometimes the UX team gives us freehand, so we could design some parts by ourselves (eg. Stopwatch, Welcome Wizard, Landscape View). It’s really fun to work with such awesome guys.

4) What feature would you like to see in the future?

I think from user perspective, longer battery life is a very important topic. The power usage is higher with white background: especially with OLED screen. I wish that Ubuntu Touch came with a darker theme, to save battery on OLED screens.

Read more
Robin Winslow

It’s becoming more and more important for websites to carefully consider how their resources are cached in users’ browsers. Get the caching wrong, and you either end up with a woefully slow experience for the user, or a very strange looking website as users are left with stale CSS files and images.

Or often both.

For our China site, we’ve decided that the HTML pages should be cached for 5 minutes, and the CSS and JavaScript can be cached for a year – as every time we update them we change the URL.

Caching headers in Django

Telling the browser how long to cache a resource is done with one of two headers:

  • Cache-Control: In HTTP/1.1, this can set the maximum age before a resource should be re-downloaded.
  • Expires: In the older HTTP/1.0 standard, this sets the date and time that a resource becomes outdated and should be refreshed.

To control these headers in Django is less simple than you might think. If you’re happy to use the cache framework then it will take care of these headers for you, but as we have a separate Squid cache in front of our application, this was a more heavyweight solution than we needed.

Modifying HTML responses using View classes

In our case, all of our HTML pages are served with an extended version of the TemplateView class:

To add headers, we need to modify the HTTPResponse, which we can intercept by extending the render_to_response method.

Django also provides patch_response_headers a handy helper function to generate our caching headers for us and attach them to the response:

And now we can see our extra caching headers in the HTTP response:

Browsers and proxies will now cache the HTML pages for 5 minutes.

Controlling caching for static files

Django recommends serving static files separately from the rest of your application.

However, for simplicity and dev-prod parity we’ve been using DJ-Static to serve static files with the Django WSGI app, as introduced by Kenneth Reitz. This was also, at the time we implemented it, the method recommended by Heroku for managing static files in Django.

However, as it turns out DJ-Static doesn’t offer any control over caching headers. And Heroku now recommend using WhiteNoise instead.

Serving static files with WhiteNoise is pretty simple (as it was with DJ-Static):

WhiteNoise will add a Cache-Control header, although it doesn’t support set the older Expires header. By default, the Cache-Control header is initially set to no caching:

We wanted our static files to be cached for a year, so we set the WHITENOISE_MAX_AGE setting in

This will set the max-age in the Cache-Control header to achieve the browser caching we’re looking for:

Now we have control

Leveraging browser caching is an invaluable tool in performance, and so understanding how we can control the user’s cache with Django is very helpful.

Hopefully I’ve demonstrated some ways that this can be achieved, which we’ve just implemented on

Also published on my blog.

Read more
Jouni Helminen

Visual design of convergent apps

It is an exciting time as we’re starting to see more and more of the new, convergence-enabled UI toolkit and features for Unity 8 come to life. Some classic X11 apps (Gimp, Libre Office and a few others) are already running on Unity 8 using new hardware from our partners, including the award winning M10 tablet from BQ – very cool.

At the same time, we want to help people write or port more applications to our platform, using our modern UI toolkit designed to smoothly flow the user experience through touch and pointer inputs, a range of screen and keyboard types and all of the permutations in between! It has been an interesting design challenge to imagine, design, and begin to build a world where all interfaces, regardless of input type or form factor, all emerge from the same core user experience and design language.

Where we are now

Our UX and SDK teams have been working on version 1.3 of Qt based UI toolkit, which allows developers to write applications that can be used comfortably with both touch and pointer interfaces. The work is still very much in progress, but some of it can be used today. You can check out the developer docs here.

Suru, our visual design language, has evolved into a new, much lighter, flatter and modern approach. It not only looks great (in our humble opinion), but helps app developers design good looking and well-functioning apps with less effort. Continuous visual and user experience refinements will will be rolling out across the whole OS (scopes, shell and apps) this coming year.

The new design guidelines for UX and UI patterns as well as Suru will be out soon. In the meanwhile hopefully these example apps will inspire you to have a look at the developer docs, get active on IRC and have a go yourself. We will also be releasing design source files and templates for the refreshed UI toolkit so that you can start applying them in your own app designs.

Dekko – Email


The first example app is Dekko – the default email client  for mobile and tablet devices from BQ and Meizu. We have been very lucky to have the incredible talents of our community member Dan Chapman working on the development of Dekko, and the app is progressing at a fantastic rate. James Mulholland helped Dan with the UX and I have been working on the UI.

Like many apps, Dekko uses a list view to represent the primary level, and a detail view to show the secondary level. Where there’s room, these views can be displayed side by side, but on small screen screens or very shrunk windows, a PageStack showing only the list becomes the primary screen. On larger screens or expanded windows, the page stack automatically progresses into the familiar two-panel configuration. This adaptive layout is common on responsive websites, and our SDK team have built a component in the UI toolkit that does most of the hard work for you – AdaptivePageLayout.


The list item, which lives in the list component, is another example of ready made component that helps developers write convergent apps with less effort. The new ListItem in our toolkit has useful, well designed default layouts baked in when using ListItemLayout. It is also optimised for both touch and pointer interaction – via ListItemActions. A common pattern of interacting with list items on touch devices is to drag them left or right revealing key actions such as delete. When using a pointer, however, you would typically right click and use the contextual menu to access the same actions. Our UI Toolkit supports both types of input at all times, so you could drag the item left or right using a mobile or touch-enabled monitor, or right click using a mouse. We believe users should be free to mix how they interact with our components using whatever means is at their disposal and to their liking.

This behaviour is already baked into our ListItem component, so users will have a consistent experience when using apps, and developers will save time not having to roll their own solutions.


The music app is another example of the super talented Ubuntu community getting involved in building some of our core apps together with our internal teams. You might remember Andrew Hayzen and Victor Thompson from a previous interview on this blog. They have since been adding features and functionality to the app, and a convergent music app using multiple panels is currently working in a branch and will be landing in the master release soon. We are also looking at adding support for streaming music functionality, keep an eye out for this in the near future :)


The multi-panel music app reacts to window size changes intelligently – the album cards resize and shuffle themselves on window size changes. On smaller screen devices we have a persistent “Now playing” control bar at the bottom of the screen, but on larger screen sizes we have enough real estate to reimagine the play bar as an extra panel on the right with “Now playing” information, along with cover art, controls and a scrollable queue.



The calendar app has been on the phone for a while but until now it hadn’t really had any UI design love or designs for larger screens.  We wanted to apply our visual language in the context of an app that is by default very minimal, allowing the few design elements to stand on their own.

Suru, our visual language, is light and flat, minimizing distractions, with carefully selected tones of gray, consistent spacing and margins to help the content breathe. We’ve added considered splashes of highlight colours that enhance the visual hierarchy without overwhelming it.

On the calendar app we are again making use of multiple panels, surfacing several layers when we have the real estate available. The same feature set of the app is of course available on all sizes, and the navigation feels intuitive with whatever input method or screen size you are using.


This design hasn’t been implemented yet, and in fact we are looking for new developers to join our Community Team. If you are a developer who would like to get involved in writing some of the core apps people use on Ubuntu – get in touch with – we would love to hear from you!

Hopefully these examples have given inspiration and pointers to anyone who would like to have a go at designing apps for convergent Ubuntu. If you have any questions, don’t hesitate to reach out –


Read more
Steph Wilson

MWC stand: open for business

Take a look at the final pictures of the stand taken yesterday before we opened for business today!

Pods at MWC

Phone demo pods ready to be played with :)

Entrance to stand MWC

Entrance to the stand  “Phone + OpenStack + NFV + IoT”

Canonical meeting room MWC

The Canonical meeting room

Read more
Steph Wilson

With MWC just two days away, the final preparations are now in full swing. The stand is looking bigger and brighter than ever and we cannot wait to share it with you.

Final preperations: MWC


Final prep: MWC


Read more
Steph Wilson

It’s day 3 and the stand is nearing completion. The funky lights have been fitted, the meeting rooms have curvaceous walls inspired by the Ubuntu shape, and the cloud and phone demo pods are ready to rock some products for you to try.

Stay tuned tomorrow for some final pictures of behind the scenes at MWC!


One of the meeting rooms




Rectangular demo pods that will feature various cloud products

Read more
Steph Wilson

It’s day two behind the scenes at MWC and the stand is starting to take shape. The iconic orange Ubuntu flags are up, the walls and doors have been assembled, and the flooring has been put down. We are nearly there…

Day 2: MWC


Day 2: MWC

Day 2: MWC

Stay tuned tomorrow to see our final preparations for the stand.

Read more
Steph Wilson

With Mobile World Congress just around the corner, work has now commenced on our biggest stand to date!

Over the next week we will be posting pictures of the stand so you can see how it all comes together.

Day one:

Day 1 MWC

This year we are in the Main Hall – taking up more space :)

Day 1 MWC

Day 1 MWC

The flags are up!

Stay tuned for more pictures of the stand tomorrow


Read more
Inayaili de León Persson

A new look for tablet

Today we launched a new and redesigned tablet section on that introduces all the cool features of the upcoming BQ Aquaris M10 Ubuntu Edition tablet.

Breaking out of the box

In this redesign, we have broken out of the box, removing the container that previously held the content of the pages. This makes each page feel more spacious, giving the text and the images plenty of room to shine.

This is something we’ve wanted to do for a while across the entire site, so we thought that having the beautiful, large tablet photos to work with gave us a good excuse to try out this new approach.


The overview page of the tablet section of, before (left) and after


For most of the section, we’ve used existing patterns from our design framework, but the removal of the container box allowed us to play with how the images behave across different screen sizes. You will notice that if you look at the tablet pages on a medium to small screen, some of the images will be cropped by the edge of the viewport, but if you see the same image in a large screen, you can see it in its entirety.


From the top: the same row on a large, medium and small screen


How we did it

This project was a concerted effort across the design, marketing, and product management teams.

To understand the key goals for this redesign, we collected the requirements and messaging from the key stakeholders of the project. We then translated all this information into wireframes that guide the reader through what Ubuntu Tablet is. These went through a few rounds of testing and iteration with both users and stakeholders. Finally, we worked with a copywriter to refine the words of each section of the tablet pages.


Some of the wireframes


To design the pages, we started with exploring the flow of each page in large and small screens in flat mockups, which were quickly built into a fully functioning prototype that we could keep experimenting and testing on.


Some of the flat mockups created for the redesign


This design process, where we start with flat mockups and move swiftly into a real prototype, is how we design and develop most of our projects, and it is made easier by the existence of a flexible framework and design patterns, that we use (and sometimes break!) as needed.


Testing the new tablet section on real devices


To showcase the beautiful tablet screen designs on the new BQ tablet, we coordinated with professional photographers to deliver the stunning images of the real device that you can enjoy along every new page of the section.


One of the many beautiful device photos used across the new tablet section of


Many people were involved in this project, making it possible to deliver a redesign that looks great, and is completed on time — which is always good a thing :)

In the future

In the near future, we want to remove the container box from the other sections of, although you may see this change being done gradually, section by section, rather than all in one go. We will also be looking at redesigning our navigation, so lots to look forward to.

Now go experience tablet for yourself and let us know what you think!

Read more
Joseph Williams

Embeddable cards for Juju

Juju is a cloud orchestration tool with a lot of unique terminology. This is not so much of a problem when discussing or explaining terms or features within the site or the GUI, but, when it comes to external sources, the context is sometimes lost and everything can start to get a little confusing.

So a project was started to create embeddable widgets of information to not only give context to blog posts mentioning features of Juju, but also to help user adoption by providing direct access to the information on

This project was started by Anthony Dillon, one of the developers, to create embeddable information cards for three topics in particular. Charms, bundles and user profiles. These cards would function similarly to embedded YouTube videos, or embedding a song from Soundcloud on your own site as seen bellow:



Multiple breakpoints of the cards were established (small, 300px and below. medium: 301px to 625px and large: 626px and up) so that they would work responsively and therefore work in a breadth of different situations and compliment the user’s content referring to a charm, bundle or a user profile without any additional effort for the user.

We started the process by determining what information we would want to include within the card and then refining that information as we went through the different breakpoints. Here are some of the initial ideas that we put together:

charm  bundle  profile

We wrote down all the information there could be related to each type of card and then discussed how that might carry down to smaller card sizes and removed the unnecessary information as we went through the process. For the profile cards, we felt there was not enough information to display a profile card above 625px break point so we limited the card to the medium size.

Just enter the bundle or the charm name and the card will be generated for you to copy the code snippet to embed into your own content.

embed card thing

You can create your own here:

Below are some examples of the responsive cards are different widths:


Read more
Barry McGee

Maybe, like me, you seen more of the inside of your gym in January than you had for the six months previous. New year, new diet, new me.. or something like that.

A big creeping problem in recent years is that websites have been on an all out binge, and not just over the winter holidays — big videos, big images, fancy fonts, third-party libraries — they just can’t get enough of ’em.

Average page weights increased by 15% in 2014 and although I haven’t yet seen any similar research done for 2015 yet, I’m willing to bet that trend did not reverse.

Last week I was tasked with making some performance optimisations to the Ubuntu online tour.

This legacy codebase stretches all the way back to 2012, and as such was not benefitting from some of the modern tools we now have at our disposal as web developers.

We have been maintaining our largest codebases such as and to ensure they are as performant as they can be but this Ubuntu tour repository slipped through the cracks somewhat.

We have users all over the world and many of them don’t enjoy the luxury of fat internet pipes that we enjoy in our London office. Time to trim the fat…

At first look, I noted on load of the site it required 235 HTTP requests to download 2.7MB of data. Chunky Charlie!


Network waterfall screenshot


Delving into the codebase, I immediately spotted some big areas ripe for improvement:

  • The CSS files were not being concatenated nor were they minified.
  • The Javascript was also being loaded in separate files, also un-minified.
  • The image assets were uncompressed.
  • The HTML was un-minified.

Beyond that – I ran the site URL through Google’s PageSpeed Insights and also discovered;

  • Browser cacheing was not being being leveraged as static assets did not have any Expires headers specified
  • There were quite a few CSS and javascript dependancies blocking rendering of the page.

As you see, the site was only scoring a lowly 46/100, not great.


Google Page Speed Insights screenshot


For jobs such as this, my first weapon of choice is the task runner, Gulp. It’s quick and easy to drop Gulp on top of any existing site and use some of it’s wide array of plugins to optimise source assets for performance.

For this job I used gulp-concat, gulp-htmlmin, gulp-imagemin, gulp-minify-css, gulp-renamegulp-uglify, gulp with critical & gulp-rev.

Explaining how to use each of them is beyond the scope of this article but you can view my Gulpfile.js and accompanying package.json file to see what I did.

When retro-optimising a site, you might find you have to make certain compromises such as placing “src” folders inside folders you are optimising to store the original documents, then output the optimised versions into the original folder to ensure everything is backwards compatible and you haven’t broken any relative links. You should also be careful when globbing Javascript files as they may need to be loaded in a certain order to prevent race conditions. This is also true when concatenating and including Javascript libraries such as jQuery.

In an ideal world, you would not deploy any files from the repository you have compiled locally. They should be ignored by version control and compiled on the fly by running your task runner on the server using a continuous integration engine such as Jenkins or Travis CI. This is much cleaner and will prevent merge conflicts when multiple developers are working on the same codebase.

So — when we have all of the above configured and then run it over our legacy codebase, how much weight did it shave?


Network Waterfall - After


Good news! Now to load the site, we only need 166 HTTP (-29%) requests to download 2.2MB(-18%) of data. Slim(mer) Jim for the win!

This should mean our users with slower connections will have a much improved experience.

When we run the leaner site now deployed through Google Pagespeed Insights – we now get a much healthier score also.


Google Pagespeed - After


This was a valuable exercise for our team and reminded us we not only have a responsibility to keep all our new and upcoming work performant but we should also address any legacy sites still currently in use wherever possible.

A leaner web is a faster web and I’m sure that’s something we can all get behind.


Read more
Alejandra Obregon

Designing cloud tools in Cape Town

Our cloud design team has just returned from a trip to Cape Town for our mid-cycle sprint. We have the luxury of being collocated in London and working closely throughout the whole year, but these sprints give us an invaluable opportunity to collaborate with other stakeholders and engineers working around the world. We get together to define priorities and review progress on our goals for this cycle.

We can showcase upcoming features and designs and get feedback from a variety of sources.

This time we also heard from cloud architects who are building data centres with the products we design. It gave us an insight into how our products are being received in the field – what is working well in reality, what we need to do more of.

The week mainly involves lots of talking, drawing, presenting and discussing topics and we work to a tight schedule.

But we also get a chance to socialise and get to know people we work with in different time zones, which I think is just as valuable as the working bit.

At the end of the week we plan in detail for the next few weeks based on the outcomes of our conversations.

It’s an exciting time to be at Canonical. A new version of our provisioning product MAAS has just been released and it’s a huge evolution and something we’re very proud of.

The new Juju GUI just went live today! It has a completely revamped interface to make it easier to build and manage your cloud applications and services.

Our Autopilot tool for building OpenStack clouds will have a really nice set of new options in our next release.

Below are some photos of our week in Cape Town. I’m looking forward to our next Ubuntu release in April and the evolution of the cloud tools that come with it.

If you’d like to join the fun, get in touch, we’re hiring!


Read more
Rae Shambrook

In the coming months, users will start noticing things looking more and more different on Ubuntu. As we gradually roll out our new and improved Suru visual language, you’ll see apps and various other bits of the platform take on a lighter, more clean and cohesive look.

Why refresh apps at all?

As Ubuntu brings convergence to life—embracing today’s as well as future devices—our visual style and UI Toolkit need to evolve to support the new world. The changes taking place platform-wide make it simpler for designers and developers to integrate convergence from inception, and help apps come to life equally on mobile or desktop without a lot of additional work. As we apply new convergence UI and UX patterns to general-purpose components like lists and checkboxes, we also seek out opportunities to work with community developers and designers to put the thinking and new components into practice. The Clock app has been one such opportunity.



The Redesign

Our clean, crisp and lucid Suru visual language and style works well with the added functionality required for convergence. There’s less visual distraction and noise than ever, providing a clear pathway to making the most of the new toolkit’s convergence functionality.

Our Suru visual design language is based on origami, with graphic elements containing meaningful folds and shadows to create the illusion of paper and draw focus to certain areas. Using the main clock face’s current animation (where the clock flips from analog to digital on touch) as inspiration, it seemed natural to place a fold in the middle of the clock. On touch, the clock “folds” from analog to digital.


To further the paper look, drop shadows are used to give the illusion of layers of paper. The shadow under the clock face elevates it from the page, adding a second layer. The drop shadows on the clock hands add yet another layer.

As for colours, the last clock design featured a grey and purple scheme. In our new design, we make use of our very soon-to-be released new color palette. We brightened the interface with a white background and light grey clock face. On the analog clock, the hour and second hands are now Ubuntu orange. With the lighter UI, this subtle use of branding is allowed to stand out more. Also, the purple text is gone in favor of a more readable dark grey.

The bottom edge hint has also been redesigned. The new design is much more minimal, letting users get used to the gesture without interrupting the content too much.

In the stopwatch section, the fold is absent from the clock face since the element is static. We also utilize our new button styling. In keeping with the origami theme, the buttons now have a subtle drop shadow rather than an inward shadow, to again create a more “paper” feel.


This project has been one of my favorites so far. Although it wasn’t a complete redesign (the functionality remains the same) it was fun seeing how the clock would evolve next. Hope you enjoy the new version of the clock, it’s currently in development so look out for it on your phones soon and stay tuned for more visual changes.

Visual Design: Rae Shambrook

UX Design: James Mulholland


Read more

We arrived in Helsinki on Sunday evening, ready to start our week long SDK sprint on Monday. Our hotel was in a nice location, by the sea.

The work stuff

The SDK is a core part of Ubuntu and provides an array of components and flexibility needed to create applications across staged and windowed form factors, with good design and user experience in mind.

The purpose of the sprint was to have the designers and engineers come together to work on tools and components such as palette themes, bottom edge, header, scrollbars, focus handling, dialogs, buttons, menus, text selections and developer tasks such as IDE, packaging and application startup.

Monday morning started with walking into our venue that looked somewhat like a classroom.



The first task of the day required some physical activity of moving all the tables around so that the environment was much more conducive to a collaborative sprint.

Jouni presenting

Each day we broke off into working groups for our respective sessions and ironed out any existing issues, as well as working through new and exciting features that would enhance different SDK components.

Theme palette sessionJamie, Pierre and Zsombor working hard on the colour palette.

Jamie the professor

Old school pointing devices, Jamie gives it a go, looking very much like a professor!

What we achieved

During the course of the week we achieved what we’d set out to do:

  • Amended the theme palette to include any missing colours and then apply these to various components
  • Completed the implementation and release the bottom edge component into the staging environment
  • Completed the section scrolling prototype and have it reviewed by visual design and UX
  • Completed the portrait and landscape edit mode header prototype
  • Worked out behaviour of complex SDK components for focus handling and added some best practice examples to the specification
  • Communicated and gained concensus on the context menu design, who are now gearing up for some pre-requisite work and then implementation of context menus
  • Prepared the visual rules for buttons and made the Ubuntu shape ready to use for buttons
  • Completed the design for sliders  
  • Discussed a tree view component for navigation
  • Created a first draft of tabs wireframes and functionality agreed
  • Created a first draft of text selections visuals and reviewed, UX and functionality was discussed ready to include in the specification
  • Created the Libertine packaging project and containers
  • Tidied up the IDE
  • Created some Snapp packages and got them working
  • Ramped up some new  investigative work that arose in our collaboration

The planets aligned… literally

In the early hours of Wednesday morning  (before breakfast) a few of us managed to witnessed a planetary conjunction (Venus, Mars and Jupiter) which was truly amazing… a surprise benefit of sprinting in the arctic circle.
Even though there were a few hours of daylight, we managed to embrace the cold and stand outside to enjoy the beautiful views during lunch and coffee breaks.

The bay

All in all, it was a very productive and fun sprint. We left with a sense of accomplishment and camaraderie.

Read more