The Yakkety Yak 16.10 release animal artwork is now available to download here.
16.10 release animal
Initial design exploration
Design development – head detail
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.
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.
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.
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.
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.
Options for how the logotype/wordmark is presented:
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.
Design exploration using the Circle of Friends – in its entirety and stripped down.
How the logotype and roundel design sit together.
Full sets of Core and Ubuntu Core logo artwork are now available at design.ubuntu.com/downloads.Read more
The main goals of the sprint were to review the work that had been done in the past 6 months, and plan for the following cycle.
Landscape is a totally distributed team, so having regular face-to-face time throughout the year is important in order to maintain team spirit and a sense of connection.
It is also important for us, from the design team, to meet in person the people that we have to work with every day, and that ultimately will implement the designs we create.
I thought it was interesting to hear the Landscape team discuss candidly about how the previous cycle went, what went well and what could have been improved, and how every team member’s opinion was heard and taken into consideration for the following cycle.
Landscape team discussing the previous cycle
Peter and I took some time aside to interview some of the developers in 1-2-1 sessions, so they could talk us through what they thought could be improved in Landscape, and what worked well. As we talked to them, I wrote down key ideas on post it notes and Peter wrote down more thorough notes on his laptop. At the end of the interviews, we collated the findings into a Trello board, to identify patterns and try to prioritise design improvements for the next cycle.
But the week was not all work!
Every day we went out for lunch (unlike most sprints which provide the usual hotel food). This allowed us to explore a little bit of the city and its great culinary offerings. It was a great way to get to know the Landscape team a little bit better outside of work.
Lots of great food in Vancouver
Vancouver also has really great coffee places, and, even though I’m more of a tea person, I made sure to go to a few of them during the week.
Nice Vancouver coffee
I took a few days off after the sprint, so had some time to explore Vancouver with my family. We even saw a TV show being filmed in one of our favourite coffee shops!
This was my first time in Canada, and I really enjoyed it: we had a great sprint and it was good to have some time to explore the city. Maybe I’ll be back some day!Read more
Recently I have been working on the visual design for RCS (which stands for rich communications service) group chat. While working on the “Group Info” screen, we found ourselves wondering what the best way to display an online/offline status. Some of us thought text would be more explicit but others thought it adds more noise to the screen. We decided that we needed some real data in order to make the best decision.
Usually our user testing is done by a designated Researcher but usually their plates are full and projects bigger, so I decided to make my first foray into user testing. I got some tips from designers who had more experience with user testing on our cloud team; Maria Vrachni, Carla Berkers and Luca Paulina.
I then set about finding my user testing group. I chose 5 people to start with because you can uncover up to 80% of usability issues from speaking to 5 people. I tried to recruit a range of people to test with and they were:
The tool I decided to use was Invision. It has a lot of good features and I already had some experience creating lightweight prototypes with it. I made four minimal prototypes where the group info screen had a mixture of dots vs text to represent online status and variations on placement. I then put these on my phone so my test subjects could interact with it and feel like they were looking at a full fledged app and have the same expectations.
During testing, I made sure not to ask my subjects any leading questions. I only asked them very broad questions like “Do you see everything you expect to on this page?” “Is anything unclear?” etc. When testing, it’s important not to lead the test subjects so they can be as objective as possible. Keeping this in mind, it was interesting to to see what the testers noticed and brought up on their own and what patterns arise.
My findings were as follows:
Online status: Text or Green Dot
Unanimously they all preferred online status to be depicted with colour and 4 out of 5 preferred the green dot rather than text because of its scannability.
Online status placement:
This one was close but having the green dot next to the avatar had the edge, again because of its scannability. One tester preferred the dot next to the arrow and another didn’t have a preference on placement.
What was also interesting is that three out of the four thought “pending” had the wrong placement. They felt it should have the same placement as online and offline status.
Overall, it was very interesting to collect real data to support our work and looking forward to the next time which will hopefully be bigger in scope.Read more
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:
-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)
-Adding a “find” action for searching the history
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.
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.
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.
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 firstname.lastname@example.org or email@example.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
Back in June we hosted a competition that asked developers to use the AdaptivePageLayout component from the UI toolkit to create an app that converges across devices. We had some very impressive entires that used the component in different ways; choosing a winner was hard. However, after testing all the apps the design team chose a winner: the Timer App.
The AdaptivePageLayout component eliminates guesswork for developers when adapting from one form factor to another. It works by tracking an infinite number of virtual columns that may be displayed on a screen at once. For example, an app will automatically switch between a 1-panel and 2-panel layout when the user changes the size of the window or surface, by dragging the app from the main stage to the side stage.
You can read more about convergence and how the adaptive page layout works in the App design guides.
The Timer app impressed the design team the most with its slick transitions, well thought-out design and ease of use. It used the AdaptivepageLayout well when it translated to different screens.
Thank you to all who participated in making their apps look even more slick. Here are the other entries:
2nd: AIDA64 App
3rd: Movie Time
4th: Ubuntu Hangups
To get involved in building apps, click here.Read more
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.
The process was as follows:
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.
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:
Let’s go through the modes in more detail.
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.
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.
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.
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.
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:
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:
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!
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
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.
Find guidance for utilizing components for effective and natural user journeys within your UI.
Use the Grid Unit System to help visualise how much space you have in order to create a consistent and proportionate UI.
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
Meet the newest member of the design team, UX designer Raul Alvarez, who will be working on the Ubuntu convergence story. Raul will be bringing new ideas to improve our apps to allow for a seamless experience across all devices. We caught up with him to tell us more about his background and what attracted him to the open source world of Ubuntu.
If we go all the way back to university, I started as a computer engineer student, but after a while I got to a point where I was rather burnt out by it. Then almost by chance, I ended up studying another degree in Advertising and PR. When studying my second degree I gained a fresh perspective. I was coming from studying maths and physics to then finding myself in classes for Spanish, history, law, and eventually design, which is where I got hooked.
I turned 30 and decided to move to London, as everyone in the small town of Salamanca (West Spain) was either getting married or bored; I was the latter. I wanted to challenge myself to do the most difficult things and push a bit more. I moved into designing Forex trading apps, which was a great experience with very smart people. I got to work very close with the developers too.
I then went into e-commerce as a designer, which was another diverse industry I wanted to learn from. Getting into something I know nothing about is key for me. It’s tricky, as people want experience, but once I’m there and I learn, I feel that I have the ability to take a fresh look at things. From studying advertising and knowing how apps are build I could bring those disciplines together to work on different platforms.
Canonical was a company I wanted to be part of. Just so happens they were looking for a designer, and now here I am!
In the late days of my computer engineering degree, me and some fellow students started our own business. It was when the Social Network movie was out and everyone wanted to be Mark Zuckerberg; and so did we. We created a photography social network that was like a Flickr wannabe, or closer to what 500px is now. We had good intentions and we worked very hard on it. However, we lacked the business vision and strategy to push it forward. We had two choices: we close it off and do something else, or we find a better way to make money.
Salamanca is a small town and has little going on, but it just so happened that a company was doing mobile apps on demand for clients. Instead of hiring more people when they had large spikes of work, they would reached out to other companies. My three partners were playing the role of developers and I was the designer. We spent four years designing mobile apps for various clients specific needs, most came from the advertising industry. We had some startups come to us who didn’t have much money and we would help them advertise and prototype their apps. It was always a rather constrained working environment with a low budget and working with trial and error.
For me, being here is amazing because I had been using a laptop that ran Ubuntu in my uni days. I’ve always known open source and the ideas around it. I remember playing with Linux when I was at high school too.
User Experience (laughs). But seriously, I think the term ‘UX’ is thrown back and forth a lot and people forget what it means. It’s a lot of ideas that could or could not be UX.
People might think that UX is just associated with apps and web design. But it’s not. If you think about user experience, it’s in everything. You can use user experience to build your hotel for instance. I could say how is the lobby going to be decorated, what is the uniform going to be like, do I want the guests to find a little chocolate under their pillow? THAT is defining the user experience. You don’t need to do a lot of research. Well, you can research user experience in other hotels, that would be one approach. Or you can say I have this vision I want to make my approach work. For this you need good judgement and to think about people, but also be prepared to take risks.
One of the parts I enjoy most about designing is whenever I don’t know what I’m going to do. That is the fun bit.
I came here thinking I knew how complex an operating system was. I wasn’t even close. I realised the complexity was way down below, every single little thing is taken into account, which amazes me. Then I realised the scale of the task. It’s amazing how much work is going on here. I have a lot of respect for it.
Making a decision like: I’m stuck and I need a change. I made the effort to move to a different country and to change my degree. It has always been very natural for me to take risks, but I didn’t realize how scary it actually is until I stop and think about it.Read more
Last week the design team had two interns undertaking their work experience at the London office.
Our first student is studying computer science for her GCSEs and has an interest in Python programming and software engineering. The second student is studying Geography and IT and had a general interest in IT.
We wanted them to experience what working in the design team is like, so we set them two tasks:
We asked them to keep a note of the key things that they had been doing and what they learned throughout the week.
They were then asked to create two paper versions of their posters, which were reviewed by one of our visual designers. After being reviewed, the designers helped the student to create a final electronic version, which they could take back to school with them.
We asked them to use the convergence tablet as their device during the week for user testing purposes.
We wanted them to:
We asked for feedback on:
They were expected to talk through their feedback for 15 minutes with two designers.
By the end of the week we wanted our interns to have the confidence to present their findings to us, as well as experience a review process with their poster designs.
The feedback we got from our first student – who used the tablet for 4 days, in between her other tasks – said: ‘ready, not a prototype, sleek and lightweight’. What she liked most about it was that ‘it can be a whole computer if you connect it’. She also liked the UbuntuStore.
The feedback we got back from our second student – who used the tablet in between tasks of making bootable USB drives and learning code – was that he ‘likes how it has the capability to … just pick it up and plug it into a monitor … Because it means that you don’t have to carry anything around, just a tablet.’
His favourite app was the Browser, he said ‘because it gives you access to everything’ and he thought it was ‘better than Safari because Safari blocks a lot of things like Flash’. He thought that the camera was of ‘good quality and focused quickly’ and felt it was easy to take photos and videos.
We also received suggestions on what they wished to see in the future and what they thought could be improved, which was great to see from the student demographic. We have captured all of this and can incorporate some of these ideas.
With the help of one of our visual designer’s, we reviewed our first student’s paper designs and helped bring her poster to life.
This poster was the fruits of her labour and she was then tasked with finishing it off at home, ready to take back to school with her.
Our London office really values the work our work experience interns undertake in the week they are here during the summer. Many of them tend to have interests in technology and our open source nature is a good way to give them a flavour of the Ubuntu design and engineering process.
If you’re a student and like what you’ve seen so far, and would like to undertake your work experience with us please do get in touch with Stefanie Davenoy – firstname.lastname@example.org.Read more
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:
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:
We’ve surfaced key categories and highlighted their most popular services:
The search stays the same for now, but we’re working on improvements which will be released in the near future:
You can explore bundles and view charm details:
And deploy your chosen charm, using the GUI or CLI:
Check it out at:https://jujucharms.com/store
We’ve summarised four of the most important stages of the project for you to get an insight into our design process.
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:
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:
Before making any design decisions we:
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.
We also undertook a competitor benchmarking project with the aim of:
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
We have been using our front end framework Vanilla across our sites for a while now, so it might surprise you to know that its first official version (let’s call it v1) hasn’t yet been released.
In preparation for v1 (which we are tentatively aiming for early September), there are a few tasks that we have been, and will be, working on to make sure that Vanilla is as robust as we can make it, and to make the process of using and improving it clear.
It’s important that long-term, ongoing projects have defined goals that people can focus on and strive for. Having short, mid and long-term goals makes it easier to prioritise and concentrate efforts on tasks that will get you closer to achieving the ultimate vision for the project.
The first thing we did in order to outline a roadmap for Vanilla was to collect all the things that we felt needed to happen for it to be ready for release, things we’d like to improve, and wishlist items that might not be urgent but that we would like to tackle at some point in the future.
With this list at hand, we organised the tasks by priority and added them to a roadmap board in Trello, which is open for anyone to have a look at. You can see which tasks we are working on during the current two-week sprint, and which tasks are queued to be done next.
Releasing Vanilla v1 does not mean that Vanilla will then be finished. As a working style guide that is used across Canonical on various different projects with different needs, new patterns will emerge and existing ones will have to be improved to be more flexible.
We thought that it would be good to document the process that a pattern should follow in order to become a Vanilla pattern, so after a little bit of brainstorming, we created a diagram that shows the different steps that should be taken from before submitting a pattern proposal to its full acceptance as a Vanilla pattern.
Most of the steps in the diagram happen in just a few seconds, but it is good to be able to visualise the entire process.
As Vanilla itself, this process diagram is not really finished. Once we start using it more frequently, we will probably have to make some adjustments to improve it. Also, there are a few branches of the process that we still need to include, namely how a pattern is added to a theme as opposed to the main Vanilla framework, and how an existing pattern (in a website of Vanilla theme) can be promoted to Vanilla.
As part of this task, we also updated the existing GitHub template that pops up when you submit a new issue on the Vanilla repository to include the option of submitting a pattern proposal.
The proposals will be reviewed on a fortnightly basis by the web team during the Vanilla working group meetings. We are pondering how we can make these meetings open to anyone who’d like to participate, as we know that lots of you would like to contribute with new patterns and improvements. We’d be happy to hear your ideas on how this could work.
While internally, in the web team, we tend to agree on and follow consistent browser support guidelines, the process isn’t documented.
We want to make sure that Vanilla is built following the latest web standards, and that people can build sites with it that will work on as many form factors as possible, so we thought defining the browser support guidelines that we want contributors to follow was a vital step in preparation for the v1 release.
The document isn’t yet finished, but we are working on it as we speak and will be sharing it soon enough.
You can see the roadmap that we have planned for Vanilla in preparation for v1 and after in Trello, but there are few key tasks that we want to carry out before September that we’d like to highlight:
This is all from me for now! Barry is writing a companion post that will go into more detail about the technical tasks that are being done on Vanilla, which he will be publishing soon.
We would love to know if you have any ideas on how to improve Vanilla — share your thoughts in the comments.Read more
One of my “official side projects” is the Go language driver for MongoDB, started a few years back while looking for a way to store data conveniently from the Go language while leaving aside some of the problems we have mapping code into table-based approaches.
Nowadays this is used in projects at Canonical, in the MongoDB tooling itself, and also in some of my own personal projects. For the personal server-side projects I’ve been using docker containers to conveniently deploy the database tooling, but this week when I went to update some of my older images pulled from the docker hub I found that the docker installed on that server was a bit too old, so it was time to update the servers.
But that got me wondering: what if I replaced all those containers by snaps? This would allow me to keep the convenience and safety of the isolation, while making a lot of things simpler. Unlike docker, snaps make the installed tooling more easily accessible to the host system (bins in the search path, processes as actual children from shell and systemd, etc), and can even use system resources directly assuming interfaces allow it (e.g. home files).
So I got into that, and perhaps ended up overdoing it a little bit. Based on my experience testing the driver, I really appreciate having all versions available for playing with, rather than just the latest one. This is how my local development system looks like right now:
$ snap list | grep 'Name\|mongo' Name Version Rev Developer Notes mongo22 2.2.7 1 niemeyer - mongo24 2.4.14 1 niemeyer - mongo26 2.6.12 1 niemeyer - mongo30 3.0.12 1 niemeyer - mongo32 3.2.7 1 niemeyer - mongo33 3.3.9 1 niemeyer -
These are backed by upstream tarballs (snapcraft downloaded them pre-built from mongodb.com), and are all installed, running, and with tooling available for playing with. They are also published to the snap store which means you can easily make use of them locally as well. If you want to do that, here is a crash course on snaps and on how I packaged the database together specifically.
If you’re using Ubuntu, update to release 16.04 which has snaps working out of the box. For other distributions have a look at snapcraft.io to see what command must be run for ensuring it is available.
Then, pick your version and install it. For example, if you want to play with the features just announced at MongoDB World this week, you want the unstable version 3.3.9:
$ snap install mongo33 93.59 MB / 93.59 MB [============================] 100.00 % 1.33 MB/s Name Version Rev Developer Notes mongo33 3.3.9 1 niemeyer -
After that you already have the tooling available in your path (assuming you have /snap/bin there), and the daemon started. So go ahead and fire the client to talk to the database:
$ mongo33 MongoDB shell version: 3.3.9 connecting to: 127.0.0.1:3317/test MongoDB server version: 3.3.9 Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user Server has startup warnings: (...) (...) ** NOTE: This is a development version (3.3.9) of MongoDB. (...) ** Not recommended for production. >
Note that the server started on the non-standard port 33017 to allow multiple versions to be running together. The pattern is that the snap mongoNN will run on port NN017.
The tools installed also follow a similar pattern. Where upstream uses
mongodump, etc, the snaps will have them under /snap/bin as mongo33, mongo33.d, mongo33.dump, and so on.
The systemd unit, if you want to interact with it for restarting, improving, debugging, etc, is named
snap.mongo33.mongod.service, as usual for any snap that contains a daemon (snap.<snap name>.<app name>.service).
The data for the process that runs under systemd lives in the the standard writable area that the confinement system opens up for snaps in general – in this specific case /var/snap/mongo33/common/. The common directory is reused untouched on updates across snap revisions, which implies snapd won’t copy the data over when doing such updates. This compromises slightly the update safety, but is worth it for bulk data that we don’t want to copy on every snap refresh.
So this ended up quite nicely. Next up is the Go server code itself, which will be packed as a snap too, for deploying it into the servers in a similar way. The exact details for how these snaps are being built are publicly available too.
If you want a hand doing something similar, we have some helpful people at #snappy on FreeNode and also email@example.com.Read more
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.
OFFF space in the Design Musem
OFFF 2016 book and program
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.”
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.
Joshua Davis design
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!
Last week I was invited to Beijing to take part in the China Launch Sprint. The focus of the sprint was to identify action items in our product roadmap for the next devices that will ship Ubuntu Touch in the Chinese market later this year.
I am a lead UX designer in the product strategy team currently doing many exciting things, such as designing the convergence experience across the Ubuntu platform. I was invited to offer design support and participate in the planning of the work we will be doing with our industry partner, China Mobile, after reviewing the CTA test results.
CTA stands for China type approval which is a certificate granted to a product that meets a set of regulatory, technical and safety requirements. Generally, type approval is required before a product is allowed to be sold in a particular country.
The sprint was very productive and a great experience to sync up with old and new faces. We were all excited to explore ideas and work together on the next steps for China Mobile and Ubuntu.
I had some downtime to explore the city and have a taste of Beijing’s most interesting local dishes and potions with people I met from the sprint…Read more
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
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.
Empty state of the canvas
Apache charm details
Mediawiki deployment with errors
Inspector home view
Inspector errors view
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.
As the Juju design team grew it was important to review our working process and to see if we could improve it to create a more agile working environment. The majority of employees at Canonical work distributed around the globe, for instance the Juju UI engineering team has employees from Tasmania to San Francisco. We also work on a product which is extremely technical and feedback is crucial to our velocity.
We identified the following aspects of our process which we wanted to improve:
I’ve always been interested in the concept of designing in the open. Benefits of the practice include being more transparent, faster and more efficient. They also give the design team more presence and visibility across the organisation. Kasia (Juju’s project manager) and I went back and forth on which products to use and eventually settled on GitHub (GH).
The Juju design team works in two week iterations and at the beginning of a new iteration we decided to set up a GH repo and trial the new process. We outlined the following rules to help us start:
As the iteration went on, feedback started rolling in from the engineering team without us requesting it. A few developers mentioned how cool it was to see how the design process unfolded. We also saw a lot of improvement in the Juju design team: it allowed us to collaborate more easily and it was much easier to keep track of what was happening.
At the end of the trial iteration, during our clinic day, we closed completed issues and uploaded the final assets to the “code” section of the repo, creating a single place for our files.
After the first successful iteration we decided to carry this on as a permanent part of our process. The full range of benefits of moving to GH are:
As a result of this change our designs are more accessible which allows developers and stakeholders to comment and collaborate with the design team aiding in our agile process. Below is an example thread where you can see how GH is used in the process. I shows how we designed the new contextual service block actions.
Meet the newest member of the Design Team, project manager Davide Casa. He will be working with the Platform Team to keep us all in check and working towards our goals. I sat down with him to discuss his background, what he thinks makes a good project manager and what his first week was like at Canonical (spoiler alert – he survived it).
You can read Davide’s blog here, and reach out to him on Github and Twitter with @davidedc.
My background is in Computer Science (I did a 5 year degree). I also studied for an MBA in London.
Computer science is a passion of mine. I like to keep up to date with latest trends and play with programming languages. However, I never got paid for it, so it’s more like a hobby now to scratch an artistic itch. I often get asked in interviews: “why aren’t you a coder then?” The simple answer is that it just didn’t happen. I got my first job as a business analyst, which then developed into project management.
I think the soft skills are incredibly relevant and crucial to the role. For example: gathering what the team’s previous experience of project management was, and what they expect from you, and how deeply and quickly you can change things.
Is project management perceived as a service or is there a practise of ‘thought leadership’?
In tech companies it varies. I’ve worked in Vodafone as a PM and you felt there was a possibility to practice a “thought leadership”, because it is such a huge company and things have to be dealt with in large cycles. Components and designs have to be agreed on in batches, because you can’t hand-wave your way through 100s of changes across a dozen mission-critical modules, it would be too risky. In some other companies less so. We’ll see how it works here.
Indeed one of the core values of Agile is “the team”. I think people underestimate the importance of cohesiveness in a team, e.g. how easy it is for people to step forward and make mistakes without fear. A cohesive team is something that is very precious and I think that’s a regularly underestimated. You can easily buy tools and licenses, which are “easy solutions” in a way. The PM should also help to improve the cohesiveness of a team, for example creating processes that people can rely on in order to avoid attrition, and resolve things. Also to avoid treating everything like a special case to help deal with things “proportionally”.
I like coding, and to be good coder, one must read good code. With open source the first thing you do is look around to see what others are doing and then you start to tinker with it. It has almost never been relevant for me to release software without source.
I dabble in livecoding, which is an exotic niche of people that do live visuals and sounds with code (see our post on Qtday 2016). I am also part of the Toplap collective which works a lot on those lines too.
I also dabble in creating an exotic desktop system that runs on the web. It’s inspired by the Squeak environment, where everything is an object and is modifiable and inspectable directly within the live system. Everything is draggable, droppable and composable. For example, for a menu pops up you can change any button, both the labelling or the function it performs, or take apart any button and put it anywhere else on the desktop or in any open window. It all happens via “direct manipulation”. Imagine a paint application where at any time while working you can “open” any button from the toolbar and change what the actual painting operation does (John Maeda made such a paint app actually).
The very first desktop systems all worked that way. There was no concept of a big app or “compile and run again”. Something like a text editor app would just be a text box providing functions. The functions are then embodied in buttons and stuck around the textbox, and voila, then you have your very own flavour of text editor brought to life. Also in these live systems most operations are orthogonal: you can assume you can rotate images, right? Hence by the same token you can rotate anything on the screen. A whole window for example, or text. Two rotating lines and a few labels become a clock. The user can combine simple widgets together to make their own apps on the fly!
I learned a lot and I suspect that will never stop. The bread and butter here is strategy and design, which in other companies is only just a small area of work. Here it is the core of everything! So it’ll be interesting to see how this ‘strategy’ works. And how the big thinking starts with the visuals or UX in mind, and from that how it steers the whole platform. An exciting example of this can be seen in the Ubuntu Convergence story.
That’s the essence of open source I guess…
Indeed. And the fact that anti-features such as DRM, banners, bloatware, compulsory registrations and basic compilers that need 4GB of installation never live long in it. It’s our desktop after all, is it not?Read more
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.