I always intended to write this postmortem earlier … now three years after development ceased, I’m finally getting around to it. Warning – retrospective rambling ahead.
In mid 2007, Nintendo released the Opera-powered browser for their Wii gaming console which they called the Internet Channel. For many people, including myself, this was the first time they had been able to use “Internet on the TV”. Because of the typical viewing distance, low resolution for CRT-based televisions, and the unique navigation interface using the Wiimote, many web sites were functional but not particularly comfortable to use. Many sites targeted at desktop PCs were too complex and heavyweight for the Internet Channel, fonts were often too small such that cumbersome zooming and scrolling was required. I felt this was a good opportunity to write a Wii-browser specific app – in particular, I wanted a news reader that was comfortable to use in a lounge room setting, controlled via the Wiimote.
I started the Wiider project around Dec 2007, as the successor to a Wii-specific news aggregator service I had set up called WiiRSS. The last SVN commit for Wiider was in Dec 2008.
The goal of the Wiider project was to create a web-based news feed reader optimized for the Nintendo Wii Internet Channel. Features included:
- Wii-friendly user interface – large TV friendly fonts, simple navigation
- Cookie-less view-only access for a personal feed list (via ?key=xxx, bookmarked on the Wii once you’ve logged in)
- Wiimote navigation controls, beyond what the browser provides
- Painless image zooming (eg Lightbox)
- RSS and ATOM feed support
- Easy feed discovery using the Google Feed API
Choosing the domain name
Every cool web two-point-oh-ish app needs a cool domain name. It’s a given. Here’s the list of available domains I brainstormed at the time (good, bad and cheesy):
- wii-feeds.com, feedwii.com, feedmywii.com, feedthewii.com
- wiilovenews.com, wiinoos.com
- (wiifeeds.com, wiifeeder.com and wiireader.com were taken)
Ultimately, I settled on wiider.com. The term ‘wiider’ had already been used around the tech press as a pun in reference to a (now defunct) Wii friendly interface to Google Reader, released by Google. There were advantages and disadvantages to this – I felt it was more of an advantage since people might feel compelled to search for ‘wiider’ and find my app. I wasn’t too worried about competition from Google’s offering, since my implementation was far better for it’s purpose.
Choice of programming language & web app framework
I prefer Python. I dabbled briefly with Ruby (on Rails), but ultimately still prefer Python. However, at the time when I began this project, there was no clear “one Python framework to rule them all”. Django was one good option, Turbogears was another. Ruby on Rails was exciting (if not hyped), but was a bit of a moving target and it’s application server was very crashy. I chose to use the Turbogears 1.0.x framework for Wiider, since I liked the philosophy of bringing together well tested components rather than reinventing the wheel (eg CherryPy as the web request handler, SQLObject as the ORM). While I now appreciate the Django templating language, at the time I also preferred the approach of Turbogears default template package, Kid (now largely superseded by Genshi), which maintains valid XML templates and allows arbitrary inline Python code if required (MVC separation be damned). Turbogears did the job just fine, but it turned out to be a fast moving project in flux. The 2.0.x release made enough key changes that migration from 1.0.x to 2.0.x wasn’t trivial, such that I was essentially stuck using 1.0.x for Wiider while the core Turbogears development focus moved on to 2.0.x and beyond. Not a showstopper, but a little annoying.
If I was to start the project again today, I’d very likely use Django, since in my opinion it now provides a better battle tested and stable base with a larger library of useful optional modules. Alternatively, these days there are enough Python microframeworks (eg, webapp2, Flask) that can be easily coupled with a templating language and an ORM (everyone seems to like SQLAlchemy) that you can easily roll your own preferred web app environment with a few “pip install” commands, and any of these would have been appropriate for a small project like Wiider.
What worked well
You could read feeds on your TV, via the Wii, lounging on your couch. I used it personally in some kind of beta state, on and off, for about 12 months, reading feeds of interest over my morning coffee. Feeds were ‘auto-managing’ – no read/unread, just the latest stuff, based on a per feed setting for how old items were allowed to be. You could add feeds directly via URL, or via Google’s feed search service embedded in the page and styled to look like it belonged there. I’d tried to design the app to scale – the database model only stored a feed with a particular URL once, even if multiple users subscribed to it.
I learned a lot. About handling ATOM and RSS feeds. About ‘small screen devices’ and modern Python web development. Optimizing web pages for comfortable reading on the Wii presents similar challenges to producing mobile sites for smartphones and tablets – skills that I’ve used on other projects since. Also, I honed skills in mundane things like keeping good project documentation in a wiki (which I, maybe strangely, enjoy) and using bug tracker (all via Trac).
Zero login. One reason why desktop-targeted feed readers were cumbersome on the Wii was the difficulty of logging in using the on screen keyboard. It could be done, but it was slow and cumbersome, and since the Internet Channel clears it’s cookies between restarts, you have to log back in every time you use the app. I solved this problem with Wiider by providing a ‘secret URL’ that would allow users to view their feeds without logging in. The user was prompted to bookmark this page for future use. To add or delete feeds, they would still need to log in, but typically I expected that people would add feeds using their desktop computer, and use the Wii only for reading. This of course meant that feed lists and content were not guaranteed 100% private, since the secret URL could be sniffed on the open network or inadvertently shared; users were warned of this danger. I believe it was a reasonable trade off between usability, privacy and security.
What didn’t work
I’m no web designer. It was functional, but could have been prettier. It did however have some smooth show/hide transitions courtesy of JQuery.
Refreshing feeds sometimes failed. Feeds were fetched on demand by the server when the page loaded – this isn’t a good way to do things since it often gave long page load times, and timeouts sometimes occurred. It’s not quite as bad as it sounds – Etags and Last-Modified headers were respected though, so updates only occurred when required. I had no interest in DoS’ing feed providers 🙂 Feed updates should have been decoupled from the page rendering via cron or a task queue – that’s something I would have added if the project continued.
Unicode. I never quite cracked a few lingering Unicode bugs. Somewhere between the feed parsing with BeautifulSoup, the database ORM provider, the template engine and the web application server, something was munging the Unicode. I learnt everything I never wanted to know about character encodings, but never quite managed to fix it.
Boot-time and startup time matters. The goal was to have a news reader where you could sit down, turn on the TV and read the latest feeds quickly, without too much messing about. This is typically the appeal of a games console over a fully fledged desktop PC – startup speed, reliability and simplicity. Personally, for me, the Internet Channel cannot provide that in it’s current form. To launch Wiider on your Wii, you needed to:
- Turn on the TV, turn on your Wii.
- Press ‘A’ while waiting for Nintendo’s unskippable health and safety message to disappear.
- Launch the Internet Channel. Wait a little.
- Go to bookmarks, launch Wiider, wait a little.
I’m certainly not blaming Nintendo for the ultimate retirement of my little web app. While Nintendo’s lack of interest in developing the Internet Channel to meet it’s full potential limited the utility of my project, it’s not that they are at fault. They do games, and they do them well. History has shown that they rarely deviate from this formula – facilitating easier access to the wilds of the open web is just not in their nature, even if it’s within their reach. I took a known risk, scratching my own itch and investing some time in a project while making some guesses about where they might head with it. My guesses turned out to be wrong.
Since I never felt the application was ready for casual use, I never really promoted Wiider publicly. I did have a single random signup by a user who must have stumbled upon it and added some feeds. Not really sure how they found it.
These days I prefer the immediacy of my smartphone or tablet for reading feeds over firing up the Wii. On the TV, things like Google TV are emerging, and no doubt many more people have home theater PCs that would run Google Reader or Feedly in a usable fashion. Many people prefer reading ‘feeds’ via Twitter/Facebook/Google+/Reddit link streams. I think Wiider’s niche has narrowed. Ultimately, since I couldn’t see myself using it anymore, I decided to retire the project. But it’s nice to have something ‘finished’, even if it was never really complete.
Here’s an export of the documentation wiki and the source code (tailored to run on WebFaction), for posterity: wiider_source_postmortem.zip