Canonical Voices

Posts tagged with 'design'

Luca Paulina

Over the last year we have been working on the Juju GUI to reach a broader audience. Juju is a way of building complex cloud environments. It connects different services, allows complex configuration and the ability to scale out quickly and easily. Juju is offered as a command line tool or as a GUI on the web.

The team

For the last 6 months a small dedicated team has been working together to push the design of the Juju GUI forward. The design team consists of 2 user experience designers, Alejandra and Luca, and 2 visual designers, Jamie and Spencer. The project has raised many questions and one of them was what it is like designing a product you don’t use. In this blog post Jamie and Luca attempt to clarify our process.

No assumptions

Luca: As a user experience designer part of my process is to create assumptions to further thought, design and development, these are later validated in interviews with stakeholders, user testing or with the development team. An assumption is something that is generally accepted as being true without proof. I’ll never be a direct user of Juju, therefore creating assumptions for the type of audience that the Juju GUI is designed for is an interesting challenge.

To help build assumptions, ideate and create cohesive user flows that will later be tested I’ve had to run planned and impromptu workshops, ask questions, have daily hangouts with the development team,  run week long sprints, ask more questions and lock myself away in the Juju war room to immerse myself in the world of Juju.

Juju_war_room

Jamie: From a visual perspective this digital product is unlike anything that I’ve worked on in the past. Whereas some rules of typography, hierarchies and readability apply to the design I’ve found myself a lot more focussed on subtle detailing and refinements than ever before. This is because users of the GUI are wanting to complete tasks, they want to be able to deploy their environments as quickly and painlessly as possible. So the design job became about helping them do that without the GUI getting in the way. It is intended to lay lightly across the canvas, aiding users when they need and not obstructing them when they don’t.

Juju GUIThe Juju GUI

Extensive and continuous research

Luca: I’m always surprised by the sheer amount of complexity that the GUI entails. The varying needs of our core target audiences means that we have to conduct a lot of research when we create user flows, ideas and when we’re examining if a feature is needed. Thankfully we have a great user research team which helps find users, conducts the testing and helps interpret the results.

I’ve found that with this particular product the interpretation of feedback has been key to making sure our designs resonate with our users. The feedback is catalogued in a document and shared out amongst the development teams to gain their insights and ideas as well. Solutions are then ideated and the design team then acts upon them creating new designs.

Jamie: The user testing results and feedback from the community has been key to the development of the visual style for the GUI. We’ve been through numerous rounds of testing to get to this stage of design development and each round of tests has moved the design forward. Once a round of testing has been completed the team will review the findings and create design tasks to solve any issues highlighted by the testers. The users we’ve tested with have been high-level cloud architects and system administrators, so familiar with the type of tasks that the GUI performs just not familiar with the way in which we perform those tasks in the GUI. Assumptions we’ve made about the way they would use the GUI have sometimes been mistaken so the design really has been guided by the users.

Juju GUI design evolutionEvolution of Juju’s interface

Constant validation from a multidisciplinary team

Luca: Throughout the project the need for validation on concepts and ideas has been incredibly important. The agile process we use allows us to create wireframes and designs quickly and get them in front the dev team and get their insight and feedback, we’re lucky enough to have a near 24 hour working cycle (Teams in Europe, North America and Australasia). Because of this it’s not uncommon for a design to go through many iterations in a week, for example; the inspector wireframes (pictured below) went through 9 revisions in 10 working days, the complexity of the inspector design and experience was refined and finessed collaboratively with the development team, this has turned the inspector into an integral and very powerful part of the GUI.

Juju inspector wireframesDetailed wireframes for the inspector

Jamie: Working within an agile process has meant that design decisions are required to be made quickly and collaboratively within the team. The design team in London is small so we can share work internally and move designs on sometimes multiple times a day. This means we’re able to keep up with the development cycle that releases every 2 weeks and means that users can see the design evolve far faster than waiting for a yearly or biannual release of the product. As a designer it’s been hard seeing the product not pixel perfect when it’s released but we’re working hard to craft, fine-tune and round the edges of it so it will be a beautiful thing to use and interact with each new release.

Inspector designVisual iterations of the inspector

Questioning language and terminology

Luca: Juju is expanding into a new field of creating clouds by managing services not machines. This means that there really isn’t a language framework that we can rely on and one thing that has been apparent over the last 6 months is the importance of terminology and language for developers. At the beginning of the project it was difficult and time consuming to learn the established vocabulary associated with the cloud and Juju, this gave us a great reason to start questioning words and terms used throughout the GUI. We uncovered words that were already established in other web services and words that didn’t connect with the user. Questioning these words and terms made it clear that not only do we (as non-users) not understand but this would also happen with users and it allowed us to finesse the language in the GUI to something more appropriate.

Good design principles and patterns

Jamie: The GUI is not just the work of the Cloud team. To harmonize the look of the products in the Canonical stable we’ve worked closely with the design team developing the phone OS looking for ways that design patterns developed by them can be applied to the Juju GUI. We’ve also worked with the Web team to see where we can integrate any elements from their UI library. The GUI is a product but it’s not a mobile OS and equally we interact with it in a desktop web browser but it’s not a website, so it ultimately has to have it’s own look. But by pooling the collective design wisdom of the teams who have been crafting interactions in their specific fields and by using patterns and guidelines already defined in this space we can create a interface that is better than the sum these parts but with it’s own clear voice.

Good design practices

Jamie: We like to sketch here. We sketch everything out before any work is done on screen and it’s enormously useful in iterating quickly through problems that users have and trying to come up with multiple solutions to these in a collaborative way. With a small team we can sketch our way through multiple problems towards multiple solutions and then move into applications like Photoshop and Illustrator once we’ve got a clear direction of the UX. This fast way of working also allows us to keep pace with the development cycle and to be able to add features to the GUI each time we do a release. Once a feature of the GUI is open to the world we’ll gather feedback then it’s back to the drawing board to refine it.

Isle of Man workshopUX sketching during a recent sprint

Playing to our strengths

Luca: Most of the processes to provision, create and manage services in the cloud are currently carried out via command line. A priority for us has been to think about how we can use visual language to provide a layer of information and understanding not readily available via the command line. As designers we understand that with colour, structure, layout and flow we can communicate the status of a system or process in a very powerful way. We have made it our goal to bring out the strengths of the GUI by exploring visual metaphors and relationships. We established that the command line is an input output tool, the GUI doesn’t have that type of interaction and offers a more holistic approach, we offer that by having a clear hierarchy and having concise user flows. Early on in the project we made a principle to not compete with the command line but to embrace it, there are users out there who will use Juju just as a command line tool or as the GUI or a mix of both.

Charm-iconsPlayful icons helps users navigate the GUI

Final thoughts

Pretty much everyone in the team has been involved in the conceptual stage of the project, this has helped us create a cohesive product with some really powerful features. I’m sure there are a lot of designers out there working on designs for products that they won’t end up using. We wanted to take the time to highlight how we’ve approached this problem while we’ve been working on the Juju GUI project. The coming months will see a redesign of the the navigation bar, notifications, service blocks and relationship lines. We’ve given you a preview of some of these features in the visuals above.

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
Katie Taylor

Since Ubuntu touch was announced, its been fantastic to see the variety of apps you’ve been developing, from shopping lists to word games, to apps that aid your daily commute.

As the Ubuntu Touch platform gets bigger and better, myself and the design team have been receiving more requests for feedback on designs, as well as questions about the App Design Guides and general app design. And although we are available for conversations on irc and in the email lists, what’s been missing is a place to have a more in-depth and visual conversation about app design.

Starting this Wednesday the design team will host a weekly app design clinic on Ubuntu On Air. The clinic is a chance for you to get feedback on your app’s UI, and a forum for you to ask questions about interactions, the Ubuntu brand and guidelines, visual styles, typography, colour… anything design that you want to ask.

If you would like feedback on a particular design, send a screenshot or mockup of your design to design@canonical.com before 1pm UTC on Tuesday.

The first clinic will be this Wednesday 11th September at 1pm UTC at http://ubuntuonair.com/ . Join us (or watch later) to find out more.

Read more
Tingting Zhao

In past years, we have had many Ubuntu users getting involved in helping with our user research. Now we feel it’s time to form a user research network, which we’re calling: UbuntuVoice.

So,  if you want to:

  • be the voice of over 20 million Ubuntu users. You will have the opportunities to take part in a variety of Ubuntu user research with different products, and help shape the Ubuntu experience. You choose the ones that you are interested in.

  • stay up to date with Ubuntu. Get periodic updates (every two months) via email, such as what designers are working on, how feedback is used, and how users behave when interacting with technology.

  • get a little something extra. Some of our research will come with an incentive, or in the form of a ‘Ubuntu goody’ lucky draw, and some research will be voluntary.

…then join us today by clicking here

If you have any questions, please feel free to contact us at: ubuntuvoice@gmail.com

 

Update: Thank you very much for everyone’s support for the UbuntuVoice! We reached our target number of participants in just a day! Since we are a small team, we can’t have more participants at the moment. However, do keep your eyes on the design blog for updates.

Ubuntu user research team

Read more
Lisette Slegers

Music app: focus on the content

Music apps that allow users to switch between player and queue mode can be quite complex. Some challenges of music apps in general:

  • Deep navigation through the music library:
    Home › Artists › Artist › Album › Play queue
  • Switching between play queue and library

And a challenge unique for the Ubuntu phone:

Tabs

The Ubuntu Music app is all about your music collection. The home screen shows a list of recently played items and the musical genres in your collection. It is easy to find your way around with the tab navigation.

Navigate to an album

Let’s open one of the albums.

Open an album

Player

Tap on a song to start playing it and enter the player view. This view combines full album art of the item that is currently playing, and a queue of all previous and next items. There are play controls in the toolbar at the bottom of the screen.

Play a song

Queue

For the next example of what you can do with the queue, let’s imagine that we have already queued up a lot more songs from various albums.

Scroll down the list to see what’s coming up in the queue. When our focus changes from the current song to the rest of the queue, the toolbar with play controls contracts. A hint of a progress bar stays on the screen; not to interact with, but as a visual hint to show something is playing and as a reference to where the play controls are.

See what's next in the queue

Users can remove songs from the queue by swiping, and move songs to a different position in the queue with drag and drop.

Bring up the toolbar with play controls to refocus on what is playing now. As the toolbar is swiped up, the queue moves back to the current item.

Back to the currently playing song

Back to the library

The user can go back to their library to find more songs to queue. Patterns for back and overflow in the toolbar are still in development so check the App design guides to find out how exactly this will work.

Back to the library

Back in the library view, we again see a hint of the progress bar to show that items are in the play queue. We bring up the toolbar and see the condensed play controls. The toolbar lets users tap play or pause on the current song, tap on the album art or song title to return to the player view, and open up the overflow actions.

Back to albums

We navigate to another album.

Open another album

Item options

To keep our focus on play controls in the toolbar and keep the toolbar as light as possible, item actions are grouped with the item and accessible via the expansion pattern. This goes for library albums and songs and queued songs. We can queue another song of the album we are looking at with the song options.

Add a song to the queue

What’s next

This is the basic UX concept for the music app. Visual design will play a big part in deciding what exactly goes where, and we will need to test if the controls are easy enough to access. Coming soon are some exciting visuals to connect the dots.

Read more
Lina Pio

Over the past few weeks we’ve been exploring visual directions for the calendar app. It’s a pretty exciting opportunity to create something fresh and at the same time useful. In this post I’ll take you through some of the directions we’re looking at right now and where we hope to eventually go. At this stage the designs are still under consideration.

Year view

This view offers a lot of challenges particularly given the large amount of information that can be compacted into such a small space. The challenge was to provide something that could inform the user quickly and usefully without overloading the screen with information. Each month is clickable. Individual dates, however, will need to be selected from the month view.

01_year copy

Month view

As with year view, it’s a tough call to keep the month view looking and feeling smooth and simple. Because of this, we decided to use the month view to provide the user with an overview of the dates in that month, from which they could select a date only. Instead of filling in the events inside the month view, the user can see the events at a glance inside the week view. We explored two different ways of laying out the month view visually.
02_month copy    02_month2 copy

Week view

In this view we experimented with the visual layout in terms of how much screen space the chrome took up and how you could visually represent different calendar events using coloured blocks vs coloured dots.

03_week1 copy 04_week2 copy 04_week3 copy 04_week4 copy 04_week5 copy

 

 

Day view

With day view, as with Week view, we tried looking at reducing the chrome around the day box to give more space to what the user most needs to see – the events during that day.

05_day1 copy 06_day2 copy

Event

Event view tends to be a different interface type than the others. Where with the other views a user’s prime activity is to navigate through information, the event is the goal in itself, providing a list of information. Because of this, a white background may be a better solution to presenting large amounts of text, making it easier on the eye. One thing that is still in design at the moment is the ability to select the date and time when creating a new event.

07_new_event1 copy 08_new_event2 copy 09_new_event3 copy 10_event_detail copy 10_event_detail2

We hope you enjoyed going through our visuals and thought process. Watch this space next time for more visuals on date and time picker to go along with event view.

 

Video

Here’s a video to show how the interactions and transitions will eventually function.

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
Michal Izydorczyk

Shorts visual exploration

Hey

After all the work we have done on the Rituals app designs it was time to start exploring other core apps.

I thought it would be good to share with you our recent exploration of the RSS Reader App.

Please note that those are only the key screens and settings are not covered yet. But this should give you something to get started ;)

Here is the link to the spec with all the font sizes, spacing, and colour values for the gradient backgrounds…

Let me know what you think ;) and I will try to update you on some visuals for the music app next.

This is the home screen of the RSS Reader.

Read more
niemeyer

As part of one of the projects we’ve been pushing at Canonical, I spent a few days researching about the possibility of extending a compiled Go application with a tiny language that would allow expressing simple procedural logic in a controlled environment. Although we’re not yet sure of the direction we’ll take, the result of this short experiment is being released as the twik language for open fiddling.

The implementation is straightforward, with under 400 lines for the parser and evaluator, and under 350 lines in the default functions provided for the language skeleton: var, func, do, if, and, or, etc.

It also comes with an interactive interpreter to play with. You can install it with:

$ go get launchpad.net/twik/cmd/twik

This is a short sample session:

> (var x 1)
> x
1
> (set x 2)
> x
2
> (set x (func (n) (+ n 1)))
> x
#func
> (x 1)
2
> (func inc (n) (+ n 1))
#func
> (inc 42)
43

Another one demonstrating the lexical scoping:

> (var add
.      (do
.          (var n 0)
.          (func (m) (set n (+ n m)) n)
.      )
. )
> (add 5)
5
> (add -1)
4
> n
twik source:1:1: undefined symbol: n

New functionality may be plugged in by providing Go functions. For example, here is a simple printf function:

func printf(args []interface{}) (interface{}, error) {
        if len(args) > 0 {
                if format, ok := args[0].(string); ok {
                        _, err := fmt.Printf(format, args[1:]...)
                        return nil, err
                }
        }
        return nil, fmt.Errorf("printf takes a format string")
}

func main() {
        ...
        err = scope.Create("printf", printf)
        ...
}

It can now greet the world:

$ cat test.twik

(func hello (name)
      (printf "Hello %s!\n" name)
)

(hello "world")

$ time ./twik test.twik
Hello world!
./twik test.twik  0.00s user 0.00s system 74% cpu 0.005 total

Read more
Iain Farrell

Hello everyone! I’m delighted to be kicking off the next wallpaper selection process for the 13.10 release of Ubuntu coming this October. As you can see from the Saucy Salamander release schedule, we hit UI freeze on August 29th of this year and we’d like to get all your lovely community submitted images ready before then. To get involved submit your images to the Flickr group for submissions.

I’ve also made the above short video to encourage new people to get involved, share it around as hopefully it’s a good intro to the process and if you have ideas or comments then let me know, I can make additional ones as we go.

With some help from designers in Canonical we’ve come up with the following tips for creating wallpapers images.

  1. Images shouldn’t be busy and filled with too many shapes and colours, a similar tone throughout is a good rule of thumb.
  2. A single point of focus, a single area that draws the eye into the image, can also help you avoid something too cluttered.
  3. The left and top edges are home to Ubuntu’s Launcher and Panel so be careful to consider how your images look in place so as not to clash with the interface.
  4. Try your image at different aspect ratios to make sure something important isn’t cropped out on smaller/ larger screens at different resolutions.
  5. Take a look at the wallpapers guidance on the Ubuntu Wiki regarding the size of images. Our minimum resolution is 2560 x 1600.

To shortlist from this collection we’ll be going to the contributors whose images were selected last time around to act as our selection judges. In doing this we’ll hold a series of public IRC meetings on Freenode in #1310wallpaper to discuss the selection. In those sessions we’ll get the selection team to try out the images on their own Ubuntu machines to see what they look like on a range of displays and resolutions.

Anyone is welcome to come to these sessions but please keep in mind that an outcome is needed from the time that people are volunteering and there’s usually a lot of images to get through so we’d appreciate it if there isn’t too much additional debate.

So, to get this show on the road here’s the outline for this cycle.

  • 12/07/13 – Kick off 13.10 wallpaper submission process
  • 23/07/13 – First get together on #1310wallpaper at 19:30 GMT
  • 16/08/13 – Submissions deadline at 18:00 GMT – Flickr group will be locked and the selection process will begin
  • 23/08/13 – Deliver final selection in zip format to Launchpad
  • 29/08/13 – UI freeze for latest version of Ubuntu with our fantastic images in!

As always, ping me if you have any questions, I’ll be lurking in #1310wallpaper on freenode or leave a question in the Flickr group for wider discussion, that’s probably the fastest way to get an answer to a question.

I’ll be posting updates on our schedule here from time to time but the Flickr group will serve as our hub.

Happy snapping and scribbling and on behalf of the community, thanks for contributing to Ubuntu! :)


Read more
niemeyer

In an effort to polish the recently released draft of the strepr v1 specification, I’ve spent the last couple of days in a Go reference implementation.

The implemented algorithm is relatively simple, efficient, and consumes a conservative amount of memory. The aspect of it that deserved the most attention is the efficient encoding of a float number when it carries an integer value, as covered before. The provided tests are a useful reference as well.

The API offered by the implemented package is minimal, and matches existing conventions. For example, this simple snippet will generate a hash for the stable representation of the provided value:

value := map[string]interface{}{"a": 1, "b": []int{2, 3}}
hash := sha1.New()
strepr.NewEncoder(hash).Encode(value)
fmt.Printf("%x\n", hash.Sum(nil))
// Outputs: 29a77d09441528e02a27dc498d0a757da06250a0

Along with the reference implementation comes a simple command line tool to play with the concept. It allows easily arriving at the same result obtained above by processing a JSON value instead:

$ echo '{"a": 1.0, "b": [2, 3]}' | ./strepr -in-json -out-sha1
29a77d09441528e02a27dc498d0a757da06250a0

Or YAML:

$ cat | ./strepr -in-yaml -out-sha1                 
a: 1
b:
   - 2
   - 3
29a77d09441528e02a27dc498d0a757da06250a0

Or even BSON, the binary format used by MongoDB:

$ bsondump dump.bson
{ "a" : 1, "b" : [ 2, 3 ] }
1 objects found
$ cat dump.bson | ./strepr -in-bson -out-sha1
29a77d09441528e02a27dc498d0a757da06250a0

In all of those cases the hash obtained is the same, despite the fact that the processed values were typed differently in some occasions. For example, due to its Javascript background, some JSON libraries may unmarshal numbers as binary floating point values, while others distinguish the value based on the formatting used. The strepr algorithm flattens out that distinction so that different platforms can easily agree on a common result.

To visualize (or debug) the stable representation defined by strepr, the reference implementation has a debug dump facility which is also exposed in the command line tool:

$ echo '{"a": 1.0, "b": [2, 3]}' | ./strepr -in-json -out-debug
map with 2 pairs (0x6d02):
   string of 1 byte (0x7301) "a" (0x61)
    => uint 1 (0x7001)
   string of 1 byte (0x7301) "b" (0x62)
    => list with 2 items (0x6c02):
          - uint 2 (0x7002)
          - uint 3 (0x7003)

Assuming a Go compiler and the go tool are available, the command line strepr tool may be installed with:

$ go get launchpad.net/strepr/cmd/strepr

As a result of the reference implementation work, a few clarifications and improvements were made to the specification:

  • Enforce the use of UTF-8 for Unicode strings and explain why normalization is being left out.
  • Enforce a single NaN representation for floats.
  • Explain that map key uniqueness refers to the representation.
  • Don’t claim the specification is easy to implement; floats require attention.
  • Mention reference implementation.

Read more
Katie Taylor

Edges are special to us. We use them for finding apps, tools and system services, so using the edges will be second nature to Ubuntu phone users. By using the launcher, how to launch your favourite app will become ingrained in your muscle memory of the left edge.

The design vision behind Ubuntu for phones includes the use of fast and natural interactions, so taking that to the welcome screen means that if your phone is locked, you can still access the launcher, system services and the right edge. If you have a pin set up, you only need to enter your pin when accessing private data, in the Gallery app or the Dash for example.

 

 

If you’ve flashed your phone recently, you will be able to activate the lock screen for the phone using a temporary hack (love it!). You’ll notice that the blur has not yet been implemented, but will be added later. Thanks to Michael Zanetti for originally posting instructions to the Ubuntu Phone mailing list. Here they are:

To enable the pin lock, log into the phone and create a file /home/phablet/.unity8-greeter-demo, with the content: password=pin

If you want to see the password unlock screen instead, put this into the file:  password=keyboard
For now, the pin is hardcoded to “1234″ and the password is “password”. Note that this functionality can (and will) disappear at any time as we bring all the bits and pieces together. This is a temporary, simple way to enable the visual part of the lock screen for us all to have a play with.

Let us know what you think on the Ubuntu Phone mailing list and the IRC channel.

Read more
Lisette Slegers

In my previous blog post, we looked at the key screens for Shorts, the organic grid and the reading view. You can read about the list view behaviour in this document. In this post, I would like to look at journeys for adding and editing content, sharing an article and adjusting the reading view.

Sharing and adjusting the reading view

From the reading view, pull up the toolbar to reveal options:

Reveal reading options

Options for adjusting the reading view are:

  • Font size
  • Light / dark theme

Article view options

Any changes made to the reading view are persistent until the view is changed again.

Adding things to read 

There are different options for adding content to the Shorts app. All of the options described here are for when the user already has feed subscriptions in the app; the first use scenario is not yet covered. To get to the different options for adding content, pull up the toolbar from the topic view:

Adding content

1. Adding a topic

Adding a topic

Adding a new topic with feed suggestions makes finding things to read much easier for users who don’t understand RSS. However, suggesting feeds for subjects could easily become quite complex; for example feeds related to ‘News’ are location specific. Whether we can suggest feeds for users will depend on if we can automate this process.

2. Adding feeds

Add feeds 1

Add feeds 2

When adding one or more feeds, the user needs to select a topic to organise it under. Selecting the topic is done with the expanded option selector.

3. Add online accounts

This might not be possible for version 1, but being able to read articles that were posted on your social networks would be a great feature to have in Shorts. Connecting to social networks will be done through Ubuntu Online Accounts.

4. Import subscriptions

Exact functionality for importing and exporting subscriptions will depend on the how the file manager works.

5. Other

Depending on browser functionality, it might be possible to add feeds from the browser.

Edit topics

In Shorts, feeds are organised under topics. Occasionally, users might want to change the names of their topics and the organisation of their feeds. Under ‘edit topics’, users can:

1. Change topic names

Edit topic names

2. Change topic organisation by adding a new one

Edit topics: add a new one

3. Moving feeds into a different topic

Move feeds into a different topic

The above proposal lets users drag feeds from one topic and drop it into another. The list of feeds under a topic could be very long, so there is an option to collapse the topic. Whether this is possible depends on the drag and drop pattern available in the SDK. Drag and drop is not the easiest thing to do on a touchscreen. A possible alternative would be to long-press on a feed, go into selection mode and have move topic as one of the options.

4. Deleting feeds or entire topics 

Same as in the messaging menu, we will use the swipe to delete pattern – this will soon be in the app design guides.

Next steps

We aim to make the app powerful but simple by having the more complex options easily accessible where they are needed, and to cater for both advanced and novice users. Do you think this app can work without pages and pages of settings? Looking forward to hear your feedback and ideas. You can follow our progress on Google+, the Ubuntu Phone mailing list and IRC channel. Next thing to do is look at first use and no content scenarios.

Read more
niemeyer

Note: This is a candidate version of the specification. This note will be removed once v1 is closed, and any changes will be described at the end. Please get in touch if you’re implementing it.

Contents


Introduction

This specification defines strepr, a stable representation that enables computing hashes and cryptographic signatures out of a defined set of composite values that is commonly found across a number of languages and applications.

Although the defined representation is a serialization format, it isn’t meant to be used as a traditional one. It may not be seen entirely in memory at once, or written to disk, or sent across the network. Its role is specifically in aiding the generation of hashes and signatures for values that are serialized via other means (JSON, BSON, YAML, HTTP headers or query parameters, configuration files, etc).

The format is designed with the following principles in mind:

Understandable — The representation must be easy to understand to increase the chances of it being implemented correctly.

Portable — The defined logic works properly when the data is being transferred across different platforms and implementations, independently from the choice of protocol and serialization implementation.

Unambiguous — As a natural requirement for producing stable hashes, there is a single way to process any supported value being held in the native form of the host language.

Meaning-oriented — The stable representation holds the meaning of the data being transferred, not its type. For example, the number 7 must be represented in the same way whether it’s being held in a float64 or in an uint16.


Supported values

The following values are supported:

  • nil: the nil/null/none singleton
  • bool: the true and false singletons
  • string: raw sequence of bytes
  • integers: positive, zero, and negative integer numbers
  • floats: IEEE754 binary floating point numbers
  • list: sequence of values
  • map: associative value→value pairs


Representation

nil = 'z'

The nil/null/none singleton is represented by the single byte 'z' (0x7a).

bool = 't' / 'f'

The true and false singletons are represented by the bytes 't' (0x74) and 'f' (0x66), respectively.

unsigned integer = 'p' <value>

Positive and zero integers are represented by the byte 'p' (0x70) followed by the variable-length encoding of the number.

For example, the number 131 is always represented as {0x70, 0x81, 0x03}, independently from the type that holds it in the host language.

negative integer = 'n' <absolute value>

Negative integers are represented by the byte 'n' (0x6e) followed by the variable-length encoding of the absolute value of the number.

For example, the number -131 is always represented as {0x6e, 0x81, 0x03}, independently from the type that holds it in the host language.

string = 's' <num bytes> <bytes>

Strings are represented by the byte 's' (0x73) followed by the variable-length encoding of the number of bytes in the string, followed by the specified number of raw bytes. If the string holds a list of Unicode code points, the raw bytes must contain their UTF-8 encoding.

For example, the string hi is represented as {0x73, 0x02, 'h', 'i'}

Due to the complexity involved in Unicode normalization, it is not required for the implementation of this specification. Consequently, Unicode strings that if normalized would be equal may have different stable representations.

binary float = 'd' <binary64>

32-bit or 64-bit IEEE754 binary floating point numbers that are not holding integers are represented by the byte 'd' (0x64) followed by the big-endian 64-bit IEEE754 binary floating point encoding of the number.

There are two exceptions to that rule:

1. If the floating point value is holding a NaN, it must necessarily be encoded by the following sequence of bytes: {0x64, 0x7f, 0xf8, 0x00 0x00, 0x00, 0x00, 0x00, 0x00}. This ensures all NaN values have a single representation.

2. If the floating point value is holding an integer number it must instead be encoded as an unsigned or negative integer, as appropriate. Floating point values that hold integer numbers are defined as those where floor(v) == v && abs(v) != ∞.

For example, the value 1.1 is represented as {0x64, 0x3f, 0xf1, 0x99, 0x99, 0x99, 0x99, 0x99, 0x9a}, but the value 1.0 is represented as {0x70, 0x01}, and -0.0 is represented as {0x70, 0x00}.

This distinction means all supported numbers have a single representation, independently from the data type used by the host language and serialization format.

list = 'l' <num items> [<item> ...]

Lists of values are represented by the byte 'l' (0x6c), followed by the variable-length encoding of the number of pairs in the list, followed by the stable representation of each item in the list in the original order.

For example, the value [131, -131] is represented as {0x6c, 0x70, 0x81, 0x03, 0x6e, 0x81, 0x03, 0x65}

map = 'm' <num pairs> [<item key> <item value>  ...]

Associative maps of values are represented by the byte 'm' (0x6d) followed by the variable-length encoding of the number of pairs in the map, followed by an ordered sequence of the stable representation of each key and value in the map. The pairs must be sorted so that the stable representation of the keys is in ascending lexicographical order. A map must not have multiple keys with the same representation.

For example, the map {"a": 4, 5: "b"} is always represented as {0x6d, 0x02, 0x70, 0x05, 0x73, 0x01, 'b', 0x73, 0x01, 'a', 0x70, 0x04}.


Variable-length encoding

Integers are variable-length encoded so that they can be represented in short space and with unbounded size. In an encoded number, the last byte holds the 7 least significant bits of the unsigned value, and zero as the eight bit. If there are remaining non-zero bits, the previous byte holds the next 7 bits, and the eight bit is set on to flag the continuation to the next byte. The process continues until there are non-zero bits remaining. The most significant bits end up in the first byte of the encoded value, which must necessarily not be 0x80.

For example, the number 128 is variable-length encoded as {0x81, 0x00}.


Reference implementation

A reference implementation is available, including a test suite which should be considered when implementing the specification.


Changes

draft1 → draft2

  • Enforce the use of UTF-8 for Unicode strings and explain why normalization is being left out.
  • Enforce a single NaN representation for floats.
  • Explain that map key uniqueness refers to the representation.
  • Don’t claim the specification is easy to implement; floats require attention.
  • Mention reference implementation.

Read more
niemeyer

The very first time the concepts behind the juju project were presented, by then still under the prototype name of Ubuntu Pipes, was about four years ago, in July of 2009. It was a short meeting with Mark Shuttleworth, Simon Wardley, and myself, when Canonical still had an office on a tall building by the Thames. That was just the seed of a long road of meetings and presentations that eventually led to the codification of these ideas into what today is a major component of the Ubuntu strategy on servers.

Despite having covered the core concepts many times in those meetings and presentations, it recently occurred to me that they were never properly written down in any reasonable form. This is an omission that I’ll attempt to fix with this post while still holding the proper context in mind and while things haven’t changed too much.

It’s worth noting that I’ve stepped aside as the project technical lead in January, which makes more likely for some of these ideas to take a turn, but they are still of historical value, and true for the time being.

Contents

This post is long enough to deserve an index, but these sections do build up concepts incrementally, so for a full understanding sequential reading is best:


Classical deployments

In a simplistic sense, deploying an application means configuring and running a set of processes in one or more machines to compose an integrated system. This procedure includes not only configuring the processes for particular needs, but also appropriately interconnecting the processes that compose the system.

The following figure depicts a simple example of such a scenario, with two frontend machines that had the Wordpress software configured on them to serve the same content out of a single backend machine running the MySQL database.

Deploying even that simple environment already requires the administrator to deal with a variety of tasks, such as setting up physical or virtual machines, provisioning the operating system, installing the applications and the necessary dependencies, configuring web servers, configuring the database, configuring the communication across the processes including addresses and credentials, firewall rules, and so on. Then, once the system is up, the deployed system must be managed throughout its whole lifecycle, with upgrades, configuration changes, new services integrated, and more.

The lack of a good mechanism to turn all of these tasks into high-level operations that are convenient, repeatable, and extensible, is what motivated the development of juju. The next sections provide an overview of how these problems are solved.


Preparing a blank slate

Before diving into the way in which juju environments are organized, a few words must be said about what a juju environment is in the first place.

All resources managed by juju are said to be within a juju environment, and such an environment may be prepared by juju itself as long as the administrator has access to one of the supported infrastructure providers (AWS, OpenStack, MAAS, etc).

In practice, creating an environment is done by running juju’s bootstrap command:

$ juju bootstrap

This will start a machine in the configured infrastructure provider and prepare the machine for running the juju state server to control the whole environment. Once the machine and the state server are up, they’ll wait for future instructions that are provided via follow up commands or alternative user interfaces.


Service topologies

The high-level perspective that juju takes about an environment and its lifecycle is similar to the perspective that a person has about them. For instance, although the classical deployment example provided above is simple, the mental model that describes it is even simpler, and consists of just a couple of communicating services:

That’s pretty much the model that an administrator using juju has to input into the system for that deployment to be realized. This may be achieved with the following commands:

$ juju deploy cs:precise/wordpress
$ juju deploy cs:precise/mysql
$ juju add-relation wordpress mysql

These commands will communicate with the previously bootstrapped environment, and will input into the system the desired model. The commands themselves don’t actually change the current state of the deployed software, but rather inform the juju infrastructure of the state that the environment should be in. After the commands take place, the juju state server will act to transform the current state of the deployment into the desired one.

In the example described, for instance, juju starts by deploying two new machines that are able to run the service units responsible for Wordpress and MySQL, and configures the machines to run agents that manipulate the system as needed to realize the requested model. An intermediate stage of that process might conceptually be represented as:

topology-step-1

The service units are then provided with the information necessary to configure and start the real software that is responsible for the requested workload (Wordpress and MySQL themselves, in this example), and are also provided with a mechanism that enables service units that were related together to easily exchange data such as addresses, credentials, and so on.

At this point, the service units are able to realize the requested model:

topology-step-2

This is close to the original scenario described, except that there’s a single frontend machine running Wordpress. The next section details how to add that second frontend machine.


Scaling services horizontally

The next step to match the original scenario described is to add a second service unit that can run Wordpress, and that can be achieved by the single command:

$ juju add-unit wordpress

No further commands or information are necessary, because the juju state server understands what the model of the deployment is. That model includes both the configuration of the involved services and the fact that units of the wordpress service should talk to units of the mysql service.

This final step makes the deployed system look equivalent to the original scenario depicted:

topology-step-3

Although that is equivalent to the classic deployment first described, as hinted by these examples an environment managed by juju isn’t static. Services may be added, removed, reconfigured, upgraded, expanded, contracted, and related together, and these actions may take place at any time during the lifetime of an environment.

The way that the service reacts to such changes isn’t enforced by the juju infrastructure. Instead, juju delegates service-specific decisions to the charm that implements the service behavior, as described in the following section.


Charms

A juju-managed environment wouldn't be nearly as interesting if all it could do was constrained by preconceived ideas that the juju developers had about what services should be supported and how they should interact among themselves and with the world.

Instead, the activities within a service deployed by juju are all orchestrated by a juju charm, which is generally named after the main software it exposes. A charm is defined by its metadata, one or more executable hooks that are called after certain events take place, and optionally some custom content.

The charm metadata contains basic declarative information, such as the name and description of the charm, relationships the charm may participate in, and configuration options that the charm is able to handle.

The charm hooks are executable files with well-defined names that may be written in any language. These hooks are run non-concurrently to inform the charm that something happened, and they give a chance for the charm to react to such events in arbitrary ways. There are hooks to inform that the service is supposed to be first installed, or started, or configured, or for when a relation was joined, departed, and so on.

This means that in the previous example the service units depicted are in fact reporting relevant events to the hooks that live within the wordpress charm, and those hooks are the ones responsible for bringing the Wordpress software and any other dependencies up.

wordpress-service-unit

The interface offered by juju to the charm implementation is the same, independently from which infrastructure provider is being used. As long as the charm author takes some care, one can create entire service stacks that can be moved around among different infrastructure providers.


Relations

In the examples above, the concept of service relationships was introduced naturally, because it’s indeed a common and critical aspect of any system that depends on more than a single process. Interestingly, despite it being such a foundational idea, most management systems in fact pay little attention to how the interconnections are modeled.

With juju, it’s fair to say that service relations were part of the system since inception, and have driven the whole mindset around it.

Relations in juju have three main properties: an interface, a kind, and a name.

The relation interface is simply a unique name that represents the protocol that is conventionally followed by the service units to exchange information via their respective hooks. As long as the name is the same, the charms are assumed to have been written in a compatible way, and thus the relation is allowed to be established via the user interface. Relations with different interfaces cannot be established.

The relation kind informs whether a service unit that deploys the given charm will act as a provider, a requirer, or a peer in the relation. Providers and requirers are complementary, in the sense that a service that provides an interface can only have that specific relation established with a service that requires the same interface, and vice-versa. Peer relations are automatically established internally across the units of the service that declares the relation, and enable easily clustering together these units to setup masters and slaves, rings, or any other structural organization that the underlying software supports.

The relation name uniquely identifies the given relation within the charm, and allows a single charm (and service and service units that use it) to have multiple relations with the same interface but different purposes. That identifier is then used in hook names relative to the given relation, user interfaces, and so on.

For example, the two communicating services described in examples might hold relations defined as:

wordpress-mysql-relation-details

When that service model is realized, juju will eventually inform all service units of the wordpress service that a relation was established with the respective service units of the mysql service. That event is communicated via hooks being called on both units, in a way resembling the following representation:

wordpress-mysql-relation-workflow

As depicted above, such an exchange might take the following form:

  1. The administrator establishes a relation between the wordpress service and the mysql service, which causes the service units of these services (wordpress/1 and mysql/0 in the example) to relate.
  2. Both service units concurrently call the relation-joined hook for the respective relation. Note that the hook is named after the local relation name for each unit. Given the conventions established for the mysql interface, the requirer side of the relation does nothing, and the provider informs the credentials and database name that should be used.
  3. The requirer side of the relation is informed that relation settings have changed via the relation-changed hook. This hook implementation may pick up the provided settings and configure the software to talk to the remote side.
  4. The Wordpress software itself is run, and establishes the required TCP connection to the configured database.

In that workflow, neither side knows for sure what service is being related to. It would be feasible (and probably welcome) to have the mysql service replaced by a mariadb service that provided a compatible mysql interface, and the wordpress charm wouldn’t have to be changed to communicate with it.

Also, although this example and many real world scenarios will have relations reflecting TCP connections, this may not always be the case. It’s reasonable to have relations conveying any kind of metadata across the related services.


Configuration

Service configuration follows the same model of metadata plus executable hooks that was described above for relations. A charm can declare what configuration settings it expects in its metadata, and how to react to setting changes in an executable hook named config-changed. Then, once a valid setting is changed for a service, all of the respective service units will have that hook called to reflect the new configuration.

Changing a service setting via the command line may be as simple as:

$ juju set wordpress title="My Blog"

This will communicate with the juju state server, record the new configuration, and consequently incite the service units to realize the new configuration as described. For clarity, this process may be represented as:

config-changed


Taking from here

This conceptual overview hopefully provides some insight into the original thinking that went into designing the juju project. For more in-depth information on any of the topics covered here, the following resources are good starting points:

Read more
Lina Pio

One of the key challenges with designing calendar applications is the number of ways you can display your time, whether it’s by year, month, week or day. After a lot of good old fashioned hard work, we refactored navigation by making the tab header the key to switching between views. Although the direction I’ll take you through in this article is strong and clean, it’s still a work in progress, and as such, can still change. The images are small in this article, to get a closer look at all of them collected together, download the PDF here.

The latest designs in this article show you how we’ve aimed to solve:

  • Navigation between different calendar views
  • Gestures to help quick navigation
  • Editing events
  • Creating events
  • How this will potentially look and feel

 

Different views

There are 5 different view templates inside the calendar app we are focusing on. They are:

  • Year
  • Month
  • Week
  • Day
  • Event

 


Navigating between different views using title header bar

You can move through the different views by tapping on the title header bar to toggle the view mode options. Just like our patterns, this title is scrollable – so that you can scroll through the view modes which don’t fit the width of the screen. Also like our pattern, swiping to the left or right moves along to the next or previous unit (year/month/week/day/event) in its category. For reference, take a look at Calum’s excellent post on this.

To get a better idea, click here to see a video of the prototype which formed the base of this navigation model and allowed us to test it out, comparing and contrasting it against other design directions. It was enough to give us a feel for the potential final build.

 

Navigating between views using spread and pinch gestures

To aid fast navigation for pro users and to also add an element of fun, we’ve decided to enable zooming in and out between views using finger spreading and pinch gestures similar to zooming in and out in a map app.

 Spreading fingers gesture: This zooms in to the next view; the next view offering more detail, close up.

     E.g. A user spreads when on the year view. This opens up the month view. Spreading on the month view opens up the week view, and so on.

Pinching fingers gesture: This zooms out, to a less detailed view – the previous view in the view hierarchy.

     E.g. A user pinches on month view, the system responds by taking the user to the year view.

 

An event

An event has several detail fields. In order of appearance they are:

  • Event name
  • Time
  • Description
  • Location
  • Guests
  • This happens (how many times does this event happen in the series? Or is it a one time event?)
  • Remind me
  • Timezone

 

Editing an event

A bottom edge swipe on an event page brings up the toolbar with the edit button.

[NOTE: toolbar menu options within the calendar and across the whole system have not been finalised, this image of the toolbar is a placeholder to give an idea of how to edit]

The edit mode shows the boxes around the fields allowing the user to type and change the event details. The toolbar in edit mode is always present. It shows cancel and save options.

 

Creating an event

A bottom edge swipe on year, month, week and day views brings up the toolbar with the option ‘New’ to create a new event. Pressing this brings up a similar template to the ‘Edit’ mode, the only difference being the blank forms.

 

Visuals

The visuals in the image below are an exploration of how this can potentially look and feel. This is still very much still in progress, but gives a strong hint of what’s to come.

 

 

I hope you like our thoughts and directions on this, and that this article gives a stronger idea of what the final app will look and behave like.

Watch this space for my upcoming articles focusing on: an in depth look at events – (including guest contacts, location views, time and date pickers etc) calendar synching with external accounts, calendar settings, and calendar mode inside the indicators.

Read more
niemeyer

Since relatively early in the public life of the Go language, I’ve been involved in pushing forward packages that might be used in Ubuntu, including making the compiler suite itself happier in such packaged environments. In due time, these packages were moved over to an automatic build system, so that people wouldn’t have to rely on my good will to have up-to-date packages, nor would I have to be regularly spending time maintaining those packages. Or so was the theory.

It’s well known that the real world is not so plain, though, and issues became much more regular than hoped. Some of the issues were caused by changes in the build conventions of Go, others self-inflicted due to my limited knowledge of the extensive conventions around packaging, or bugs in indirect dependencies of the process, and more recently the sub-optimal scheduling algorithm used by the build farm has driven the builds to a halt.

So, the question is how to get out of this rabbit hole, but still give people a convenient way to use Go in Ubuntu.

Enter godeb, an experiment that dynamically translates the upstream builds of Go into deb packages. In practice, it’s a simple standalone Go program that can parse the build list, fetch the requested version, and in memory translate the contents into a correct binary deb package.

Since you cannot build a Go application without a Go compiler first, there’s an x86 32-bit binary and an x86 64-bit binary of godeb available for download. After the compiler is installed, godeb may be fetched and rebuilt locally by running go get launchpad.net/godeb.

Once the godeb binary is available, it’s easy to get up-to-date packages:

$ ./godeb install
processing https://go.googlecode.com/files/go1.1.1.linux-amd64.tar.gz
package go_1.1.1-godeb1_amd64.deb ready
Selecting previously unselected package go.
(Reading database ... 488515 files and (...) installed.)
Unpacking go (from go_1.1.1-godeb1_amd64.deb) ...
Setting up go (1.1.1-godeb1) ...

It figures what the most recent build available is, downloads, translates, and installs it, asking for a password via sudo if necessary. Running godeb install again will fetch the latest version (or the requested one) and replace the currently installed package. Package installs default to the same architecture of godeb itself, and may be changed by setting the GOARCH environment variable to 386 or amd64, borrowing from a Go convention.

New releases of Go are immediately available, and so are the old ones:

$ ./godeb list
1.2
1.2rc5
1.2rc4
1.2rc3
1.2rc2
1.2rc1
1.1.2
1.1.1
1.1
(...)

$ ./godeb -h
Usage: godeb <command> [<options> ...]

Available commands:

    list
    install [<version>]
    download [<version>]
    remove

For the time being, I’m holding up maintenance of the Go PPA in Launchpad in favor of this system. Of course, you can still install the golang-* packages on Ubuntu 12.10 and 13.04 from the official repositories as usual.

Read more
Jussi Pakkanen

The decision by Go to not provide exceptions has given rise to a renaissance of sorts to eliminate exceptions and go back to error codes. There are various reasons given, such as efficiency, simplicity and the fact that exceptions “suck”.

Let’s examine what exceptions really are through a simple example. Say we need to write code to download some XML, parse and validate it and then extract some piece of information. There are several different ways in which this can fail: network may be down, the server won’t respond, the XML is malformed and so on. Suppose then that we encounter an error. The call stack probably looks like this:

Func1 is the function that drives this functionality and Func7 is where the problem happens. In this particular case we don’t care about partial results. If we can’t do all steps, we just give up. The error propagation starts by Func7 returning an error code to Func6. Func6 detects this and returns an error to Func5. This keeps happening until Func1 gets the error and reports failure to its caller.

Should Func7 throw an exception, functions 6-2 would not need to do anything. The compiler takes care of everything, Func1 catches the exception and reports the error.

This very simple example tells us what exceptions really are: a reliable way of moving up the call stack multiple frames at a time.

It also tells us what their main feature is: they provide a way to centralise error handling in one place.

It should be noted that exceptions do not force centralised error handling. Any Function between 1 and 7 can catch any exception if that is deemed the best thing to do. The developer only needs to write code in those locations. In contrast to error codes require extra code at every single intermediate step. This might not seem so much in this particular case, after all there are only 6 functions to change. Unfortunately in reality things look like this:

That is, functions usually call several other functions to get their job done. This means that if the average call stack depth is N, the developer needs to write O(2^N) error handling stubs. They also need to be tested, which means writing tons of mock classes. If any single one of these checks is wrong or missing, the system has a latent bug.

Even worse, most error code handlers look roughly like this:

ec = do_something();
if(ec) {
  do_some_cleanup();
  return ec;
}

What this code actually does is replicate the behaviour of exceptions. The only difference is that the developer needs to write this anew every single time, which opens the door for bugs.

Design lesson to be learned

Usually when you design an API, there are two choices: either it can be very simple or feature rich. The latter usually takes more time for the API developer to get right but saves effort for its users. In the case of exceptions, it requires work in the compiler, linker and runtime. Depending on circumstances, either one of these may be a valid choice.

When choosing between these two it is often beneficial to step back and look at it from a wider perspective. If the simpler choice was taken, what would happen? If it seems that in most cases (say >80%) people would only use the simple approach to mimic the behaviour of the feature rich one, it is a pretty strong hint that you should provide the feature rich one (or maybe even both).

This problem can go the other way, too. If the framework only provides a very feature rich and complex api, which people then use to simulate the simpler approach. The price of good design is eternal vigilance.

Read more
niemeyer

This week I found some time to work on another small spin-off from the juju project at Canonical, and I’m happy to make it openly available today: the xmlpath package, which implements an efficient and strict subset of the XPath specification for the Go language.

This new package will be used in an upcoming (and long due) revision of the goamz package API, which is currently limited by the fact that once the XML result returned by Amazon is unmarshalled into a static structure, any other data that the package wasn’t prepared to deal with becomes hard to access by clients. This problem is being solved by parsing the tree into an intermediary form which can then have XPath expressions conveniently and efficiently applied to it.

Path expressions currently supported by the package are in the following format, with all components being optional:

/axis-name::node-test[predicate]/axis-name::node-test[predicate]

Compatibility with the XPath specification goes to the following extent:

  • All axes are supported (“child”, “following-sibling”, etc)
  • All abbreviated forms are supported (“.”, “//”, etc)
  • All node types except for namespace are supported
  • Predicates are restricted to [N], [path], and [path=literal] forms
  • Only a single predicate is supported per path step
  • Richer expressions and namespaces are not supported

For example, consider this simple document:

<library>
  <!-- Great book. -->
  <book id="b0836217462">
    <isbn>0836217462</isbn>
    <title>Being a Dog Is a Full-Time Job</title>
    <author id="CMS">
      <name>Charles M Schulz</name>
      <born>1922-11-26</born>
    </author>
    <character id="PP">
      <name>Peppermint Patty</name>
      <born>1966-08-22</born>
    </character>
    <character id="Snoopy">
      <name>Snoopy</name>
      <born>1950-10-04</born>
    </character>
  </book>
</library>

The following expressions can be applied to it, with the indicated result as first match:

/library/book/isbn “0836217462″
/library/*/isbn “0836217462″
/library/book/../book/./isbn “0836217462″
/library/book/character[2]/name “Snoopy”
/library/book/character[born='1950-10-04']/name “Snoopy”
/library/book//node()[@id='PP']/name “Peppermint Patty”
//*[author/@id='CMS']/name “Charles M Schulz”
/library/book/preceding::comment() ” Great book. “

The API implemented allows compiled paths to be held and re-applied any number of times, concurrently or not. For example:

path := xmlpath.MustCompile("/library/book/isbn")
root, err := xmlpath.Parse(file)
if err != nil {
        log.Fatal(err)
}
if value, ok := path.String(root); ok {
        fmt.Println("Found:", value)
}

Result sets can also be optionally stepped over via an idiomatic iterator interface.

The performance of these operations is close to using the static unmarshaling currently implemented by Go’s encoding/xml package:

BenchmarkParse                 5000        613862 ns/op
BenchmarkSimplePathCompile     1000000     1983 ns/op
BenchmarkSimplePathString      1000000     1565 ns/op

As a reference, this is a similar encoding/xml operation, using a struct with a single nested field on the same document:

BenchmarkSimpleUnmarshal       5000        622519 ns/op

I’m hoping this will make our unavoidable XML interactions slightly less painful.

Read more
Martin Keary

This is a presentation of our ‘Paper’ Motion theme for Ubuntu Mobile.

The theme is informed by the ‘paper’ graphic style of the mobile OS and we have sought to accentuate it wherever possible. Rather than using more overt effects like page curling and folding, we have hinted at the theme by using multiple layers, ‘stacking’ and suggestive effects. Multiple layers of sliding paper can be observed in the animation of the switch button, stacking can be seen occurring on the icons in the launcher and an example of a suggestive page-turning effect can be seen during the ‘App Stacking’ example.

Read more