Customers have to specifically decide on a feature set, not just on the platform

It’s not enough to get “an Android phone”. There are two major differentiators on the Android platform that requires customers to look close to really get what they want: 1) the OS version and 2) the specific device capabilities. These two are interconnected (a device usually only comes with one specific OS version), but two devices with similar hardware can perform quite differently with different OSses.

The major differences customers can experience are along these lines (in no specific order):

• screen size
• networks supported (3G/WiFi,GSM)
• keyboard / touchscreen
  • multi-touch or just single-touch
    • (in the multi-touch case there are different qualities of multi-touch as well (number of simultaneous touches supported, robustness of detection)
• camera
  • sensor quality
  • flash (yes/no/type)
  • front-facing camera (yes/no)
• GPS (yes/no)
• pre-installed apps*
• fundamental look and feel of the apps on the device*
• availability of fundamental apps like navigation*
• availability of tethering
• size of internal memory
  • this is a big issue because pre-2.2 devices cannot install applications on SD cards and this limits the amount of installable apps dramatically
• Google certification*
• enterprise security features *

the items marked with a * will be subject to a future post because they require more detailed discussion

Many of these options that are not prominently advertised (and as such taken as a platform capability) make a difference for the applicability of your Android device (tethering? fundamental look and feel?). Also, all these options may lead to a Paradox of choice situation.

Now, to me it seems that the mobile devices market is mostly defined through devices, not so much through platforms, but that may be changing now. Apple delivers the iOS for different devices and Motorola calls it’s devices the Droids, so platform may be important.

The questions that remains to be answered: What are the defining properties of the Android platform from a customer perspective?

The Samsung mail client

Samsung has put their own email client with IMAP/POP3 support on the phone. And I’ve never used an email client with so many fundamental flaws:

• it considers all mail it has not read itself to be unread on IMAP. (Yes, IMAP!)
• you cannot copy text from received emails (!!!)
• it does not support threading
• folders are shown as an horizontal bar at the top. This is not helpful if you have 50+ folders
  • oh, and you cannot move/copy mails to folders anyway
• the “new mail” notification does not show subjects, only number of mails received
• responding to mail does a fullquote and puts the text to the top; and no, there’s no way to do it another way

And I forgot, it looks really ugly.

Fortunately there’s K9Mail on the Android market that does most of these things better. But for an out-of-the-box experience (how many people exactly will be spending time looking for alternative clients) this is really bad. You can do better, Samsung.

Samsung's Mail app

One of the most notable things (a 3rd generation iPod touch being my companion for over a year now) is the less-than-stellar performance of most things on the Samsung. I believe it’s caused more by the software than the hardware, the Samsung Galaxy sports a 1GHz processor and 512 MB of memory.

My most prominent (and hardest to bear) examples (using the unofficial Froyo images found on the web; performance was worse in 2.1):

• clicking buttons often  does not offer any feedback (> 30% of the cases, more like 70% if the phone has been running for some time)., so you’re always wondering if the phone actually recognized your clicks  This makes for a terrible user experience since it often takes 3-10 seconds to launch applications.
• When someone calls you, the phone rings, the screen goes dark and after around 3 seconds the screen lights up again and you see who’s calling. This is pretty ugly for a device that’s dominantly a phone! (This was really bad with 2.1, around 10 sec)
• The clock runs 7 minutes late after a single day of use. The C.L.O.C.K, can you believe it?
  
• battery drain is really bad. Even mild use of 3G (downloading one small app, checking facebook once, twitter twice) means that the battery is down to 25% ofter one day (no phone use). This means you cannot take this device with you (on a trip) if you cannot be sure that you can charge it overnight. This also makes the navigation applications useless because the battery will not survive a trip longer than 2-3 hours.
• applications seem to use blocking updates which makes the system unresponsive (instead of updating in the background in a separate thread). This should be blamed on the applications (since background updates are even advertised as best practice by Google) but the prevalence of applications that present a “wait or force close” screen after updates is high. Even Google’s Listen stalls on me every few minutes. I hope, developer education will solve this one.
• You see the “force close” screen much to often. This is almost certainly caused by generally low quality of apps in the Android market but even apps delivered stock with the phone crash way to often.

These are my top-level frustrations and I think there are conceptual reasons for them:

• The code produced by the Dalvik VM is still much slower than machine-specific code.
• the Android OS gives applications a lot of freedom (which is a good thing), allowing them to do things in a non-optimal way
• there is no review of applications enforcing strong quality standards. This is two-faced. It allows for innovation and crazy ideas but allows for a lot of bad user experience. I guess, even the apps produced by Google, Facebook or twitter might be better if they had to go through an Apple store-like review process.

In the end, it’s still really hard to write good, working software. It’s even harder to write software that has a good user experience. And it’s still a lot harder to do this for smartphone-type devices where functionality is more limited and user experience is the only thing that really counts.

I love that now there i strong competition to the iPhone, but (at least for me) Android does not deliver, yet. But I’m not giving up. The platform does have a lot of interesting concepts (think of Intents, e.g.).

Google wird nicht müde, in unglaublicher Geschwindigkeit großartige Dienste zu veröffentlichen, das Web voranzubringen und sich überall einzumischen, wo es was zu verbessern gibt, sei es Bildung oder Umwelt. Natürlich gibt es für sämtliche Google-Aktivitäten plausible ökonomische Gründe (manchmal mit ein bisschen Altruismus gewürzt), aber Google weiss, wie fragil seine dominante Position ist. Wenn die öffentliche Wahrnehmung von Google kippt, war’s das. Ein größerer Google-Hack mit Zugriff auf private Daten könnte dies verursachen..

I looked at WordPress while writing my Diploma Thesis and found that WordPress lacks important means for consistent type-checking:

1. There is no centralized definition (regexps and constraints) for all the data ‘types’ WordPress uses
2. There is no general agreement on exactly when and how input and output filtering and sanitation take place. This leads to ad-hoc solutions like the one causing the current vulnerability.

What WordPress really needs is a better architecture that solves the two problems stated above and as such makes vulnerabilities like this recent one very unlikely, not ever more ad-hoc hacks. Unless the WordPress project is willing to spend considerably effort on the architecture, using WordPress for professional means will become an intolerable liability. Software Engineering is about long-term stability and dependability, established in the process, not about “if you update your WordPress every few days, you’re safe” (as Matt Mullenweg suggested).

Die Bedienung ist komfortabel, es gibt automatische Vervollständigung der Adressbucheinträge und Vorschläge über Ähnlichkeiten in schon getaggten Bildern.

Big deal, Foto-Taggen kann Facebook auch? Falsch!

• Facebook benutzt (so weit ich weiss) keine Gesichtserkennung und die Markierung funktioniert nur mit von Hand gesetzten Quadraten. Es werden keine Bilderkennungsverfahren eingesetzt, es entsteht nicht mehr Information, als dass eine Person auf einem Bild ist. Man kann also nach Bildern mit bestimmten Personen (innerhalb von Facebook) suchen, mehr nicht.
• Google stellt durch die Gesichtserkennung eine Verbindung zwischen einem Muster (dem Gesicht) und einer Identität (Name+Mail bzw. Adressbucheintrag) her. Diese Information lässt sich prinzipiell dafür nutzen, ausreichend getaggte Personen (am Besten in verschiedenen Posen) in allen öffentlich zugänglichen Bildern zu finden. Die Muster, die Google sammelt, wären bestimmt auch nützlich, um automatische Personenerkennung für Überwachungskameras zu realisieren.
• Wenn man (zufällig) auf einem Bild ist (Google erkennt auch Bilder im Hintergrund und bietet diese zum Taggen an), muss man damit rechnen, getaggt zu werden. Man verliert die Kontrolle über die eigene Findbarkeit. (Auch wenn man die Personen, die zufällig im Hintergrund stehen nicht kennt und somit nicht taggt, sind diese möglicherweise von jemand anderem getaggt worden; es ist ein Leichtes für Google, die Bilder zu verknüpfen)

Google hat prinzipiell die Möglichkeit, die entstehenden Verknüpfungen zu nutzen, um auch alle Personen auf den Bildern zu erkennen, die Google sich im Web ercrawlt. Für mich stellt das eine neue Dimension des Privatspäreverlustes dar, weil selbst nicht-netzaffine Personen, die kein Material über sich selbst veröffentlichen, auf einmal im Netz per Bild auffindbar sind.

Ich glaube nicht, dass Google Böses mit den anfallenden, sehr wertvollen Daten vorhat. Aber alleine die Existenz dieser Daten birgt eine gewisses Risiko. Google sagt, dass es sich an geltendes Recht in den Staaten halten wird, in denen es operiert. Und wenn wir dann den nächsten Kinderschänderfall haben und “die Regierung” (oder der Volkszorn in Form der “Bild”) Google unter Druck setzt, Daten, die angeblich zur Verfolgung hilfreich sind, freizugeben…

Und jetzt? Alle Bekannten und Verwandten taggen? Weil das so praktisch ist. Oder lieber sein lassen? Die Verantwortung für seine Entscheidung muss jeder selber tragen.

Despite the fruitful discussion I’m still not sure about the feasibility of a “rich types in frameworks” solution. There’s not too much to be gained over a conservative approach used in e.g. Django (escape everything, use other markup languages than HTML).

Nevertheless, here’s the presentation…

Ein Business-Model definiert man üblicherweise in einer Sprache, die ausdrucksfähig genug dazu ist. Wieso bildet die ActiveRecord Implementation bei Ruby on Rails dann ausgerechnet einfach das Datenbankschema ab? In SQL99 gibt es zwei numerische Typen, drei Datumstypen und Strings. Wie bitte schön kann ich ausdrücken, dass ein Attribut eine E-Mail Adresse ist? Oder eine Postleitzahl?

Überall, wo die Postleitzahl benutzt wird, muss der Entwickler aufpassen, dass diese auch ja wohlgeformt wird. Das ist eine klassische Aufgabe, die man dem Framework überlassen will. Aber das Modell ist hat keine ausreichende semantische Tiefe.

Das richtige Ende

Django benutzt ebenfalls ActiveRecord, allerdings andersrum. Die Modell-Definitionen sind Python-Code, aus denen das Datenbankschema generiert wird. Hier hat man die komplette Ausdrucksfähigkeit von Python. Man könnte Validierungslogik und komplexe Bedingungen (“dieses numerische Feld darf nur Primzahlen enthalten”) formulieren.

Leider werden diese Möglichkeiten in Django noch nicht ausreichend genutzt. Nur einfache Typen wie Email oder Längenbeschränkungen können ausgedrückt werden. Für alles Andere muss wieder jeder Entwickler eine eigene Lösung finden und dabei Fehler machen.

Wiederverwendung

Damit die armen Entwickler von Webanwendungen nicht dazu verdammt sind, die immer gleichen Fehler wieder und wieder zu machen, sollte ein Framework auch eine Bibliothek von vordefinierten Datentypen (Name, Telefonnummer, URL, TextMitHTML) haben, die dann “sicher” in einer Anwendung verwendet werden können. Filterung, Validierung und Konvertierung (z.B. nach (X)HTML, JSON usw.) wären dann zentral definiert, vergessene Escapes (die einen grossen Teil der Injektionsattacken ausmachen) wären dann Schnee von gestern.

Fazit

• In Web-Applikationen könnte man viel mehr Funktionalität in das Applikationsframework auslagern, wenn man mehr über die Typen wüsste.
• Modelliere in der ausdrucksstärkeren Sprache, nicht im kleinsten gemeinsamen Nenner.

For now, there’s not much to see here. Please have a look at the wiki page about my thesis and a concept presentation I gave at the department on 11/06/2008:

Check back soon, I’ll update the page with early draft versions of the thesis. There will also be articles about selected topics of my research in the blog.