OK, these are hard words, but sometimes I'm really angry about Maemo. But every time I tested another smartphone (Android, Symbian) I wasn't much happier. There are a lot of things I love about Maemo like the openness or the availability of my favorite Linux applications instead of some restricted "Apps".

You might say, please write a bug report. But I think this is not about a specific bug, it's about a general policy, a philosophy, how things should designed. My aim is to supply a bit to the discussion how MeeGo Handset UX should be designed, that everybody (except the competitors) is happy. I hope you see this as a constructive article and not as a "flame" post.

1. The phone application seems not to have priority

The phone application shall be the king, the unquestioned king. All other applications should step back and be quite as long as this crucial part is in the "room".
^ OK, it's a smartphone and I can do a lot of amazing stuff, but it's still a phone. The programs who handling phone calls should have absolute priority in case of memory, CPU and UI. I don't care how much applications are active. If I receive a phone call I want be able to accept or deny it immediately. I won't wait a second. Accepting a call and ending a call are the most crucial tasks on a phone.
It's interesting what a touchscreen can do and where a hardware button is better. I think unless the touchscreen recognition is (exactly, not roughly)as fast as a button event handler, there should be a button on the devices for accepting/ending calls.

2. Such a latency

It's nice when a UI looks good and has fancy animations, but it must perform fast on all planned hardware. Do I asking to much, when I want to listen a Internet radio stream via 3G with my bluetooth headset while I'm checking my emails or browsing online? If the system isn't capable to allow real multitasking it should be restricted by design (see Apple iOS). If you promise something to me, I want use it.

I have no pity for the system if it react really slow on my inputs. On mobile devices you make a lot of typos when you write a text, so direct feedback is crucial. All buttons, dialogs etc. should react immediately, at least the should report that they are working. In Maemo 5 on the N900 I must wait two long seconds after I clicked on a chat account until I get the "Edit Account"-Dialog. In the "Settings" application it sometimes even longer. Another show stopper is the long time the animation between landscape and portrait mode needs. But these seem to be solved in MeeGo.

Form follows function means in this case fanciness follows speed. This should be a dogma.

3. I don't get any feedback from the system

Especially in cases where the latency is high, the user should get feedback from the user interface. But feedback is an old recommendation in the usability scene. The user should every time know how the system state is. Why there isn't a symbol permanently showing me, that Shift or Fn is locked? The message which appears in Maemo 5 isn't enough. We talked about the relationship of form and function. If there is a scroll bar, it should be there permanent. It might hurts some designers hearts, but we talking about an everyday-device, not about art. Beautiful interfaces who respect usability are perfect, but a nice screen layout alone is nothing.

4. The UI is not consistent

Style guides aren't their only because someone had too much time. If applications and especially user interfaces follow a special and every time similar philosophy, then the users know what they can expect. Style guides aren't only guides for developers and designer, they are or better their results are guides for the user.

I don't understand why the QA-Process for Maemo Extras Testing is explicitly excluding the appearance of applications from the evaluation. Apple was criticized for their rigorous policy in other points, but I think their policy for the UI design is just right.

Another example: Why I can't switch from the (I call it) quick contact view to edit. If I access a contact from the address-book it's no problem. Both contact views looks similar, except the first one just isn't full-screen. As a user I don't care, that they might be different widgets.

Not only users need consistency. Developers need them, too. Think about the big jumps from Diablo to Maemo 5 to (in Amsterdam announced) Harmattan, to MeeGo. Is my application running on the next version, too? This might be a big question before you start to develop for a specific platform, nonetheless you have commercial aims or are an open-source developer. If developers can concentrate on their application and UI instead of learning new toolkits and SDKs, then the users will profit, too.

5. Not enough User-centric Design

PR1.2 and PR1.3 (Maemo 5 releases) fixed a lot of stuff people wonder about. We live in the 21th century, so why I can't delete a received mail directly (opened straight from the notification). I still can't navigate from such a mail to the a previous or next mail.

Sometimes I want to call from a different phone or someone asks me for a number. Users want to a address book like in the old days. Sending a contact via bluetooth is nice, but think of different user scenarios, too. Now with PR1.3 we have a zoom, which is great. But it's not easy to access it (Menu -> Zoom). Is there a shortcut? Why isn't it double-tap, something easy and convenient?
In general everything important should be big. Buttons should be used without special motor skills (in German we say "sausage fingers"). Think of bad weather, shaky public transport and 1000 other non ideal situation. But think also about, what is easy to remember. Which structure and layout make sense for the most users.

Because their isn't the average user, think of flexibility and customization. I have set up three mail accounts. I would love to get the mails including attachments from the first one always, from the seconds only via Wi-Fi and checking the third only manually. With Modest (Maemo client for mails) it's not possible. Another example: you cant choose custom alarms for calendar entries. You have a handful of choices from 0 minutes before up to one day, but choosing a custom date seems to be too much.

6. These damn regressions (Still missin' my old phone)

I know, software development is hard work. Sometimes you improve one part and has a regression on another one. I'm talking about big regressions. I should be able to do everything with a N900 (or successor), what I was able to do with an dumb phone (like Nokia 1200 or Sony-Ericsson W810i). All classical scenarios should work on the smartphones. If friends ask me about the N900, I answer them you can do a lot of crazy stuff from Twitter to Terminal, but don't try to do phone calls.

Your opinion

I hope you see my intention and points. I would love to see your comments, either here, in your (micro)blogs or from face to face at the MeeGo-Conference in Dublin.

P.S.: If you write a comment, the Spam prevention ask you, what's my first name is... ;)

Mac-User haben schon länger in iChat das unscheinbare Bonjour als Protokoll verfügbar. Apple bezeichnet damit ihre Zeroconf-Funktionalität. Ohne Konfiguration (Zero-Configuration) sollen Netzwerkdienste zugänglich sein, etwa Drucker, Dateifreigaben oder eben auch Chat. Diese Technologie ist seit einiger Zeit auch unter Linux und anderen Unixen unter dem Namen Avahi verfügbar.

Der Chat selbst ist eine Abwandlung von XMPP (aka Jabber), wurde in der XEP-0174 spezifiziert und hört auf den Namen link-local XMPP. Eigentlich wird in dieser XEP weniger XMPP spezifiziert, sondern hauptsächlich die Verfahren für das mDNS (Multicast-DNS). Der XMPP-Anteil unterscheidet sich kaum (warum auch) vom "Original", lediglich Authentifizierung beim Server fehlen, die Verbindungen werden zwischen den Chat-Partnern direkt aufgebaut und Online/Offline-Benachrichtigungen werden via mDNS übermittelt. Das Kommunikations-Framework Telepathy implementiert dies in der Komponente mit dem schönen Namen "Salut".

Genug der Theorie. Ich wollte mir das ganze anschauen und dazu ein Nokia N810 Internet Tablet mit Maemo und ein Desktop-PC zur Kommunikation via local-link XMPP überzeugen. Auf letzterem ist Ubuntu installiert, welches seit etlichen Versionen Avahi vorinstalliert (was nicht ohne Kontroverse ist). Ausserdem kommt dort als Chat-Client Empathy zum Einsatz, welches wiederum auf Telepathy basiert. Hier genügt es das Paket telepathy-salut zu installieren und ein zusätzliches Konto anzulegen, wo lediglich ein Name eingetragen werden muss (also nicht ganz Zeroconf).

Auch die Chat-Applikation unter Maemo verwendet Telepathy (welches ursprünglich im Auftrag von Nokia für Maemo entwickelt wurde). Leider findet sich in den Standard-Repositories nicht die Erweiterung für Salut. Ich fand aber diesen Blog-Artikel mit einem Verweis auf eine Anleitung, um Salut, Sofia (SIP, mittlerweile per Default dabei) und Haze (Telepathy-Wrapper auf die libpurble von Pidgin). Dieser bin ich zunächst gefolgt, aber ohne Erfolg, da eine Abhängigkeit für Haze nicht erfüllt wurde, was mich aber ja nicht interessiert. Ich habe die benötigten Pakete dann einfach von Hand installiert. Daher meine ich, es reicht via diesem Repository:

deb http://packages.collabora.co.uk/maemo diablo salut

und dem Klassiker Maemo Extras die Pakete avahi-daemon, telepathy-salut und osso-accounts-plugin-salut zu installieren. Anschliessend ein neues Chat-Konto einrichten und da wieder Salut wählen. Wenn sich dieses Konto nicht verbinden will (Status-Icon blinkt grün-rot), liegt es unter Umständen daran, dass Avahi nicht läuft. (Bei mir war es nicht mal installiert... )

Dass nicht während meiner rtcomm-Odysse vielleicht doch etwas wesentliches installiert wurde, kann ich leider nicht versprechen. Try and Error, Kids!

Ich bin echt begeistert. Mit Ruby, Netbeans und Glade mal eben ein kleines Programm geschrieben, was Daten von und zu einem GPS-Handheld (hier ein Garmin eTrex) überträgt. Es ist dabei lediglich eine kleine GUI für das Kommandozeilen-Tool gpsbabel.

Zunächst mit Glade3 sich die GUI zusammen geklickt und als XML gespeichert. Dann mittels ruby-glade-create-template den Ruby-Code generieren. Hilfreich war dieser Blog-Artikel von Rob welcher eine kurze Einführung zur Verwendung von Ruby mit Glade gibt. Der generierte Code muss aber noch minimal angepasst werden. An passender Stelle, etwa der initialize-Methode holt mensch sich das Window-Widget und macht es sichtbar.

 # Main Window aus Glade holen
 @main = @glade.get_widget("main")

 # Main Window sichtbar machen
 @main.show_all

Wenn Ihr in Glade schon alle Signale setzt kreiert das Ruby-Skript gleich auch alle Methoden, um die Events zu behandeln. Anschliessend diese mit der Logik füttern und - Ratz-Fatz - ist alles fertig.

Aber ich kann doch gar kein Ruby? Na gut, Java und Python hab ich ja schon gemacht und das bissl Syntax hab ich mir weitestgehend bei Hackety Hack angeeignet (und ein klein wenig auch bei den Nachbarn und meinem Mitbewohner Rat gesucht).

Die meiste Zeit beanspruchten die Überlegungen für eine (hoffentlich) sinnvolle, grafische Oberfläche. Hier spielt das (nicht ganz stabile) Glade seine Stärken aus: Elemente lassen sich beliebig hin und her schubsen. Viele sinnvolle Elemente, wie etwa der About-Dialog sind schon vordefiniert und lassen sich mit minimalem Aufwand einrichten. Angeblich soll ja GTK+ in C nicht so schön zu programmieren sein, aber mit Glade finde ich es doch sehr hübsch und effektiv.

Wer nun wissen will, was ich da fabriziert habe, kann in den Code hineinschauen und sich gerne gTrex 0.0.1 herunterladen. Über Kommentare zu diesem noch nicht aufgeräumten Ranz-Code freu ich mich.

Netbeans hat ausser Syntax-Highlighting und das Programm aufrufen nicht viel gemacht, selbst eine brauchbare Code-Completion konnte ich nicht feststellen. Falls jemand weiss, wie letzteres für Ruby/Gtk+ einbinden kann, wäre ich für Hinweise dankbar. Ansonsten war rbbr noch beim aufspüren gesuchter Methoden hilfreich. Mensch ist ja schon von Java + Eclipse sehr verwöhnt, besonders der exzellenten Dokumentation via Javadoc...

Jetzt gilt es die Fehlermeldungen zu verarbeiten und ein sinnvollen Workflow zu implementieren. Der Filechooser-Button muss auch weg, da dieser eigentlich nicht für das Speichern gedacht ist. Die GTK+-Entwickler können sich einfach nicht vorstellen, warum mensch sowas benutzen sollte? Paar weitere Punkte zur Verbesserung stehen schon in der entsprechenden Tomboy-Notiz.

Links

• Ruby-GNOME2
• gpsbabel
• GTK+ and Glade3 GUI Programming Tutorial - Part 1

Vermehrt erreichen mich verzweifelte Anrufe, ob es mir gut geht, ich sauer sei oder sonst was nicht stimmt. Denn warum sollte ich sonst die ganzen Jabber-Nachrichten unbeantwortet lassen?

Der Grund des Übels liegt in meinem Spieltrieb. In der Post-GUADEC Euphorie habe ich meinen Jabber-Client gewechselt. Statt dem nun weitestgehenden brauchbaren Gossip verwendete ich dessen auf dem Kommunikations-Framework Telepathy basierenden Fork Empathy. Daher sind wohl eine mir unbekannte Menge an Nachrichten bei mir nicht angekommen. Ob wirklich Telepathy/Empathy schuld sind, oder nur mein Jabber-Server, weiß ich nicht. Schreibt mir doch bitte eine E-Mail, wenn Ihr Euch von mir kommunikativ vernachlässigt fühlt. Bitte gibt an, von welcher Jabber-ID Ihr an welche meiner Jabber-IDs geschrieben habt.

Alternativ könnt Ihr auch meinen öffentlichen Jabber-Account prometoys@jwchat.org eintragen und anschreiben.

Was ist denn nun das richtige Wiki für Maemo? Angeblich das, aber das SDK Tutorial ist woanders...