dretblog

Moving Birthdays Around

a while ago, i noticed that the iPhone contacts app is not smart enough to properly handle birthdays, because it always requires years and thus only supports birthdates (and not birthdays). that was an inconvenience, but at least one that could be worked around by always using some fake year for birthdays with unknown years (and the birthday app i am using on the iPhone even supports handling one specific fake year as an unknown year of birth).

recently, i ran into another problem with the date handling of the contacts apps, and this time it is is more than an inconvenience, because date handling seems to be broken on a conceptual level. what happened is that i switched timezones (traveling from the west coast to europe), and suddenly about half of my birthdays had shifted one day forward. i did not bother to reverse engineer the exact data stored by the contacts app, but this means that apparently, the app stores the timestamp of when you have entered a birthday, and then interprets this timestamp according to the timezone you're currently in. as a result, birthdays are stored as a combination of the date entered by the user, the time when the date has been entered, and either the timezone in effect when it was entered, or no timezone information (in the latter case, it is probably interpreted as a UTC timestamp later on).

all of this means that some of the birthdays i had entered magically shifted to one day later after making the trip (it would have looked even worse when traveling to japan, i guess; almost all birthdays would have shifted). and of course there is no user interface for looking at the time associated with a birthday, which means that it is impossible to figure out which birthdays did shift, and which ones did not. welcome to the wonderful world of iPhone simplicity and usability.

the bad thing about this bug is that it is not reversible (unless the contacts app also stores the information about which timezone you were in when you entered a birthday, which is rather unlikely). the problem is rooted in a misunderstanding of what a birthday is (it is a day or a date, depending on the model, but certainly not a timestamp) and carries this misunderstanding into the app's data model. if you really wanted to be fussy about the exact time of birth, you could extend it into a timestamp, but then you would need to capture the timezone for the place of birth as well, and this would take birthday information to a level of detail probably not interesting for the majority of users. also, very few people think of their birthday as shifting around in the calendar depending on where you were born and where you currently are; it's simply a day and it's that day depending on where you are on your birthday.

after going through the substantial user interface pain of entering about 100 birthdays, i now expect these to jump back or forth one day, depending on the timezone where i entered them, and the timezone i am in. this jumping back and forth will be unpredictable, because i cannot look at the timestamp associated with the birthday entries. for being heralded as a marvel of usability and utility, i have to say this particular detail of the way the iPhone manages contact information is not quite up to what i would expect from software being subjected to use cases (such as people traveling between timezones and expecting birthdays to be stable) and systematic testing based on those use cases.

40 Million Tracked iPhones

starting with the upcoming iPhone OS 3.0, the iPhone will learn a number of new tricks, most of them software-based. one interesting area to watch are the micropayments which are supported by the new OS; it will be interesting to see how that affects apps and the delivery of mobile services in general.

less visible, but more importantly, iPhone OS also means that starting next week, 40 million iPhones (this number includes the iPod Touch sales as well) will become traceable on the web. the new mobile safari will support the location API currently under development by the W3C. this might seem like a minor update, but it actually means that web sites are now able to locate and track users with GPS precision (if they agree to it).

user tracking on the web already is more widespread and concentrated than most people think, but location tracking adds a new quality to this picture. it also adds a lot of value, because browser-based location information allows to serve location-sensitive ads, which can be much more specific and targeted than the usual behavioral advertising strategies allow. so before you click on Allow when iPhone 3.0 asks you whether you want to allow mobile safari access to your location, think about the fact that this means you are essentially donating your location to behavioral profiling including your location trail.

the underlying design flaw is that the API as it is now allows 3rd party scripts unrestricted access to the location info. this is introduces the same problems that exist around 3rd party cookies, but there is no browser setting that allows you to control this. maybe browsers will have a preference for this at some point in time, if there is user demand for this kind of privacy setting, but as it is now, there is no such differentiation.

close to 90% of all major sites use trackers (here is a good WWW2009 paper about this), and it will be interesting to see how long it takes until these trackers start to also track location. my guess would be: not very long. and as soon as urchin.js/ga.js, probably the most-executed script(s) on the web, become location-enabled, location tracking will become a widespread thing on the web. location mining will become a fascinating and rich field, and it probably only is a matter of time until some agencies figures out that they would be interested to get access to these data sets so that they can figure out who is repeatedly hanging out in suspicious places...

Times Reader 2.0

the first version of the New York Times' Times Reader was built on the Windows Presentation Foundation (WPF) and was pretty well-done as a proprietary one-time project; the second version of Times Reader (Times Reader 2.0, ironically lacking any of the features you would expect from 2.0 products after the Web 2.0 term became a buzzword) has now been released. this time it is built on the new latest and greatest proprietary platform you can get your hands on: Adobe Integrated Runtime (AIR). the other option to do the same thing would have been to use Microsoft's Silverlight. there certainly is a pattern to that: NYT seems to believe that the most promising way to develop new and compelling ways of delivering newspaper content is to ignore the web.

given how much newspapers are struggling with economics and how to adjust to the new environment of the web, it is amazing and disheartening to see how little they actually understand about it. the WPF reader was kind of nicely done (as a standalone app) but suffered the fate of many of these apps: it required an install, which the vast majority of people will not do. it also required an initial install of the underlying framework, which for XP users meant installing the insanely bloated .NET 3.0.

on top of that, the installer was badly broken and in fact so badly broken that it was impossible to uninstall and reinstall, which rendered the application useless for many. and NYT simply stopped supporting it, because they probably ran into the problem that they had become software providers with many struggling customers, and handling this would have required substantial resources for a substantial period of time.

instead of learning from that fiasco, NYT now decided to simply switch proprietary platforms and stick with the install required model. now potential readers first have to install AIR, and then they can install the reader. of course this is a possible of doing it, but does this make this any sense? offline reading can be supported in browser-based apps with google gears and, this is the essential part, can be made optional so that people can enable offline mode if they think they will need it. this kind of design is called loose coupling and one of the hallmarks of well-done web architecture. and there is no install and this is actually a pretty important issue.

apart from that, being from Adobe, AIR is huge and resource-hungry, and the freshly installed reader quickly passes the 100mb memory consumption mark right after startup. this might be less insane than having a 100mb twitter client, but generally speaking, the question is: why choose a proprietary and install-only platform? let's look at the product manager perspective:

• choosing a proprietary platform makes the developers happy, because proprietary platforms come with nice (and expensive...) SDKs that allow developers to ignore the messy world of the web; instead they can live in the closed world of their choice.
• choosing a proprietary platform will result in nice and predictable demos, allowing the demo to ignore that the vast majority of users will never get to that point because they will not install either AIR or the reader app.

this is the recurring pattern in many of projects of this kind: product managers have little interest and incentives to switch to web-based solutions, which are less pleasant to design and develop, and don't have the slick visual effects of the proprietary platforms. who would need to step in? probably some CIO-level person, but then again, would they know enough about web and information architecture to understand the fundamental difference between AIR and the web? after all, the companies producing these proprietary platforms have gone to great lengths to capture the term Rich Internet Application (RIA) for them, which technically is correct (no web in there), but leads many people to believe that they are more or less web apps.

strategically speaking, programming yet another silo for content is what newspapers have done for a while now, and it will be interesting to see whether recent and future moves in the e-book market (such as the kindle and the upcoming kindle DX) will eventually make newspapers understand that whatever their future may look like, it most likely is not an electronic equivalent of the printed newspaper. however, the painful experience of reading newspapers on the kindle and the ongoing evidence that content producers still haven't started thinking in horizontals rather than in verticals make it unlikely to see really forward-looking products from NYT and the publishing industry in general.

maybe the ability to run simple micropayments for iPhone content through the app store will change the perspective of some content producers. but instead of seeing the potential for building an app for personalized content from a variety of sources, i am pretty sure we will just see another wave of verticals being developed. the interesting question is: will the newspaper industry's focus on verticals disappear faster that the newspaper industry? the NYT times reader 2.0 looks like an indication that the publishing industry is determined to stick to verticals. let's hope amidst all the layoffs they also hire some people who actually understand the web and web architecture.

Flashy iPhone

while the next iPhone model may still be a couple of months away (version 3.0 of the OS was recently announced, and most people expect an updated phone version as well when the OS will be released this summer), there is one thing i really hope it will have. an LED. at some point in time, apple realized that the screen-only approach is inconvenient when you actually missed a call or a message, because, well, you missed it, and thus you are not necessarily switching on the phone to check for messages on the display. as an iPhone owner, you might get used to doing this all the time, but if this is what happens, it is a sure sign that the designers forgot something important. so apple added a feature (i don't know with which OS release) which lets the phone repeatedly ring for messages. but there is no such thing for missed calls, and the repeated ringing is a nuisance, particularly at night. maybe this was the best the designers could come up with as a software patch, but there would be a much better way of doing this.

my first mobile phone (back in 1998) was an ericsson SH888 (it was great because it had a built-in modem and IrDA; those were the pre-GPRS days). it was extremely expensive, had a bauhaus-kind of forms follows function beauty (which i actually liked), and was built like a rock. what it also had was a green LED that emitted very short pulses every few seconds as a power indicator. and when there was a notification on the screen (for a missed call or a received message), the LED switched to faster blinking. very simple, but highly efficient. and over time, i also liked the constant power-on blinking of the phone, because it allowed to find the phone in the dark easily, and since it was just a very short pulse, the blinking never was annoying.

my second mobile phone (2001) was an ericsson T39m, the first WAP phone available and absolutely pathetic in this department (not ericsson's fault, just the general stupidity of building a parallel web for mobile phones). it even had POP-based email, which was insanely expensive due to the ridiculous data plans available back then (this one had GPRS). also, reading email on a three-line display was not terribly convenient. one funny thing about the T39m was the messed up firmware (with regard to the little LED which it inherited from the SH888). while the LED still switched to fast blinking as long as the screen backlight was switched on for displaying a notification (missed call or received message), it switched back to slow blinking as soon as the screen backlight was switched off. this minor bug annoyed me to no end, i was so used to simply look at the LED to check for missed calls or messages that i realized how convenient that had been when it was no longer possible. i even brought it to a dealer to get a firmware update just to get the LED fixed, but as it turned out, that part of the firmware was not fixed in the new version i got.

what i want for the next iPhone is such an LED. i am sure apple designers would choose a white LED and teach it all kinds of tricks (such as fading) to make it look better, but the basic idea of having some kind of notification without having to switch on the phone would be extremely useful. plus the added benefit of being able to find the phone at night. and i am sure battery life would not be affected significantly by this, and it also requires almost zero additional space. it could be used to visualize timers and countdowns without having to look at the screen all the time. it would allow more subtle phone ringing than the not-so-subtle vibrate. and if the LED would also get an API, additional uses would be possible by allowing apps to access it. maybe it could even by used by push data, so that external requests could trigger it. i have no high hopes for this to actually happen, but it definitely would be nice to see apple's attention to detail coming to the conclusion that an additional notification mechanism would be useful in a variety of ways.

The Rise of The Micropayments

now that apple has revealed its plans for the iPhone 3.0 software, one of the exciting things about it is what apple calls In App Purchase: Allow users to purchase content or services from your application using the Store Kit framework. This new framework handles the financial aspects of the transaction, processes payment with the iTunes Store, and provides your application with information about the purchase.

this may actually turn out the be the return of the micropayment. apple's App Store was the first successful way to get an ecosystem of mobile apps off the ground; and it was quickly copied by almost all major mobile OS vendors. it was what made me make my first purchases in bed, browsing featured or popular apps and buying some relaxing game. or interactive fish. whatever, it definitely introduced a model where purchases are done on the level of an impulse buy, which is great for small-scale business.

with this model being extended to within apps, apps can start charging the same small amounts for content, or access to advanced features. it'll be very interesting to see how this feature develops when 3.0 becomes available this summer, but i would not be surprised to see a huge wave of successful micropayment-based apps, disproving the micropayments will never work mantra repeated for such a long time.

another interesting aspect of this is that apple gets to keep their usual 30% share of every purchase. that's what i would call a substantial margin. if this new feature really takes off, apple will make tons of money with it, and at some point in time providers will ask why apple charges about ten times as much as credit card companies. and the answer to that is: because you can do what you like when you have a monopoly.

iPhone 3.0

while i haven't touched my iPhone To Do List for quite a while, the rumors around the unveiling of the iPhone 3.0 software roadmap tomorrow made me look at the list again. even though i never updated the list for the 2.0 versions of the software, many of the issues are still open. some sites say that cut&paste may eventually be included, which would finally spare us the humiliation of having to write down things so that we can type them in again.

but more importantly, it would be nice if apple released its death grip around what it considers its monopolies on the phone. for example, i would pay handsomely to buy an iPhone app for SMS messaging, simply to get rid of the annoying chat metaphor, and more importantly get a character count so that i'd know whether AT&T will charge me for one or two international messages (and these are still obscenely expensive, so i'd really like to know). actually, i'd like to get an SMS messaging app that would stop using AT&T for sending messages altogether and simply use a web-based service for sending them...

more generally, i'd be paying even more handsomely for an application pulling together SMS, email, voicemail, and twitter, to give me the unified messaging i really want, also extending contacts with twitter ids and using this information as the switchboard for all apps. and while i am at it, why not add fax capabilities as well, there are numerous pretty decent web-based fax services that could be used.

of course, this is not going to happen, because the iPhone is not a computer but a phone, and thus historically is treated as a walled garden, and not as a general-purpose device. this traditional view of how telecoms and phone manufacturers look at what their customers are allowed to do aligns nicely with apple's world view, so there is little hope to see an open iPhone that would allow me to install and use the apps that i want to use.

and i guess i'll continue to use the iPhone because it's well-designed and useful and still miles ahead of the competition that is only now slowly waking up. but i just don't buy the claim that i am better off with the resticted iPhone than i would be if i had the freedom to install a crappy phone or messaging app that would not work well.

Mobile Platforms and Services

with the New York Times reporting about additional traction for Microsoft on LG devices, the more interesting question is how relevant smartphone OSs will be in the long run. the iPhone has definitely stirred up the marketplace, ending the unfortunate situation for end users where installing apps on a phone was something no mortal could figure out. plus it was the first really good browser on a phone, unfortunately hampered by the fact that the touchscreen interface renders a substantial number of Ajax applications unusable.

the current smartphone OS ranking is Symbian, BlackBerry, Windows Mobile, iPhone, and the rest (mostly Android, i guess; what happened to Openmoko?). with Palm ditching their own Palm OS in favor of Windows Mobile, it seems like the first victim of some market consolidation is already established. while it is important for the phone makers and the OS makers which OS will eventually win and which ones will disappear, for service providers this may not be as important as it seems, and more importantly, it should not be as important as many think it is.

application runtimes for mobile applications can be the native OSs listed above, but they can also be runtimes layered on top of these OSs, the most important ones being Java ME (a.k.a. J2ME), JavaFX, Flash Lite, and Ajax. this mirrors the development of the web in general, where Java applets, Flash, Ajax and recently Silverlight and AIR are used as application development platforms. Google's Chrome is an attempt to also get into that space by extending the Ajax platform with some missing but essential features for standalone apps.

for developers of mobile and location-based apps, this landscape can be confusing. for example, the iPhone is very popular, but the platform has no support for map-based apps, whereas Android has pretty good built-in support, but is not very popular. you could also implement such an app using Ajax, but then it will not be usable in the iPhone's browser because of its accessibility problems. so how to proceed?

the most important thing to look at is the fact that apps are just interfaces to services, so focus on the service and worry about the front-end later. figure out what you need from the platform to deliver your service. what would make your life easier on the platform? XML support? HTTP support with solid caching? a universal feed parser? XSLT? XSLT 2.0? mapping? access to the device location? designing and implementing location-based services is not an easy task in today's landscape, and it is made harder by the fact that it is hard to predict the landscape in a year, and almost impossible to predict it in two years. which means that instead of focusing on eye candy and platform-specific goodies, focus on the service you are designing, and make sure you can move with the landscape as it is shifting.

i am still hoping to find some comprehensive comparison of all the implementation platforms described above, taking into account the many different requirements that typical mobile apps have today. it would be hard work, but it also would be highly valuable for anybody trying to make a move in that landscape. should i built the fancy iPhone app which costs me a lot in development time? why not just build an Ajax app and produce an iPhone-optimized variant of it? such a matrix would also be pretty interesting for the vendors, i guess, to better figure out where their platforms are lagging behind, and where there is uncharted territory where they could be the first movers.

for service providers, on the other hand, instead of building just web apps, it becomes increasingly important to built web services (not of the SOAP variety, i am more talking about REST here), and to make sure this service can be easily used by a variety of front-ends. twitter probably is a great example for how powerful this model can be; their front-end (the web site) is very basic and minimalistic, but their simple and well-designed service has encouraged a flood of twitter implementations on all imaginable platforms. only about 30% of all users access twitter through the twitter-provided front-end (the web site), the other 70% use it with other front-ends built by third-party developers. i am pretty confident this would not have happened if twitter had provided a WSDL-based API accessible through SOAP.

all of this boils down to the following: for mobile apps these days, focus on the service, provide a well-designed service, built a front-end on a platform that fits your requirements, and make sure you can switch front-end platforms should the mobile landscape make it necessary.

[[ update 2/18/2009: tim bray just published a post covering Palm's webOS as well, which i did not mention at all. ]]

Location Privacy

it's only a coincidence, but it was interesting to read about a new service by Google that tracks user locations and about MySpace handing over a lot of private information in response to a subpoena. using Google's new Google Latitude service, people can update their location via a variety of ways (currently supported are Android, iPhone, BlackBerry, Windows Mobile, Symbian S60, and J2ME), and then this information is transmitted to Google, where it can be accessed by others. of course, the service has privacy controls (it's basically the same service as Yahoo! Fire Eagle, but more targeted at users than at applications), but this only controls what's exposed to others, not what Google does with the data.

the mobile privacy policy does not say anything about how long Google stores the location data, and surprisingly, the full privacy policy also does not say anything about that. does that mean Google will store my location data forever or as long as they please? remember, even though Google mostly uses this data internally, they might be forced to release this information. and your location information might just cause some collateral damage, when your location track is being released as a part of some investigation and you're not really guilty of anything, but you still were in a place where you were not supposed to be...

building centralized applications always is technically easy (as long as they scale reasonably), and also very attractive for the party doing the centralization. in particular if it is information that is very valuable for data mining and user profiling. but as a user, the important question is with how much non-monetary currency i am willing to pay for a service; in Google's case, the currency often is privacy.

for me as an iPhone user, AT&T has my location trail anyway, and i am sure they will also turn it over if somebody shows up with a subpoena. i always wanted to be able to just switch off the phone part of my iPhone, so that i can still use the Wi-Fi without being hooked up to AT&T all the time. with the new Google service, iPod touch users now also can be traced (not with GPS or cell tower positioning, though). seeing that most people are carrying there phones around all the time, this might be the tipping point where people actually realize how much privacy is eroding with all these great free services, but i has been hoping this a number of times already...

Breaking Apps

now that the iPhone 2.1 Software Update has been released and the iPhone 3G is slowly approaching the status of actually working as a phone, i am still wondering why there were so few complaints about the fact that 2.0.2 basically disabled all 3rd party apps for a couple of weeks.

i am wondering how people would react if a windows service pack would break all non-microsoft software on a PC, and microsoft would respond by saying we are aware of that and will issue a fix sometimes next month. people would run around accusing microsoft of doing this on purpose and being evil again. apparently, apple can get away with that easily, and i really don't understand why. it is as mysterious to me as the fact that most people still seem to believe that Google wants to improve the world, instead of reeling in enormous profits.

my conclusion from this observation that only few people complained is that almost nobody is using 3rd party apps for important tasks. it really is not such a big deal when your koi pond or your primordial ooze is unavailable for a couple of weeks...

iPhone or AT&T?

my Could not activate Cellular Data Network post proves to be pretty popular, so i guess i am far from being the only one getting this message. the interesting questing is whether this problem is an iPhone problem, where the network works fine and the iPhone is just unable to use it, or whether the iPhone works fine and the AT&T network has problems with its data service. without testing, this question cannot be answered, and from the customer perspective, it does not really matter all that much, the simple end result is that i cannot use my iPhone for the service that i am paying for.

the iPhone 2.1 software update promises to give fewer dropped calls, but when even the announcement of such a fix does not claim to just make your phone work, but simply make it a little less unstable than it currently is, i am not very hopeful for getting a working phone out of that.

for me, living with a phone that drops the majority of incoming calls and requires me to hit redial a couple of times before i can call anybody is not all that bad. i am mainly using the data service anyway, and while that also has its issues, on average it at least seems to work better than the phone service.

finding out what exactly is going wrong would be really interesting, however. while the failure to simply connect calls looks like a network problem, on the other hand there seem to be many complaints in other countries as well, so maybe it is the iPhone after all? hard to tell, i guess, since probably many cellphone carriers use the same vendor for building their networks, so it might be just some incompatibility thing between the iPhone and that equipment?

the one thing i would really be interested in would be to see other 3G phones on the networks that don't work very well with the iPhone (such as AT&T), and see whether they have the same problems with connecting calls and using the data service. that could be a pretty interesting starting point to figure out who's to blame...