MidKnight Gallery

One of the new features that has been added that’s a no-brainer in retrospect (though none of my previous phones had it) is an ability to take screenshots of your iPhone screen. This means documenting iPhone features, showing off how cool your game looks, etc. all are much easier to do.

This also makes it very easy to note one thing that many people “know” but don’t give much thought to. If your website is Flash heavy, or worse, almost exclusively Flash, here’s what it looks like to an iPhone:

That little blue building block? That’s the “I don’t know how to play this content” icon where a website decided to have everything Flash-driven.

Yes it’s true that Google has arranged with Adobe to index flash files. This mitigates, but does not eliminate the argument that Flash-heavy content hurts your search rankings, even in Google. Nevertheless, creating Flash-heavy sites, especially sites that have no easy way to bypass the Flash, means that anyone without access to a full desktop is unlikely to dig up any useful information about your company, such as phone numbers to contact you.

Just a thought.

I’m very impressed by what the guys at Google have released so far. They’ve already addressed several obvious issues that made it an intriguing development platform in development, if you’ll pardon the expression, but useless for me. The biggest one is image resizing and manipulation.

Hearing this, I revisited it and am quite impressed. For ajax-based work (like custom coding an editor) it’s more complicated than straightforward PHP/Javascript development for small sites. This is mostly because of the need to tell at least two sets of files what’s handling a request for a web page before you even get to wiring up the python code to the template. What it gives you in return though is an absolutely stunning level of scalability, as well as a very rapid method for prototyping all of your changes.

The remaining headache is the need for some form of version control. You can have different ”versions” of an app posted, and roll back to a prior version, but there’s no integrated access to a common file repository where people can independently work on different files and see the combined changes before deploying them to the server. Guess I’ll have to figure out how to set up my own repository and how to make it so my fellow developers and I can work on it, along with a workflow that won’t cause headaches in deploying to the Google apps site.