I've made a couple additions and modifications to iTweet this week, they are lots of fun and add some great functionality!

In the Web interface I've added Statistics to your profile in the top right - so you can see at a glance your number of updates, favorites, following and followers. This updates itself as you tweet, fave and follow.  There is also an "Appearance" preference in the Settings menu - you can keep the default iTweet look OR import your Twitter profile's appearance - background image, font colors, sidebar color and everything!

If you are wondering "where did the nifty follow/notifications/block buttons go?", I have moved them all to the Profile pages to make better use of the API and make these methods more intuitive.  The old method assumed whether you were following a person or not based on the timeline they were found in; this was a little confusing and inconvenient, so I've moved it to the Profile page.  Here the page can tell (via the Twitter API call) whether you are following that person or not, and present the correct options depending on that status.

There's also an "is so-and-so following me?" button so you can see if that person is following you, and a "Twittering Since" date that shows when that person joined Twitter.  That part has been interesting to me as it's neat to see how long someone has been part of the Twitter community.  That data is made available via the Twitter API, although for some reason you can't find that info about a user on twitter.com - another reason to use iTweet!


Leave comments on this blog, or let's talk on Twitter or Facebook.

itweet, twitter, api, iphone

This is part of a series of posts about the Apple iPhone and the future of the mobile Web.

With regard to the upcoming release of an iPhone SDK for native, third-party apps: keep in mind that Web apps are growing in popularity and functionality.  Many predict web apps will one day render the desktop tower more or less obsolete.  As apps like Google Mail/Reader/Docs/Calendar, Basecamp, Todoist and the rest become more ubiquitous, online file storage like .Mac and box.net become cheaper/easier/faster, and bandwidth pipes become less of an issue, the day will come when files and applications are all run online, and users log in through a thin client OR EVEN A MOBILE DEVICE to establish their identity and to operate the data and applications.  Google is banking on this.  You can bet that Microsoft is working to create Web-app versions of their software.  Apple seemed to be on the same page with the original, abandoned Safari SDK, and with the Google Maps and Search integration on the iPhone. What happened?  Some have suggested that the problems involved got too complicated just to fix them instead of working around them. I don't know if that's true, but  Apple has certainly been mum about it.  In any case there is no denying that Web apps will certainly play a large part in the next generation of computing.

There will clearly need to be further integration of the two platforms (web and native).  Many of Apple's most useful apps are already integrating into a blend of desktop app that uses online services...and what's really beautiful about them is the way that they run transparently in the background without making a big deal of their online tasks.

iPhone/mobile apps should really attempt to emulate this. Internet-dependent processes should happen quietly, when the iPhone has bandwidth and battery power to use for these tasks. The user shouldn't have to monitor or adjust or push too many buttons to make these things happen. Most apps are used for repetitive tasks.  As such they should be streamlined as much as possible.  Mobile apps should have ten times the amount of streamlining, both due to slower bandwidth and processor speeds, and to the fact that they are mobile "on-the-go" pieces of software that should allow you to enjoy you life and take part in the world around you instead of standing around pushing buttons.

In our world, reliable and ubiquitous wi-fi is not a reality yet.  Even cell/EDGE service is not available constantly.  (Think airplane.)  The iPhone should be a tool that is adapted to that fact - when internet or EDGE connections are unavailable, data that might be needed later should be stored natively. Services that require real-time information from the web should use the web.  The difference is simple, yet the tools have not been created for the development community yet.  As bandwidth and connectivity cease to be an issue, more of the iPhone's computing can rely on services "from the cloud".  In this kind of environment, the line between Web app and native app will begin to disappear.

So although there are some who say that Apple is missing the boat by not sticking with a Web-only platform, I say, for the good of the iPhone and mobile computing, use whatever it takes to get the job done...but use your platforms to the fullest of their capabilities instead of allowing them to be crippled by technical restraints that, ultimately, can be overcome.  Not by third-rate hacks or Band-Aid workarounds, but by matured, full-fledged development environments that can be programmed to do the repetitive tasks for you while you get on with participating in real life.  Bottom line: Don't forget to consider the technology available to the world you're in right now while you plan for the possibilities of the future.

This is part of a series of posts about the Apple iPhone and the future of the mobile Web. Stay tuned.
Next up: my iPhone wish list...

Tags: iphone, web+apps, apple, mobile, safari, colby palmer

In my last post I wrote about mobile application design and how form should disappear in the face of function.  The implementation of MobileSafari on the iPhone comes so very close to giving developers a toolkit to accomplish this with pizazz, but there are a couple issues holding it back from its full potential:

The "dev kit" that Apple offers doesn't allow access to the phone's features.
This was covered in my last post. Lack of access to the camera, microphone, speaker, alerts etc. hinder iPhone apps from being fully effective.

MobileSafari's support for Web standards is subpar.  The implementation of the Web standards that Apple touted as an application development platform are disappointing.  Javascript behavior is slow and unreliable, and even some CSS properties do not behave according to the Web standards that Apple touted as the future of the iPhone.

This may have come as a surprise to Apple.  As far as I know they have never said outright that the Safari browser and its Mobile counterpart can behave like two different animals, but as someone who spends a lot of time with both, I know it to be true.  This is something that I had considered worth overlooking for a while as the platform was improved on; but rather than fixing the current problems and bringing MobileSafari up to speed with JavaScript handling, iframe display, and the rest, Apple seems to be applying Band-Aid fixes instead, by using custom CSS and Javascript events that work around existing limitations.

At the VON conference this fall, I heard the claim that Apple never second-guesses themselves, that every move is planned well in advance.  While I don't doubt that this is true, this claim was accompanied by the assertion that Apple never makes a mistake.  That the 3rd-party SDK later release was intentional. That the sucky Safari SDK was never intended to be the "real" platform for the iPhone.  Even that the $100 early-adopter rebate was all planned from the beginning.

I don't really agree with this stance; I obsessively read everything iPhone-related that I could get my hands on for MONTHS, and I follow Apple pretty closely.  While it's true that they haven't taken many false steps since Jobs came back on board with the launch of the original iMac and the iPod, there have been a few recent products that weren't exactly flops, but I'm sure they didn't go the way Apple planned them to.

Part of the reason I would hate to think that Apple made no mistakes is this: if the whole Safari SDK - price drop/refund - 3rd-party app saga was all part of some grand scheme on Apple's part, that would qualify in my book as majorly planned obsolescence.  More than I'm comfortable with, in fact.  Especially as a Web developer - so what, was Apple just messing with my mind?  I don't my (imaginary) type of relationship with Steve Jobs is Walt Disney exactly, but I don't think it's Ike Turner either.

The idea that everything Mac is orchestrated perfectly from on high might work somehow...except for the fact that some things with the iPhone haven't gone as initially (publicly) planned.  And the planned obsolescence angle just doesn't fit the company's profile.  Sure, tech stuff (and especially gadgets) improves in leaps and bounds.  I spend thousands of dollars every year chasing the newest carrot that technology dangles in front of me; I'm a total sucker for that.  But I think this is just a little too off-track to be intentional.  Apple has been plenty cool about people hacking their iPhones, and I don't doubt that they are working as hard as possible to achieve maximum development AND maximum profit at the same time.  So I disagree that the whole thing was planned from the start; I'm chalking it up to "bumps in the road" that will one day lead us to the modern mobile Internet that I envision.

I am, of course, interested in your opinion.  Do YOU think the whole iPhone timeline has been completely engineered?  Let's talk about it in the comments of this post.

This is the second part of a series of posts, starting with the present and leading us into the future of the mobile Web. Stay tuned.
Next up: Integration of mobile app platforms...

Tags: iPhone, mobile, web apps, apple, colby+palmer, sdk, javascript, css, mobile+safari, safari