UDS Report: Day 1

Integrating Ubuntu Online Accounts [pad]

This discussion was mostly about feedback from app developers about how to use the new api and what requirements different apps have. There is new documentation being developed which will help developers get integrated and make use of people’s online accounts without having to write their own authorisation management code.

Concerns with the API were as follows:

  • Being able to support both Gnome and Ubuntu Online Accounts; would require a wrapper to negotiate between them.
  • Support for permissions/capabilities of each account can provide each app with only the permissions it needs.
  • Allow app keys to be used so targeting a permission or token to a specific app and not just the desktop as a whole.
  • How does this relate to the Freedesktop secrets API ? GnomeKeyring etc.
  • There was a need for more plugin documentation to help developers get to grips with it all.

Ubuntu Development Videos [pad]

This session was very frenetic with many people interested in making scripts and performances to update the developer video guides.

My job this cycle will be to put together some basic media and branding for use in developer videos as well as performing in one video when the scripts are written. Tasks have been divided into the steps: 1) script, 2) performance, 3) editing, 4) publishing. There is a task which will hopefully provide the documentation on how to do each part for everyone who hasn’t done these videos before.

Others not involved in the session will be needed, we need as many different people as possible to complete the documentation refresh.

Integrate a Paper Cuts toolbelt

This session fell into a hole, no one turned up and the room didn’t do anything.

Monday Plenaries

Today we heard about design community, valve’s commitment to Ubuntu (read more on OMG) and the importance of app developers and how we’re giving them a good time.

Error handling design guidelines [pad]

We were given a presentation about some of the problems that we have on the desktop presenting information when things go wrong. [link]

When cryptic errors occur, users are left baffled, powerless and sometimes even insulted. The guidelines are there to show developers how best to communicate to users and guide users out of any problems through suggestion and allowing recovery where possible.

Tone plays an important part of a message’s ability to convay useful information. An error should be both clean enough for the user and contain enough identifiable information for any tech support. this is a serious conflict and is the reason error messages need a lot of thought and attention. Nobody expects their app to have errors, but when they happen we want users to be congenial if not happy.

Ubuntu SDK Assessment Criteria [pad]

This session was filled with caution and the consensus was generally that because we don’t control the Ubuntu stack, we can not make guarantees about the APIs that might be involved in nailing down an SDK.

Thus we want to create an Ubuntu Kit for Software Development which does not commit Ubuntu to supporting applications developed using it beyond the version it was developed on.

There are lots of parts to development which should be documentation and in cases codified i.e. made into automated tools and scripts to reduce workload. No decisions on an SDK have been made and this session is mostly about investigations into making that decision.