Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on “rollovers”, which pop up menus or other elements when the mouse arrow hovers over a specific spot. Apple’s revolutionary multi-touch interface doesn’t use a mouse, and there is no concept of a rollover. Most Flash websites will need to be rewritten to support touch-based devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?

In addition to the above, there’s also video which: decoding video to display on a computer screen using software requires a lot of the CPU (and kills battery life), while using a hardware-based encoding (H.264) is much more efficient.  Flash didn’t support H.264 until very recently.

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

One of the most intriguing points Jobs makes is the concept of being beholden to a third-party to make updates to their libraries whenever Apple introduces a new technology.  With the speed of changes in the iPhone OS, I can see his point.

Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

via Thoughts on Flash.

First, I thought I’d outline the reasons for an alternative to Gmail.  Let me preface this by making it clear that I love Gmail – it’s a great service, but one that has some inherently odd choices that make it less than ideal for an email-heavy user.  Some of Gmail’s most irksome quirks:

• No such thing as folders.  Instead, everything is tagged, which doesn’t lend itself well to being used inside my mail client
• The “All Mail” special tag appearing in my mail client via IMAP, which appears as though I receive two of every email
• Removes duplicates of messages, which means if I send a message to myself, it will never appear in my inbox (instead, it’s always in my Sent Messages tag)
• Not completely reliable.

In terms of reliability, it’s very important to me that the service is always available, and always fast.  I want to receive messages moments after they’re sent – not hours later.  When checking for messages from my other accounts (via POP), Google uses some heuristics to determine how often it should check for new messages.  Unfortunately, this often means it won’t check for an hour or so, which can be very annoying.

So, I’ve been on the lookout for a Gmail replacement for some time, and thought I had found it in Apple’s revamped MobileMe service.  When it was launched, it appeared that Apple was doing email right, but as I’ve learned from using the service first-hand, I’ve merely traded improvements in some areas, for problems in others.  For instance:

• It can’t check foreign email accounts.  This wasn’t a complete deal-breaker, as I have some clever auto-forward email recipes setup which largely solves this problem.
• There’s no way to send mail as a non-MobileMe email account.  You can create multiple “personalities” that give you different @me.com addresses, but there’s no way to send as a non @me.com address.  This is a huge problem, and means I can’t stop using Gmail until this is added to MobileMe.
• It drives me crazy that the web interface often refreshes the entire page.  If I leave it open in a Safari tab for a little while, then return, it seems to refresh.  That’s annoying.
• Another annoyance factor is that whenever I return to the email interface (or whenever the page refreshes), all of my folders are expanded.  I have a LOT of email, and I keep them fairly well organized into many different folders.  I’d like the system to remember what folders I had kept closed.

I should mention that I am a big fan of the push email functionality I get with MobileMe (and is a major reason why I’m still using the service).  Also, the email web interface is clean and intuitive (and matches the Mail desktop app, which scores major points with me).  Compared to the other major email providers (Gmail, and Yahoo Mail, for instance), the MobileMe email interface wins hands-down.

Apple’s MobileMe is a fantastic service, but I just can’t switch yet.  So many different great features are all aligning to make for a killer email product, but the annoyances I’ve outlined are show-stoppers for me (and why I can’t dump Gmail just yet).  I’m more than happy to pay the MobileMe subscription service if Apple could just get these last few details smoothed out.

What’s your take?  Have you considered switching from Gmail to MobileMe?

The Pandora and AOL Radio apps are designed to allow you to stream radio to your iPhone or iPod Touch.  The introduction of fast 3G Internet access on the iPhone represents a significant threat to satellite radio and, to a lesser extent, terrestrial radio.  Consider the implications.  A user has an iPhone that’s the same size as an iPod (or a Sirius Stiletto) that can stream radio while in the car, walking down the street, or inside a building.  The iPhone can hop onto WiFi networks (same with the iPod Touch) or use 3G.  Even Edge connectivity allows for decent streaming.  All that adds up to great wireless access – as good as, or better than, satellite technology, since 3G and Edge connections work indoors whereas satellite doesn’t.

Accessibility aside, the real advantage is the phenomenal flexibility streaming radio provides.  Take Pandora for example.  It’s a streaming radio program for the iPhone that creates a customized radio station matched exactly to your tastes.  But even the simple ability to skip over songs you don’t like, a basic feature of Pandora, is inherently absent from any pre-programmed content station.  Such a simple feature goes a long way to improving your listening experience, and it’s almost embarrassing in the age of TiVo to not be able to skip over content you don’t find interesting.

With greater accessibility and significantly greater flexibility, streaming Internet radio will become one of the biggest threats to satellite radio over the next few years and will become a killer app for the iPhone.  Cell technology is getting better at providing high-speed Internet access, and already there are a number of very good streaming services that match listener’s tastes to music.  As the iPhone becomes increasingly popular among consumers and access speeds increase, satellite will suffer.  Satellite’s only hope to stay competitive is to offer enough exclusive content that listeners won’t be able to part ways with satellite radio without missing their favorite programs, but even that strategy is tenuous at best – it will only be so long before the content creators themselves decide to head for the greener pastures that Internet streaming radio provides.

Here’s a quick overview of how to get all of your old emails into Gmail as painlessly as possible (and one way that preserves dates!).

Loading Emails
I spent some time looking into the different options I had for loading my email messages into Gmail. I have about 10 thousand or so that I wanted to keep stored (there’s a lot more than that sitting around in various mbox files, but these were the important ones). These 10 thousand or so messages comprised about one year of using the Apple Mail application on my Mac. So, poking around, I found a Python script by Mark Lyon called GML (for GMail Loader), which was designed to iterate through each message in an mbox (or other format) file and forward each message to GMail.

I managed to get the script working (one tip: be sure to export your messages by using the Save Archive option, which will create appropriately formatted mbox files for the script to read) and was able to import about the first thousand or so messages I had. Unfortunately, I ran into a couple of problems. First, I could only forward so many messages an hour due to a restriction set by my ISP’s SMTP server. Second, and most problematic, was that the GML script would actually forward each message, one-by-one, as if I were clicking the Forward button in my email client. This meant that, although the message still had it’s original date associated with it, the message would show up as having been originally sent on the date that I forwarded the message, not when it was actually received. This was a problem, and there had to be another way.

One idea I had was to setup my own pop server, where I would place all of my archived messages, and setup this server as an account in Gmail. Then, Gmail would connect to my mail server and load all of my old messages. I never got a chance to try it, but my guess is that it would work. Instead, another idea came up (courtesy of Costa): use IMAP.

Not long ago, Google announced the Gmail service would now support IMAP, allowing mail clients to connect to Gmail and use it as a kind of clearinghouse for all things email (IMAP stores everything on the server, allowing any number of clients to connect and always appear in sync with one another). If I added Gmail as an IMAP account to my Apple Mail program, could I then simply drag messages stored in the various folders into Gmail? The answer, luckily, was yes!

It was simple: I merely added Gmail as an IMAP account to my Apple Mail client, then just dragged folder-by-folder all the messages important to me onto my Gmail account. It took a while to transfer all the messages (be sure to open the Activity window in Mail to see your progress), but once it was done, all my old messages were safely stored in Gmail and had their original dates! Perfect!

Using IMAP
So now I’ve got my desktop Mail client using Gmail as my sole email account, along with my iPhone. Whenever I read a message on my desktop, it’s marked as read on my phone. And whenever I send an email from my phone, it appears in my Sent folder on my desktop. Everything stays in sync, and I’m very pleased with how it turned out.

One note: be sure to check out this page for details on fine-tuning your Gmail IMAP setup with Apple Mail and the iPhone. There’s a couple of neat little tricks to get your setup streamlined.

First, mass data storage is getting cheaper and cheaper, but to really push prices down, it takes the economies of scale a company like Google or Amazon can get by combining thousands of users’ storage needs into a single service.  Providing a service like this will decrease the total cost per gigabyte to even lower levels, which theoretically could make it cheaper to sign up and pay for a service like this than to go out and buy a hard drive.

Second, Google usually does services right (not always, but usually).  It looks like they have an eye towards consumers, rather than businesses (like Amazon’s S3 service), which will, hopefully, mean good integration with your desktop.  I sincerely hope to see a tightly integrated OS setup where users can treat their Google storage service as “just another hard drive” on their computer.  I’d really rather not see some cumbersome client software you have to download, but rather a network share on your computer.

Third, and most important (to me at least), is the freedom from worrying about backups, redundancy, and scaling.  More and more, I’m watching movies and TV shows on my computer or home entertainment system via iTunes and similar services, and my storage requirements are expanding rapidly.  There will be a time in the very near future where I’ll need a terabyte or multiple terabytes to store my movies and TV shows for access, rather than as DVDs.  And I’m not alone: many people are doing just this, as everything becomes digitized and always available.

Anyway, it’s all still very early to get too excited about this service, but I really hope Google does this one right.  Keep it simple, no client software, cross-platform, and as cheap as possible is the way to win consumers here; and I know that now – and in the future – people’s storage requirements are just going to increase.

sudo su
[Enter your password]
bash
export ARCHFLAGS="-arch i386"
gem update

Note that you’ll want to change the i386 to the actual architecture you have (my MacBook, for instance, is an Intel processor, while you would want to use “ppc” for non-Intel Macs).

Once I had updated my gems, things started working fine again. For instance, mongrel_cluster was having issues configuring a new project, but after updating the gem using this method, it seemed to be working fine. Hope you find this useful!

There are several to-do list iPhone web apps out there (notably, 37signal’s Ta-Da Lists), though it’s just not quite what I’m looking for. I really like the built-in to-do list in iCal, so having an actual iPhone application (not just an app via Safari) that can sync to my pre-existing iCal to-do items would be ideal. Hopefully Apple will be forthcoming with one (especially since it seems to-do items will play a bigger role with the Mail client in Leopard).

And I think Joel is completely right. Gmail, for one, has been stagnant for the last three years or so, and haven’t been preparing for the future. Check out this blog article from Lifehacker about a comparison between Gmail and Yahoo Mail. Their conclusion? Yahoo Mail has spent the last two years innovating and adding all sorts of new features, while Gmail has very little improvements (except, perhaps, incrementally increased storage levels).

As Joel has pointed out, the future of web applications is going to involve a standardized interface, providing UI-level features, interoperability, and a common platform for development. And there’s evidence of this happening. Several frameworks have come out recently that are generally very good: my favorites are YUI and prototype/scriptaculous. Very helpful, though the YUI is, I think, especially useful, as it provides a lot of very clean, useful interface-based functionality perfect for developing rich applications. But, it’s far from lightweight. And Joel’s point is: that’s okay.

I think we’re nearing a critical mass when more online software development will use an existing framework like YUI, so the common code between these sites will more likely be in users’ caches, therefore speeding up load times and reducing bandwidth costs. And, on top of that, there is likely to be further innovation to speed this up: building some amount of the framework code into browsers, say, or different, longer-lasting caching mechanisms strictly for Javascript framework files, or a whole number of other options.

Whatever happens, I think the biggest winners over the next several years will be with the developers who spend their time making the best applications, and let others (like browser developers) worry about keeping it fast. That’s not to say, “go out and make super-slow sites”, but rather to realize you shouldn’t spend all your time developing faster applications while neglecting features and other forward-looking progress.

If you’re not already aware, if you bought your iPhone within 10 days of an announced price break, you’re entitled to receive the difference from Apple (provided you claim this within another 14 days of the announcement).

Should Apple reduce its price on any shipped product within 10 calendar days of shipment, you may contact Apple Sales Support at 1-800-676-2775 to request a refund or credit of the difference between the price you were charged and the current selling price. To receive the refund or credit you must contact Apple within 14 business days of shipment.

Sadly, we at Draconis bought out iPhones 16 days before the announcement: 2 days later and we would have qualified for that rebate. But I’m not bitter over it: I love my iPhone, was willing to part with the full price without expecting any kind of rebate, and anyway, these things are out of our control. Anyone else in the same boat as us?

Craig Hunter has a good article up on his site that discusses some of the limitations of creating applications for the iPhone, though his standpoint is coming as a traditional Mac developer (and he makes great points: it doesn’t make any sense for a user to connect to a web app to input to-do list items):

Business aspects aside, the main issue I see as a traditional developer is that iPhone web app development is still very limited. Outside of some viewport settings, a couple special link types (really only the “tel:” link is new), and some new “-webkit” style attributes, there is little about making iPhone-specific web apps that differs from generic web apps. And that’s possibly the most disappointing aspect of all from my standpoint. Apple’s announcement states that “developers can create Web 2.0 applications which look and behave just like the applications built into iPhone”, but that’s not the case.

I believe there’s a lot that can still be done with the tools we’re given, and I look forward to Apple creating more tools in the future.