This recent post on CrunchGear shows off a new tablet app for Wired Magazines that is under development. This started the gears working in my head about a real problem emerging in the app ecosystem that has developed around Apple, Android and to a lesser extent RIM, Windows CE Mobile Phone, WebOS, et. al.

If I pick up a newspaper or magazine I know exactly how it’s going to work. I can skim through pages, read any article that grabs my fancy and curse at the subscription cards regardless of what type of periodical it is or who has published it. But in a world where we get our publications via app it’s possible that no two will ever be alike. Not only is it likely that no two interfaces will be the same but it’s also a near certainty that some will just plain suck. Many engineers are not designers and even those that are may not have any sense of good layout or UI. There shouldn’t be a learning curve when it comes to reading an article.

I envision this playing out:

• First, you hear about a great article around the water cooler at work.
• The next time you’re around your tablet you go and look it up.
• Curses, it’s not available online, but if you download the company’s app you can get it.
• Whoops, the app costs $4.99… well you heard it was a good story so you’ll pay it. After all there must be other articles you’d find interesting.
• After spending your lunch hour downloading the app and figuring out how it works you discover that the article you’re after isn’t in the current issue.
• You spend your next coffee break on Google trying to figure out how to get previous issues.
• Ah ha, there’s a separate app for previous issues… it’s also $4.99.
• After getting home you spend an hour on the phone navigating a phone tree until you can explain to the level one tech support person that you downloaded the wrong app.
• Level one manages to shrug his/her shoulders so over dramatically you can actually hear it over the phone. You’re then transferred to level two.
• Level two tells that there’s no way transfer the purchase price to the other app, but they’ll send you a refund card in 4 to 6 weeks so that you can get your five bucks back in 8 to 12 weeks. By the way you really should be calling the phone company with these types of issues.
• You go head an purchase the second app knowing you’ll get the the refund before you retire.
• After downloading and figuring out how this different UI works you’re exhausted and go to bed.
• You wake up the next morning enthusiastic that you’ll finally get to read this, surely, amazing article.
• You open the app which crashes, but it works fine the second time you try.
• You wade through 4 screens worth of advertisements and at long last you make it to the article.
• The article quotes two freely available AP stories and has one other paragraphs that amounts to “well, I guess we’ll have to wait and see.”
• …
• The jury turns in a guilty verdict and you’re introduced to your new cellmate Big Tony.

If the day comes where the majority of people are consuming their print media on portable devices like the Kindle or iPad I’m sure these issues will work themselves out. Until then this seems to be one of those issues where technology only serves to make our lives more complicated. Granted most of us won’t end up getting our salad tossed by Big Tony and his crew but the frustration is inevitable. On the bright side, if it does end up going to the extreme maybe the publisher will issue your refund in cigarettes.

Thanks to Stephen Poff for the CC image

I tried various different ways to express this thought on twitter, but 140 characters just wouldn’t do it. So instead I’ll expand a bit and vent as part of a proper blog post. I don’t make enough of those anyway.

I am firmly addicted to RSS feeds. This despite my assertion when they first came out that they weren’t useful to the end users of a website. They say the ability to change your mind is a mark of intelligence… right?

I currently subscribe to 66 feeds in google reader. On an average day this amounts to about 150 to 200 items that come through GR. I skim over quite a few and take my time reading the ones I like. This is a very manageable arrangement that take occupies about an hour of my day.

Then there are days like today in which just about every blog on the internet with any leaning toward technology has posted basically the same stories about iTunes, iPods, TC50, and/or Demo. As a result I’ll probably have sifted through about 500 feed items by the time the day is over.

What I want it some basic filtering built into to Google Reader. I am a big fan of the app in all other ways but the lack of filtering may actually end up being a deal breaker. I blame Apple… or at least the echo chamber that surrounds it. My desire for a GR filter started with the iPhone, grew to a serious annoyance with iPhone2, and has come to a head with iTunes8.

I know there are options out there. There’s a Greasemonkey scripts to add filters to Google Reader, but I have no desire to have Grease Monkey installed. There’s also yahoo pipes, but Yahoo’s been shutting a lot of stuff down lately and it would mean running every feed through Yahoo before I add it to GR which is less than ideal.

Now taking bets on when my desire for a filter starts to out-weigh my lazyness to the point where I switch to another RSS reader.

That was what, 4 characters more than 140?

I think I’ve about had it with Ubuntu Hardy Heron. It’s a sad day when my windows box is more stable than my linux laptop. I also made the mistake of upgrading my work machine from Gutsy Gibbon to HH last week and I’ve been regretting it ever since. Three times today alone I had Nautilus crash on me without the ability to restart it. When I’d kill the existing Nautilus process a new one would start automatically and crash until I rebooted the box. Reboots like that are unacceptable to me on a linux machine.

I’ve been playing with Ubuntu since the Warty Warthog days and this is the first upgrade that has not been a significant improvement. That makes me want to not give up on Ubuntu completely and instead downgrade back to Gutsy until the issues get worked out. Then there’s the bandwagon part of me that wants to jump on the the PCLINUXOS bandwagon.

Tomorrow after work I’m going to install PCLINUXOS on my home laptop and if things go well I’ll consider putting it on my work machine too. PCLOS has it’s .roots in Mandrake… aka Redhat, but it’s a full fledge distro in its own right now and it uses APT. I can work with anything so long as I have APT.

Thanks to Hayden Simons for the photo

A week ago tomorrow IDX decommissioned the last of its image servers. Over the last 2 and a half months I migrated a little over 20 million images, about 480 gigabytes, from our severs to Amazon’s S3 service. Most of that time was spend just occasionally checking in on the migration scripts that I had written or rewriting our image acquisition scripts to work with S3. We download images from about 190 sources every night as we gather MLS data on behalf of our clients.

The best part of the whole image migration and overhaul is that image acquisition is now tied into into our data balancer system. Each MLS in our system has a time stored in the database that is the earliest we can reliably download data from that source. Once we reach that time in the day the MLS goes through a series of steps triggered by a cronjob that runs once a minute. First the data is downloaded from what ever source makes it available. This can be ftp, http, soap, rets, or even direct sql connections. Next the data is parsed and made ready for insertion into our database. Once processing is done the data is geocoded so that we can easily map all the properties.

This was where the process stopped. When the app was first written image scripting was rushed as we were trying to meat our launch deadline. The image scripts were on different servers, so the data balancer couldn’t act on them directly. Instead each was launched as its own cronjob on one of the image servers. Every MLS is unique in the way we acquire images and is constantly changing, as such each must have its own acquisition script. Now each of those scripts is defined in our database.

Once per minute a script runs on our EC2 server that looks for image ready flags in our data balancing system. When it finds one it checks the database for the specific file that should be run to gather images. The script runs and then resets the image ready flag. As with data our image sources are varied. In some cases we generate URLs based on a know syntax, in some cases we’re given URLs by the MLS. In this cases we don’t need to store anything. Often we get images from some FTP source, via RETS, or in one case we download binary stored as BLOBs on a remote SQL server. Needless to say it’s complex to get all these images from 190 disparate sources, so anything we can do to automate things better is good.

My next project is building WSDL web services using NuSoap. This is uncharted territory for me, so I’m sure I’ll have more to say on this subject later.

It’s looking a little different over here at web 4.0 beta. I upgraded to the latest version of wordpress this morning and I decided to change the theme. The old one was custom build by me and never really got finished, so rather than bring it over to the new install I let it fade into the ether. This is a clean and simple theme that will be easy to customize when I’m slightly better equipped and motivated.