Canonical Voices

Posts tagged with 'development'

Anthony Dillon

table.highlight { margin-bottom: 0; } table.highlight td { text-align: left; font-size: 0.8em; line-height: 1.6; border: 0; }

This post is part of the series ‘Making ubuntu.com responsive‘.

The JavaScript used on ubuntu.com is very light. We limit its use to small functional elements of the web style guide, which act to enhance the user experience but are never required to deliver the content the user is there to consume.

At Canonical we use YUI as our JavaScript framework of choice. We have many years of using it for our websites and web apps therefore have a large knowledge base to fall back on. We have a single core.js which contains a number of functions called on when required.

Below I will discuss some of the functions and workarounds we have provided in the web style guide.

Providing fallbacks

When considering our transition from PNGs to SVGs across the site, we provided a fallback for background images with Modernizr and reset the background image with the .no-svg class on the body. Our approached to a fallback replacement in markup images was a JavaScript snippet from CSS Tricks – SVG Fallbacks, which I converted to YUI:

The snippet above checks if Modernizr exists in the namespace. It then interrogates the Modernizr object for SVG support. If the browser does not support SVGs we loop through each image with .svg contained in the src and replace the src with the same path and filename but a .png version. This means all SVGs need to have a PNG version at the same location.

Navigation and fallback

The mobile navigation on ubuntu.com uses JavaScript to toggle the menu open and closed. We decided to use JavaScript because it’s well supported. We explored using :target as a pure CSS solution, but this selector isn’t supported in Internet Explorer 7, which represented a fair chunk of our visitors.

mobile-open-navThe navigation on ubuntu.com, in small screens.

For browsers that don’t support JavaScript we resort to displaying the “burger” icon, which acts as an in-page anchor to the footer which contains the site navigation.

Equal height

As part of the guidelines project we needed a way of setting a number of elements to the same height. We would love to use the flexbox to do this but the browser support is not there yet. Therefore we developed a small JavaScript solution:

This function finds all elements with an .equal-height class. We then look for child divs or lis and measure the tallest one. Then set all these children to the highest value.

Using combined YUI

One of the obstacles discovered when working on this project was that YUI will load modules from an http (non secure) domain as the library requires. This of course causes issues on any site that is hosted on a secure domain. We definitely didn’t want to restrict the use of the web style guide to non secure sites, therefore we need combine all required modules into a combined YUI file.

To combine your own YUI visit YUI configurator. Add the modules you require and copy the code from the Output Console panel into your own hosted file.

Final thoughts

Obviously we had a fairly easy time of making our JavaScript responsive as we only use the minimum required as a general principle on our site. But using integrating tools like Modernizr into our workflow and keeping top of CSS browser support, we can keep what we do lean and current.

Read the next post in this series: “Making ubuntu.com responsive: testing on multiple devices”

Reading list

Read more
Anthony Dillon

This post is part of the series ‘Making ubuntu.com responsive‘.

Performance has always been one of the top priorities when it came to building the responsive ubuntu.com. We started with a list of performance snags and worked to improve each one as much as possible in the time we had. Here is a quick run through of the points we collected and the way we managed to improve them.

Asset caching

We now have a number of websites using our web style guide. Because of this, we needed to deliver assets on both http and secure https domains. We decided to build an asset server to support the guidelines and other sites that require asset hosting.

This gave us the ability to increase the far future expires (FFE) of each file. By doing so the file is cached by the server and not resupplied. This gives us a much faster round trip speed. But as we are still able to update a single file we cannot set the FFE too far in the future. We plan to resolve this with a new and improved assets system, which is currently under development.

The new asset system will have a internal frontend to upload a binary file. This will provide a link to the asset with a 6 character hexadecimal attached to the file name.

/ho686yst/favicon.ico

The new system restricts the ability to edit or update a file. Only upload a new one and change the link in the markup. This guarantees the asset to stay the same forever.

Minification and concatenation

We introduced a minification and concatenation step to the build of the web style guide. This saves precious bytes and reduces the number of requests performed by each page.

We use the sass ruby gem to generate minified and concatenated CSS in production. We also run the small amount of JavaScript we have through UglifyJS before delivering to production.

Compressed images

Images were the main issue when it came to performance.

We had a look at the file sizes of some of our key images (like the ones in the tablet section of the site) and were shocked to discover we hadn’t been treating our visitors’ bandwidth kindly.

After analysing a handful of images, we decided to have a look into our assets folder and flag the images that were over 100 KB as a first go.

One of the largest time consuming jobs in this project was converting all images that could to SVGs. This meant creating pictograms and illustrations as vectors from earlier PNGs. Any images that could not be recreated as a vector graphic were heavy compressed. This squeezed an alarming amount out of the original file.

We continued this for every image on the site. By doing so the total reduction across the site was 7.712MB.

Reduce required fonts

We currently load a large selection of the Ubuntu font.

<link href='//fonts.googleapis.com/css?family=Ubuntu:400,300,300italic,400italic,700,700italic%7CUbuntu+Mono' rel='stylesheet' type='text/css' />

The designers are exploring the patterns of the present and ideal future to discover unneeded types. Since the move from normal font weight to light a few months ago as our base font style, we rarely use the bold weight (700) anymore, resorting to normal (400) for highlighting text.

Once we determine which weights we can drop, we will be able to make significant savings, as seen below:

google-fonts-beforeandafterReducing loaded fonts: before and after

Using SVG

Taking the leap to SVGs over PNG caused a number of issues. We decided to load SVGs as opposed to inline SVGs to keep our markup clean and easy to read and update. This meant we needed to provide four different coloured images for each pictogram.

pictopack-smiles

We introduced Modernizr to give us an easy way to detect browsers that do not support SVGs and replace the image with PNGs of the same path and name.

Remove unnecessary enhancements

We explored a parallaxing effect for our site’s background with JavaScript. With worked well on normal resolution screens but lagged on retina displays, so we decided not do it and set the background position to static instead — user experience is always paramount and trumps visual enhancements.

Future improvements

One of the things in our roadmap is to remove unused styles remaining in the stylesheets. There are a number of solutions for this such as grunt-uncss.

Conclusion

There is still a lot to do but we have definitely broken the back of the work to steer ubuntu.com in the right direction. The aim is to push the site up to 90+ in the speed page tests in the next wave of updates.

Read the next post in this series: “Making ubuntu.com responsive: JavaScript considerations”

Reading list

Read more
Anthony Dillon

This post is part of the series ‘Making ubuntu.com responsive‘.

When working to make the current web style guide responsive, we made some large updates to the core Sass. We decided to update the file and folder structure of our styles. I love reading about other people or organisations Sass architectures, so I thought it would be only right to share the structure that has evolved over time here at Canonical.

Let’s get right to it.

  • core.scss
  • core-constants.scss
  • core-grid.scss
  • core-mixins.scss
  • core-print.scss
  • core-templates.scss
  • patterns
    • patterns.scss
    • _arrows.scss
    • _blockquotes.scss
    • _boxes.scss
    • _buttons.scss
    • _contextual-footer.scss
    • _footer.scss
    • _forms.scss
    • _header.scss
    • _helpers.scss
    • _image-centered.scss
    • _inline-logos.scss
    • _lists.scss
    • _notifications.scss
    • _resource.scss
    • _rows.scss
    • _slider.scss
    • _structure.scss
    • _tabbed-content.scss
    • _tooltips.scss
    • _typography.scss
    • _vertical-divider.scss

I won’t describe each file as some are self-explanatory but let’s just go through the core files to understand the structure.

core.scss contains the core HTML element styling. Such as img, p, ul, etc. You could say this acts as a reset file customised to match our style.

core-constants.scss is home to all variables used throughout. This file contains all the set colours used on the site. Base font size and some extra grid variables used to extend the layout.

core-grid.scss holds the entire responsive grid styles. This file mainly consists of generated code from Gridinator which we extended with breakpoints to modify the layout as the viewport gets smaller. You can read more about how we did this in “Making ubuntu.com responsive: making our grid responsive”.

core-mixins.scss holds all the mixins used in our Sass.

core-templates.scss is used to hold full pages styling classes. Without applying a template class to the <body> of a page you get a standard page style, if you add a template class, you will get the styles that are appropriate for that template.

webteam frontend working on web style guideWeb team front end working on the web style guide.

Divide and conquer

Patterns were originally all in one huge scss file, which became difficult to maintain. So we decided to split the patterns file apart in a pattern folder. This allows us to find and work in a much more modular way. This involved manually working through the file. Removing all the components styles into a new file and import back into the same position.

Naming conventions

Our mission when setting up the naming convention for our CSS was to make the markup as human readable as possible.

We decided early on to almost use a object oriented, inheritance system for large structural elements. For example, the class .row can be extended by adding the .row-enterprise class which applies a dark aubergine background and modifies the elements inside to be display correctly on a dark background.

We switch to a single class approach for small modular components, such as lists. If you apply the class .list the list items are styled with our simple Ubuntu list style. This can be modified by changing the class to .list-ubuntu or .list-canonical, which apply their corresponding branding themed bullets to the items.

list-stylesList styles.

The decision to use different systems arose from the desire to keep the markup clean and easy to skim read by limiting the classes applied to each element. We could have continued with the inheritance system for smaller elements but that would have lead to two or more classes (.list and .list-canonical) for each element. We felt this was overkill for every small component. For large structural elements such as rows it’s easier to start with a .row class and have added functionality and styling by adding classes.

Mixins

We mainly use mixins to handle browser prefixes as we haven’t yet added a “prefixer” step to our build system.

A lot of our styles are quite specific and therefore would not benefit from being included as a mixin.

A note on Block, Element, Modifier syntax

We would like to have used the Block, Element, Modifier (BEM) syntax as we think it is a good convention and easy for people external to the project to understand and use. Since we started this project back in 2013 with the above syntax, which is now used on a number of sites across the Canonical/Ubuntu web real estate, the effort to convert every class name to follow the BEM naming convention would far outweigh the benefits it would return.

Conclusion

By splitting our bloated patterns file into multiple small modular files we have made it much easier to maintain and diagnose bugs within components. I would recommend anyone in a similar situation to find the time to split the components into separate files sooner rather then later. The effort grows exponentially the longer it’s left.

Introducing linting to the production of the guidelines will keep our coding style the same throughout the team and help readability to new members of the team.

Read the next post in this series: “Making ubuntu.com responsive: ensuring performance”

Reading list

Read more
Anthony Dillon

I was recently asked to attend a cloud sprint in San Francisco as a front-end developer for the new Juju GUI product. I had the pleasure of finally meeting the guys that I have collaboratively worked with and ultimately been helped by on the project.

Here is a collection of things I learnt during my week overseas.

Mocha testing

Mocha is a JavaScript test framework that tests asynchronously in a browser. Previously I found it difficult to imagine a use case when developing a site, but I now know that any interactive element of a site could benefit from Mocha testing.

This is by no means a full tutorial or features set of Mocha but my findings from a week with the UI engineering team.

Breakdown small elements of your app or website its logic test

If you take a system like a user’s login and register, it is much easier to test each function of the system. For example, if the user hits the signup button you should test the registration form is then visible to the user. Then work methodically through each step of the process, testing as many different inputs you can think of.

Saving your bacon

Testing undoubtedly slows down initial development but catches a lot of mistakes and flaws in the system before anything lands in the main code base. It also means if a test fails you don’t have to manually check each test again by hand — you simply run the test suite and see the ticks roll in.

Speeds up bug squashing

Bug fixing becomes easier to the reporter and the developer. If the reporter submits a test that fails due to a bug, the developer will get the full scope of the issue and once the test passes the developer and reporter can be confident the problem no longer exists.

Linting

While I have read a lot about linting in the past but have not needed to use it on any projects I have worked on to date. So I was very happy to use and be taught the linting performed by the UI engineering team.

Enforces a standard coding syntax

I was very impressed with the level of code standards it enforces. It requires all code to be written in a certain way, from indenting and commenting to unused variables. This results in anyone using the code, being able to pick up it up and read it as if created by one person when in fact it may have contributed by many.

Code reviews

In my opinion code reviews should be performed on all front-end work to discourage sloppy code and encourage shared knowledge.

Mark up

Mark up should be very semantic. This can be a case of opinion, but shared discussion will get the team to an agreed solution, which will then be reused again by others in the similar situations.

CSS

CSS can be difficult as there are different ways to achieve a similar result, but with a code review the style used will be common practise within the team.

JavaScript

A perfect candidate as different people have different methods of coding. With a review, it will catch any sloppy or short cuts in the code. A review makes sure  your code is refactored to best-practise the first time.

Conclusion

Test driven development (TDD) does slow the development process down but enforces better output from your time spend on the code and less bugs in the future.

If someone writes a failing test for your code which is expected to pass, working on the code to produce a passing test is a much easier way to demonstrate the code now works, along with all the other test for that function.

I truly believe in code reviews now. Previously I was sceptical about them. I used to think that  “because my code is working” I didn’t need reviews and it would slow me down. But a good reviewer will catch things like “it works but didn’t you take a shortcut two classes ago which you meant to go back and refactor”. We all want our code to be perfect and to learn from others on a daily basis. That is what code reviews give us.

Read more
Inayaili de León Persson

Release month is always a busy one for the web team, and this time was no exception with the Ubuntu 13.10 release last week.

In the last few weeks we’ve worked on:

  • Ubuntu 13.10 release: we’ve updated www.ubuntu.com for the latest Ubuntu release
  • Updates to the new Ubuntu OpenStack cloud section: based on some really interesting feedback we got from Tingting’s research, we’ve updated the new pages to make them easier to understand
  • Canonical website: Carla has conducted several workshops and interviews with stakeholders and has defined key audiences and user journeys
  • Juju GUI: on-boarding is now ready to land in Juju soon
  • Fenchurch (our CMS): the demo services are fixed and our publishing speed has seen a 90% improvement!

And we’re currently working on:

  • Responsive mobile pilot: we’ve been squashing the most annoying bugs and it’s now almost ready for the public alpha release!
  • Canonical.com: with some of the research for the project already completed, Carla will now be working on creating the site’s information architecture and wireframing its key sections
  • Juju GUI: Alejandra, Luca, Spencer, Peter and Anthony are in a week-long sprint in San Francisco for some intense Juju-related work (lucky them!)
  • developer.ubuntu.com: we have been working with the Community team to update the site’s design to be more in line with www.ubuntu.com and the first iteration will be going live soon
  • Fenchurch: we are now working on a new download service

Release day at the Canonical office in LondonRelease day at the Canonical office

Have you got any questions or suggestions for us? Would you like to hear about any of these projects and tasks in more detail? Add your thoughts in the comments.

Read more
Inayaili de León Persson

We might have been quiet, but we have been busy! Here’s a quick overview of what the web team has been up to recently.

In the past month we’ve worked on:

  • New juju.ubuntu.com website: we’ve revamped the information architecture, revisited the key journeys and updated the look to be more in line with www.ubuntu.com
  • Fenchurch (our CMS): we’ve worked on speeding up deployment and continuous testing
  • New Ubuntu OpenStack cloud section on www.ubuntu.com/cloud: we’ve launched a restructured cloud section, with links to more resources, clearer journeys and updated design
  • Juju GUI: we’ve launched the brand new service inspector

And we’re currently working on:

  • 13.10 release updates: the new Ubuntu release is upon us, and we’re getting the website ready to show it off
  • A completely new project that will be our mobile/responsive pilot: we’re updating our web patterns to a more future-friendly shape, investigating solutions to handle responsive images, and we’ve set up a (growing) mobile device testing suite — watch this space for more on this project
  • Fenchurch: we’re improving our internal demo servers and enhancing performance on the downloads page to help deal with release days!
  • Usability testing of the new cloud section: following the aforementioned launch, Tingting is helping us test these pages with their target audience — and we’ve already found loads of things we can improve!
  • A new canonical.com: we haven’t worked on Canonical’s main website in a while, so we’re looking into making it leaner and meaner. As a first stage, Carla has been conducting internal interviews and analysing the existing content
  • Juju GUI: we’re designing on-boarding and a new notification system, and we’re finalising designs for the masthead, service block and relationship lines

We’ve also learnt that Spencer’s favourite author is Paul Auster. And Tristram wrote a post on his blog about his first experience with Juju.

Web team weekly meeting on 19 September 2013Spencer giving his 5×5 presentation at last week’s web team meeting

Have you got any questions or suggestions for us? Would you like to hear about any of these projects and tasks in more detail? Please let us know your thoughts in the comments.

Read more
Chee Wong

Right… so where should we start? First post.

Hello, my name is Chee, and I am an industrial designer.

In this post I will share some materials, stories and process during the development of the Ubuntu Edge.

 

D001

We started off by pulling the key elements of the Suru theme, and expanded on that, in order to explore the transition from a digital user experience, to a physical one.

 

0002

0005

0003

Once the rough ideas were formed, the fun part started, as we dived right into visualising the concepts; Pencils, sketching pads, markers, clippings, samples, colour chips and anything else interesting.

 

D003One of the best way to visualise, experiment and refine a design is to materialise it in any way possible. In the process of creating and fine tuning the Ubuntu Edge, we turned to methods known to be the most effective: Model making, 3D CAD, and 3D printing. In our case, we tried it all!

 

0009

0006

D004It’s equally important how the Ubuntu Edge feels in the hand, how it visually presents itself and how certain textures give visual cues to the perceived expression. How each material works alongside each other without creating visual complexity is one of the key role to either make or break a design.

After several rounds of refinement and fine-tuning, we pressed forward with what we have now today as the Ubuntu Edge. From a rendering to visualize the Ubuntu Edge, to one that sit in front of us.

 

I hope you enjoy reading through the process, and lets make it a reality.

The Ubuntu Edge

D005

Read more
Anthony Dillon

I wondered if I could make an easily updateable, prototype site in order to test a number of different IA’s using an XML file to represent the sitemap. This post is about what I did and how to get some sample code if you want to use or extend it for yourself.

The XML

The goal is to be able to simply edit, delete or add a section in the XML and refresh the site. There you have it. The navigation menu has changed.

Each <page> child of <sitemap> is top level navigation. You add children to that by placing <page> nodes inside each other.

<page title="Contact" url="contact-me">
  • title – The name of the menu item and the title of the page
  • url – The permalink for that page, this is added to the parents name if a child

Below is an example navigation to build a personal website:

<sitemap>
   <page title="Work" url="work">
       <page title="Develop" url="develop">
           <page title="Web development" url="web-development"></page>
           <page title="Apps" url="apps"></page>
       </page>
       <page title="Design" url="design">
           <page title="Web design" url="web-design"></page>
           <page title="Magazines" url="magazines"></page>
           <page title="Cartoons" url="cartoons"></page>
       </page>
       <page title="Videos" url="videos">
           <page title="Animation" url="animation"></page>
           <page title="Live footage" url="live-footage"></page>
           <page title="Showreel" url="showreel"></page>
       </page>
   </page>
   <page title="About Me" url="about-me">
       <page title="Life" url="life">
           <page title="Photos" url="photos"></page>
           <page title="Videos" url="videos"></page>
           <page title="Inspiration" url="inspiration"></page>
       </page>
           <page title="Socal" url="social">
           <page title="Friends" url="friends"></page>
           <page title="Family" url="family"></page>
           <page title="Things I've done" url="done"></page>
           <page title="Bucket list" url="bucket-list"></page>
       </page>
   </page>
   <page title="Contact" url="contact-me"></page>
</sitemap>

The system has only been developed to navigate three levels deep.

Adverts

I also wanted to have little ads in the corner of some of the mega menu dropdowns. To do this, there is an promo.xml in the XML folder. Simply wrap a title, img, p and link, if you would like, in the url of the top level link. This will result in an advert style banner on the right side of the menu. You can restyle this banner with CSS.

Here is the example of promo.xml:

<adverts>
    <work>
        <title>Latest website</title>
        <img>assets/images/200x150-b8b8b8-fff.jpg</img>
        <link url="#work/develop/web-development">See more</link>
    </work>
    <about-me>
        <title>My picture</title>
        <img>assets/images//200x150-b8b8b8-fff.jpg</img>
        <p>This is a little blarb all about what I do and where I am.</p>
    </about-me>
</adverts>

This is a little blarb all about what I do and where I am.

Hash bang

Using hash bangs, the site does not reload the page when a menu item is clicked. The JavaScript takes the updated hash value and updates the page values to mimic a new page. There are even three different page contents that are changed to reinforce to the user the fact we have changed page.

Demo

Check out the demo: http://www.anthonydillon.com/navigation-prototyping

The Result

The results were good. We were able to use this code to test three potential IAs and the mega menu itself with ten users. The XML allowed the me to easily tweak the menus between tests and it looked real enough that the users weren’t distracted by the lack of content behind the pages.

The Code

Feel free to use the code for quick navigation prototyping at: https://launchpad.net/navigation-prototyping

If you would like contribute to this project all your help is appreciated!

Read more
Anthony Dillon

We realise that changing Operating System (OS) is a big thing for anyone thinking of testing something out. That becomes a huge barrier for people trying out Ubuntu for the first time and seeing if they like it. As a member of the web team I decided to take on the challenge as a cool way to testing out some HTML5 and jQuery. The purpose of this blog is to talk about some of the challenges and thought processes I went through during the build.

Getting started

I started by breaking down the Ubuntu interface into DOM elements, similar to developing a web page from a design. So I took on the background first, each part of the build brought different challenges. In the case of the background, I needed it to stretch full width and height of the viewport.

The launcher

Once I had that nailed, I moved onto the launcher on the left of the screen. At the time of building (11.10) the menu would slide out of view when a window was fullscreen. By creating a DIV with a list of icons and styled with CSS to replicate the menu in the OS. Now I needed to add the interactive slide to the menu, which I decided to apply with jQuery because I wanted the animation to work on older browsers and not just browsers with CSS3. When a window is fullscreened I would trigger the menu system to slide the menu out of the viewport. Then binds a mouseover event to slide the menu back into view when the user needs it again.

Precise launcher

The global menu bar

Precise global menu bar

All that was left to make the web page look like the static Ubuntu interface was to add the global menu bar at the top for settings and window controls. This was again a simple DIV with a window control DIV floated to the left and a list of settings icons floated to the right.

Building applications

Now the interface looked like the initial Ubuntu screen. I turned to focus on applying the functionality to the menu icons, beginning with the folder icon. Created a Folder class and a File class, Folder class below:


function Folder($name, $location){
  if ($name==undefined) { $name='Untitled Folder';}
  if ($location==undefined) { $location='/Home';}
  var _name = $name;
  var _size = '6.2 GB';
  var _location = $location;
  var _in_bin = false;this.name = function (){ return _name; };
  this.size = function (){ return _size; };
  this.location = function (){ return _location; };
  this.in_bin = function (){ return _in_bin; };
  this.rename = function($name){
    _name = $name;
  }

  this.bin = function($in_bin){
    _in_bin = $in_bin;
  }

  this.move = function($location){
    _location = $location;
  }

  this.drawIcon = function($id, $type){
    return  "<div class='file-folder "+$type+"' data-type='folder' data-id='"+$id+"'><p></p><span>"+_name+"</span></div>";
  }

  this.type = function(){
    return 'folder';
  }
}

Both of these classes are used by the file system class that created them and stored them in an array to access and modify them later.
Now that we have a file system, the fun part comes when you connect it all up and see if it comes to life. This is how the connections happened:


Menu window workflow


When the folder icon on the menu is clicked it tells Base which triggers the open function in the folder system. I built the Folder and File classes with the aim to give the folder system full functionality, like rename, drag and drop to move, etc. But that was descoped to finish the tour in time for the release of 11.10.

Seeing this work I felt the buzz to jump to the next application, then the next, until all the applications I set out to develop were finished and working.

Have a go for yourself: Ubuntu Online Tour

Conclusion

One of the questions I was asked is `how long did it take you?’ In total it took about 4 months, from what started as a quick test to being given the time to bring the development to fruition. It was crucial that all elements of the demo looked and felt exactly like the OS as this will be most people first try of Ubuntu so we didn’t want it to be different if they install Ubuntu.

I plan to keep the tour up-to-date with the latest version of Ubuntu every six months. With every update I try to add features and application which I haven’t managed yet. A few features that come to mind would be to progressive enhance the movie player to use HTML5 video if available rather than Flash. I would also like to see the music player (Rhythmbox) be developed.

If you have HTML, CSS and jQuery skills and time to spare. Please feel free to contribute. The code can be forked from: Ubuntu Online Tour Launchpad Page.

Read more
Iain Farrell

In this latest post from Dalton Maag Lukas Paltram updates us on the development thinking that went into the italics in the new Ubuntu font family.

The design of the regular weight of the Ubuntu font, in all three script systems, was a big step forward. All design principles were defined and fixed. We could now proceed to it’s close companion, Ubuntu italic.

Upright and italic characters

The first trials for the Italic were concerned primarily with the question whether this should be simply a slanted and refined version of the regular style, typical for grotesque and geometric font styles, or should it be a classic, true Italic as we know it from serif and humanist sans serif fonts. We felt that only a true italic could satisfy the design of the Ubuntu font.

In typography, the purpose of the italic is to emphasise certain words or sentences. Therefore, a textural difference to the regular is important. The italic angle is of course the most obvious difference but in addition a slight reduction of width further helps to differentiate the italic.

Italic fonts have their roots in cursive handwriting and accordingly some characters have different shapes to the upright version. This is most obvious in the characters a, e, f or g, for example. As Latin script readers we are used to seeing these alternative glyph shapes and they are perfectly legible. Yet Ubuntu is a multilingual typeface, and we also had to consider other scripts and the changes that a switch to the cursive structure would bring to them. So, how does that affect Greek and Cyrillic letters, or other characters that we are not so familiar with?
Changed shapes

The principle of the regular design is simplicity and clarity. This principle needed to be carried across to the italic design,  so we introduced just enough true italic elements to give it its own warm and human character without compromising on simplicity and clarity.

Lukas Paltram

Read more