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 way 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.
Comments