Jaffa's Projects

In the latest Internet Tablet School editorial, The future of Nokia, Maemo and the Internet Tablets, krisse explains why a Maemo-based netbook makes the most sense for Nokia now.

Respectfully, I've never heard a more crazy idea:

• Maemo is a touch-based OS, which doesn't work well with a larger style keyboard.
• People who don't want Windows would find Mac OS X or Ubuntu Netbook Remix a much more compelling user experience on such a device.
• What on earth is the benefit of Maemo here, vs. an alternative OS?!
• The comments when the 770 was released were "where's the phone?", and although Nokia make lots and lots of non-phone devices (such as one of our DVB-T receivers), the comments about Nokia trying to break in to a crowded market (of laptop makers) would be easily compiled into an hilarious book.

IMNSHO, it's just plain bonkers to go down that line instead of a small, tablet form factor - however unproven that may in the end-consumer mainstream.

The call for nominations for the first maemo.org Community Council elections has been open for a couple of weeks now. But I wonder if the wider maemo.org is aware of just how important this could be for the future of the platform.

So, this post'll be syndicated on planet.maemo.org in the hope that we get more candidates putting themselves forward, and interest drummed up in the wider community in terms of asking the candidates more probing questions. Hopefully we can avoid the nastiness associated with the US presidential election :-)

Of course, I'm biased. I've thrown my hat into the ring: my candidature announcement has been sent to maemo-community. I recommend you subscribe if you're interested in shaping the future of Maemo, rather than "just" developing with it.

Picked up from Internet Tablet Talk, there're a couple of videos showing how bad the OpenMoko UI is on basic usability challenges.

What's interesting is that the small comparison with the iPhone shows how poor hardware (pressure-based touchscreen, bezel around the screen) combines with poor software implementation (separate apps => slow start-up times, little thought to the size of a usable target area) to emphasise the poor user experience. And, frustratingly, how many of the issues raised cut quite close to the bone for Maemo devices too :-(

Hopefully the UI changes in Fremantle (for example, #2564) will be a big help; and a concentration on finger usage may allow a more sensitive, different, touchscreen technology to be used in the N900. Will be very interesting to see the UI talks at the summit - see you there!

Following on from my earlier post, maemo.org: what next?, LinuxTag has now happened (and Quim very kindly used my open source triangle), and the 10 days brainstorm for the 100 Days community action plan, and 2010 Agenda have been launched.

My main focus in the earlier post was more related to the 2010 vision: what should Nokia do as soon as possible to really fully utilise an untapped area of the community.

However, what can the community do to organise itself and present more of a consensus view? Consensus by mailing list posts and wiki-edits just means the loudest - or most pushy - individual voices get heard. So, I suggest a Community Council, elected by the maemo community, to act as a filter/co-ordinating body to present a more unified view to Nokia - and therefore help them to help us.

Comments welcome below, or just make changes in the wiki!

I was invited, but unfortunately had to decline, to speak at the maemo track of LinuxTag 2008. The final topic, maemo.org: what next? is subtitled "mid-term: what Nokia should do + what the community could do". Whilst looking at whether I could attend, I started thinking about this topic. Below is the crystallisation of some of those thoughts which probably would've formed the basis of a few slides to kickstart discussion.

Where are we?

Since November 2005, we've had the N800 and N810; both spaced about a year apart. But whilst the release of the N810 saw its OS backported and released for free for the N800; the release of the N800 saw the 770 dropped in terms of official support.

All three releases had "device programmes" whereby key members of the community could get the devices at severe discounts. This had the advantage of ensuring key software and power-users could deal with the new devices; but meant that hackers who may have maintained support for the earlier devices didn't have to scratch that itch.

Nokia were criticised very heavily for their decision to drop 770 support. However, in their defense they've generally had a fairly open, but unguided approach, to community involvement. It seemed such a large company was having difficulty defining - let alone adjusting to - truly open, community-involved processes.

Recent developments such as the involvement of Niels Breet and Quim Gil have certainly helped here. There've been improvements to the maemo.org website such as karma and rating downloads & news articles which have definitely increased interaction. Quim's contact with the community both through official channels and the Internet Tablet Talk forums has been very well received. These are steps in the right direction, but more needs to be done.

Corporate interests in open source projects

There are three aspects to an open source project, especially when there's corporate sponsorship:

Open source triangle

Community involvement

Pushes sales and reduces costs: more software developed for a device; more community support for users; some aspects of software development being done by the community which can become headline items in sales packages.

Openness

Allows experimentation with a device: new operating systems; backported OSes etc. However may be viewed by suspicion by marketing teams wanting to make a large fanfare for an upcoming release.

Control

Essential for a company: what's going to be in a release, how it's going to be supported; ensuring the package as a whole has a consistent marketing message.

None of these are "better" than the others, and a true open source project - without any control at all - either splinters into a series of forks, or never gets enough traction or user-base to get that far. However, I'd suggest the best corporate-sponsored open source projects sit closer to the middle of the triangle than anywhere else. For example, if the 770 ecosystem was closer to the centre, the "hacker editions" may not have been a cost Nokia needed to swallow.

Are there "good" open source projects with corporate sponsorship? Sure! Amongst many others there are:

• Eclipse (IBM)
• Firefox (Mozilla Corporation)
• OpenOffice.org (Sun)

What Nokia should do

Nokia need to take action to really push community involvement. Nothing's got for free: if Nokia aren't seen to be committed to the community, why should the community be committed to Nokia? I'm sure we can have a discussion about where we are on the triangle, although I suspect there won't be much argument that we're closer to the bottom left than anywhere else.

Is this a bad thing? It depends. Certainly, being further towards the centre would mean - at least - the Hacker Editions could be maintained outside of the maemo.org team; other OSes such as Poky, Mamona and even Ubuntu Mobile could be got running on the device; the experts in the community could provide input into specifications, designs and even provide implementations. This'd mean:

• Somewhat reduced costs on behalf of Nokia;
• More devices being sold. Some people are looking for an entirely open device (see the interest in OpenMoko or Pandora). Others are looking for an open device on which they can run a software stack of their own choosing, such as Poky.
• Contributions from people who are personally devoted to the device, rather than being paid to work on it by their employer. That's not to say that the employees aren't doing a good job, or that they're not devoted to the device; but if someone's willing to do even some work for free, why look that gift horse in the mouth?

These are all good things, both to the end-users, the community and Nokia's bottom-line.

So, to increase openness and community involvement in maemo.org, I suggest the following to Nokia:

Default code position: open

The default position for all ITOS and Maemo code should be open source, unless there are legal and contractual reasons it shouldn't be the case. It should be possible for an external developer to tweak - say - the look and feel of the Media Player (perhaps cover.jpg album art support), rebuild it and share it in the community. Any component which is closed should have a page in the wiki or somewhere else explaining why that is closed source, and details of the API that component is supposed to provide to the system.

Work in the community, not with the community

• Nokia's internal bug tracker should be closed to anything but issues with upcoming, unannounced hardware: all software bugs and development features should be in the maemo.org Bugzilla or component-specific open bug trackers.
• All components should have discussion - even between Nokia staff - on open mailing lists and IRC. All high-level designs should be discussed on maemo-developers to get most involvement and input. Low-level implementation details should be discussed on component-specific mailing lists.
• Discuss software roadmaps on maemo-developers, engage the non-Nokia community to feel like they're not just contributing into a black hole; but are involved in the decision-making, policy-making and strategic direction of the platform on all levels.
• Improve the tooling for people wanting to rebuild an ITOS component, possibly even including the ability for third parties to produce their own FIASCO images. Indeed, for the community to help with the Hacker Editions, this ability is essential.

Raise the bar for third-party developers

Put considerable effort into integrating, homogenising and ensuring consistency between all of the built-in applications. Polish here will encourage application developers to raise their game. I've tried to avoid an iPhone comparison, but look at the quality of third-party iPhone apps, even before the official SDK was launched.

Increase the ease with which applications can be fully Hildonised and integrated into maemo

• It's currently too easy to half complete a port, without any addition of battery-management functionality; proper load notification; proper backgrounding etc.
• Effort could be made, for example, to make GtkMenuBars a more pluggable interface: Hildon would use a plugin which rendered it as a fixed point pop-up, the Mac OS-inspired desktops would use a plugin which rendered it at the top of the screen, the ROX-based distributions could have a fully popped up menu. This should also decrease the effort to port applications.
• Similarly, HildonWindow is a hack to get default themes working. This hack would be better put in the window manager, rather than requiring changes to every application.
• Work closely, and openly, with other companies using Hildon as an interface to effect these changes; such as Intel and Ubuntu; to ensure that Moblin, UME and maemo don't splinter and that porting applications between them, and innovations made by one company can be reused without being dismissed because of "Not Invented Here" syndrome.

Some of these may be too much for Nokia to swallow as a company not used to openness. There will be comments within Nokia that this will open themselves up to too much competition; that if their entire software stack is open someone else will be able to clone it. So what, though? Be a hardware company; be a focal point; sell services to your competitors building similar hardware; sell to consumers a polished device with an active community.

I strongly believe taking these actions will increase the openness of ITOS (and hence maemo) development and massively increase the participation of the non-Nokia community. For example, I and at least a handful of others, would commit to regularly commenting, reviewing and participating in design reviews of high-level (and perhaps even low-level) specifications; if only we were asked.

Nokia have a large, untapped resource of professional, enthusiastic programmers; artists and users, who would be willing to effectively work for Nokia for almost nothing: just an acknowledgement that their input is being listened to, visible changes resulting from their work and - perhaps, just maybe - inclusion in the next device programme ;-)

X-Fade's been working hard and bug #2347 has been fixed. This now means that the official maemo.org downloads catalogue can now contain non-tablet software such as tablet-encode.

Hopefully this'll boost the profile of things like mediautils to a wider audience.

Steps are simple:

1. Go to add new application (logging in if necessary) and fill out the fields as detailed.
2. One particularly cool feature is the ability to put in a direct download URL for the "click to install" arrow.
3. Don't try and attach any screenshots until you've first saved the details; there's an issue with that and it's best done when editing the page after the first save.

I've raised a feature request that the download statistics available to extras(-devel) users are picked up from garage.maemo.org for a more integrated system.

tablet-encode has had v2.18 released. Notable new features in this release include:

• A new "mplayer" preset with a very high bitrate.
• Ability to define your own presets and options in ~/.tablet-encode.conf.
• Ability to rip all the episodes off a DVD with a single option.
• Add support for Freevo FXD files as pointers to the actual video.

The --episodes option is particularly cool; ripping a TV series' DVD for (say, a long flight) is now a 3-step process:

1. Attach N810 via USB.
2. Insert DVD to computer.
3. Run:

   tablet-encode --episodes dvd: /media/nokia-sd/Video/
   

It's hard to imagine it being any easier! Of course, at some point the GUI should support showing you thumbnails of each of the titles so you can select the ones you want to rip. If anyone's got any time, and experience with Perl Gtk+, I'd be happy to accept some help in improving the GUI version.

I'd also like to thank GeneralAntilles, rm_you, Marius Gedminas, Mike Lococo and divinerites for all their help with this release.

A quick follow-up to my post on improving application start-up usability. I've done a very rough & ready mockup:

A higher-quality (but not any better put together) AVI can be downloaded (333KB).

The announce of the iPhone SDK has revealed some interesting facts; including a particularly ingenious (and simple) way Apple have improved the user experience of starting applications.

It's a bit of a cheat, but with sound User experience Design (UxD) principles behind it: two small waits are better than one long one. It's why we have "please wait" messages on everything from ATMs to websites, and Hildon Desktop's own "Application loading" info messages at the top-right. The user feels the action is progressing whilst complex operations are occurring underneath.

Therefore, Apple's idea is simple: display an image of the application completely empty of content, but with the structure of its window in place as quickly as possible after launch. When the app actually opens its window, it replaces the image.

For example, the "launch image" for the iPhone's Settings app is shown on the left, with the actual app's first window on the right:

...and the Stocks app:

I've just posted to maemo-developers an idea for similar within the Hildon Desktop. For example, imagine the instant you selected File Manager from the launch menu, this image was shown:

The normal "File Manager loading" infoprint would also be shown, and then the File Manager proper would open and replace it.

Although it's "only" a few seconds we're talking about, I think it could really make ITOS feel more responsive. Given we've only got a 400MHz processor to play with, the impression of speed is just as important as the making the startup time as low as possible (but with the overhead of shared libraries etc. there's a lower bound which is achievable).

Comments, as ever, welcome.

The iPod Touch has recently gained a location ability, despite not having a GPS. How?

A company, called Skyhook Wireless have driven around the US and Europe with a laptop and a GPS; recording the position and strength of every wireless access points SSID they detect.

A device, such as the iPod Touch, can have a database - or use the Internet - to go the other way: "I can see these APs with these signal strengths. Where am I?". A colleague tried this in the centre of London and it was accurate to within 20m!

The advantage of this on Maemo are obvious: for the N800, it provides a mechanism for knowing where you are (in built-up areas) without an external GPS. On the N810 it can be used to prime the built-in GPS for faster lock times, and get a lock within buildings etc.

Skyhook make money licencing their technology to OEMs etc., however their SDK is downloadable and, once you get through the signup process, you find they've got ARMEL binaries for Maemo 3.1 (i.e. OS2007).

Unfortunately, I don't have an OS2007 device, and trying to get it working on OS2008 ultimately resulting in a segmentation fault. They've yet to reply to the email I sent asking if they've got a Maemo 4.0 (chinook/OS2008) SDK available.

However, this is promising for two reasons: 1) they're aware of Maemo; 2) it might be something Nokia is looking at licencing.

All of this could be tied together with GeoClue and at some point we might take advantage of location-based services. That'd be a cool day.

I've just sent an email to maemo-developers asking for feedback on an idea:

RFC: Proposal to solve multiple repository, poor QA situation

There is an increasingly acute problem with the Internet Tablets, the number of repositories a user has to install to correctly get some software is growing. It has been regularly discussed on maemo-dev that the best thing to have would be for all packages to be in extras - especially since in OS2008 it is now included by default (albeit disabled).

I fear that the gronmayer.com database of repositories - no matter how useful it is - will only exacerbate the situation.

What I'm suggesting is an easy way for developers to upload to extras, with a group of volunteers doing the legwork of signing and uploading the packages, doing quality assurance and so on.

This should make it easier for developers (no need to have their own repos any more), and easier for users since they'll only need to enable the extras repository and know that none of the software in there will brick their device, be uninstallable etc.

The QA will also allow users to use the categories of the Application Manager more, as the gatekeepers will strictly limit the categories that are used by the packages flowing through them.

Of course, this system will be voluntary: I'm in no position to dictate that everyone use it, but hopefully there'll be sufficient benefits to everyone to make it a viable scheme.