Here's a bookmarklet to help you tweet links to Web pages from your iPhone using iTweet.net and bit.ly:

Post Link via iTweet

Adding and using this bookmarklet is simple.  Just drag the above link into your Safari bookmarks and sync your iPhone to transfer the bookmarklet to your iPhone.

Then, from any Web page that you would like to post on Twitter, just go to your Bookmarks, locate the "Post via iTweet" bookmarklet and select it.  A new web page will be opened to http://itweet.net, the link will be shortened using bit.ly, and placed in the Post field ready for tweeting.

I thought about putting the original page's title into the tweet as well, but then I realized I would usually rather make up my own caption. However if the general consensus is that adding the page title to the tweet would be more useful, I can make that change - leave your opinion in the comments here, or email me, or contact me on Twitter.

Thanks to Matt Teske for providing the motivation to make this bookmarklet - I will definitely find it useful and I hope you will too. 

itweet twitter bitly link url iphone

I saw a lot of discussion going on in the Twitterverse recently about standard conventions for "retweeting" - the increasingly popular habit of repeating someone else's tweet verbatim with a credit to their username (or as close to verbatim as possible inside of the 140-character limit).

I personally don't retweet often, but I see it happening more and more every day. (Whether or not this increases the quality of Twitter conversations is a debate for another post.) Enough users of iTweet.net, the Twitter client for the Web and iPhone that I make, requested a retweet button so I went ahead and added one several weeks ago.

Several weeks ago, savvy iTweet.net user David Simmons had written me to ask if iTweet could use the Unicode "recycle" symbol ♺ as a standard for retweeting.  I immediately liked the idea - it's expressive, cool-looking and best of all it's only one character long, conserving space for more tweet.

Unfortunately I looked into it and found that the symbol doesn't render in SMS messages or on the iPhone.  Since iTweet.net is an iPhone web app, and since a large number of Twitter users rely on SMS, IMO this makes it a no-go for a standard retweet convention.  Bummer!  Many other Unicode characters display just fine on the iPhone - I don't know why some do and some don't, but ♺ is not one of the friendly ones.

My point here is that if a convention isn't able to be communicated through all channels, it shouldn't become a standard. For this reason I have made the ♺ symbol available in the "symbols" section, but can't recommend using it as a retweet symbol for anyone who wants maximum exposure and clarity in their tweets.


Anyway there is some great discussion on the topic over at Stowe Boyd's blog - go check it out if you're interested - and this made me think I should put my two cents in on the subject.

There has been other discussion about whether "RT" or "via" makes for a better standard.  I personally think "via" is a bit more friendly to newbies and a lot more readable, but "RT" seems to be the most common convention, so that's currently what I use in my Twitter client.

I also found this interesting article at Dan Zarrella's blog where he states:

Contrary to what I initially thought, “RT” is used more than 4 times more often than the full word “retweet”.

I am quite open to the idea of using something different if a better standard is proposed.  What's your favorite retweet convention?


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

twitter, itweet, retweet, iphone, unicode, sms

iTweet.net user John Haydon made this fantastic "How To" video called Setting Up And Using iTweet.Net and posted it on his blog, CorporateDollar.org.  Nice work John!


The response to iTweet 2's web interface has been truly extraordinary and now WAY surpasses usage of the original iPhone interface.  It is so wonderful to see a larger user community developing and producing great stuff like this video.  Thanks everyone!

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

Technorati tags: itweet, twitter, video, iphone, howto, diy, web app

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

Twitter just made a great addition to their Search API: Twitter Trends!

This method allows you to see the hot topics of discussion across the entire Twitterverse.  This is a neat way to keep up on breaking news, technology trends, political sentiments, or the latest Internet meme that everyone's tweeting about.

When I hear about some fresh news or tech rumor, I do a quick Twitter search before I go to any news website; it's a great way to find a wealth of links to pertinent content across the Web.

I've added the Twitter Trends method to both the iPhone and the Web version of iTweet.net.  I think it will become a fun way to keep up on current events, and to entertain myself when I'm stuck in line at the bank.    Enjoy!

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

Technorati Tags: itweet, itweet.net, twitter, iphone, trends, api, colby palmer

Today I'm releasing a major upgrade to iTweet, an interface for Twitter that is one of my pet projects.  This is a double release: a hugely improved iPhone Web app, and an all-new interface for any Web browser.

Click here to give the new iTweet a try!

Beginning with the iPhone app, there are some key features to note:

• Tap user pictures to toggle bio information. This section allows you to see a user's location, bio, and URL.  There are quick links to send a DM, view extended profile, turn notifications on/off, block, and follow/unfollow.
• "In reply to" links allow you to see the tweet a person was replying to, without loading a new page.
  
• Built-in search and hashtags via the Twitter Search API.
  
• Monitor your remaining API requests using the number in the "refresh" button.
  
• Update (and check) your location from the Settings menu.
  
• Change your notifications device, get more detailed API usage info, set hashtags preferences, and more from the Settings menu.
  
• Vastly improved speed in loading all timelines.
  

As before, a basic rule of thumb with iTweet goes: tap the avatar to see a person's profile, tap the username to see a person's tweets.

There is also a contact form on the About page, please use this for feature requests and bug reports!  (It sends messages directly to my email so you will get a quick response, especially if you're following me and I can DM you.)   <3


The Web interface has all the same features as the above, but adds some more information that doesn't fit on a tiny iPhone screen:

• Detailed user info and API limit info available at top right.
  
• Speed Tweet mode! Hitting the "Return" key from the text-entry field will send your tweet, more like an IM client than the Twitter website. Give it a try! I love it... if you don't you can turn that feature off using the Settings menu.
  
• Really simple method for sending DM's, I use this one all the time too.
  

Known issues and limitations:

• Character counter on the iPhone version still slows down typing. This is the biggest problem with the app, by my own reckoning and others' as well. I've tried many, many different methods of doing this. We're talking HOURS of experimentation! Basically I find that inspecting a textarea just kills MobileSafari's performance, especially in a Web page that has a lot of other elements in it.  I'm open to suggestions, as always. I've pared it down to 3 simple lines of Javascript and I don't think it can be any lighter than that.
  
• User profile pages are missing information for most users. Also profile information such as "last update" are running behind something like 5-18 hours.  This is due to a bug in the Twitter API which I have reported here. I will post an update when this is fixed. This will allow some very cool functions to be brought back to the Web version especially!
  

Happy iTweeting! I'm always interested in your feedback, you can contact me here.

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

Technorati Tags: itweet, iphone, twitter, api, iphone app, colby palmer

The Surfin' Safari blog announced SquirrelFish today, a new javascript interpreter for WebKit that is 1.6 times faster than the current interpreter. This is incredible, as Safari is already a super-fast browser, but as John Gruber points out in Daring Fireball, it may mean improved JavaScript support for the iPhone.

If you've read much of this blog, you already know my opinion about the whole "JavaScript on the iPhone really sucks" thing. I was recently reminded of this when translating some jQuery/JSON scripting from the Web to the iPhone. What ran as a fairly simple and speedy app on the Web became unusable on the iPhone, and I had to strip out tons of code to get even basic functions up to speed.

Keep your fingers crossed that SquirrelFish makes it to the iPhone, and soon!  I'm not sure if its release so close to the WWDC conference means it won't be making it to the upgraded "iPhone 2" that everyone is expecting to be announced, or if an iPhone software update will be released after the new iPhones hit the market.  The sooner the better!

The creators of SquirrelFish say this is just the beginning of new breakthroughs in compile times, and it sounds like they've done some very intensive and boring research to create their mutant aquatic rodent.  Thank goodness for the brilliant and patient minds (read: obsessives) who sort these complicated things out so the rest of us can have a better Web experience.

Oh, and yes... as everyone seems to notice, the SquirrelFish logo is way badass. It looks like it may evolve into a StimpyFish in a later release.

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

Tags: squirrelfish, iphone, javascript, webkit, safari

There's no shortage of Twitter clients out there that will work well on your iPhone. Twitter even offers its own: m.twitter.com. But iTweet takes the cake for us. The client offers a great UI, and most importantly, the ability to download only new tweets each time you refresh, saving a lot of time and bandwidth if you're using AT&T's snail-slow EDGE data network.

I just saw this really nice mention of iTweet,  my Twitter UI and iPhone web app, here on Wired.com's Epicenter blog.  Thanks guys!

(This article contains a voting system for "best app".  If you enjoy using iTweet, please visit this page and click the green "UP" arrow to vote for iTweet!)

I've also received a few requests now for a BlackBerry version of iTweet.  I have never made a BlackBerry app before but how hard can it be, right?  I will try to create a BB iTweet as soon as possible for those of you who don't have iPhones yet. 

In other iTweet news, I'm working on a complete rewrite of the desktop app (and the iPhone app pending a review of the upcoming iPhone SDK).  It's lean, mean, and Ajaxy.  My favorite new feature: Speed Tweet mode!  It's so much fun I can't stop Twittering lately.

Reminder again: please give iTweet an "UP" vote here.  Thanks!

Tags: iphone, iTweet, twitter, wired, review, iphoneapp

I recently had a client ask me to adjust her site to be iPhone-compatible.  The navigation of this site uses Flash to apply a cosmetic animation on the text, so her site wasn't navigable via iPhone or any other non-Flash equipped device.

At first I thought I would advise her to forget about the slight effect that the Flash provided and change to a non-animated, but fully accessible navigation system.  But I knew she really liked this small detail of the site, so I thought I would try another way.

...are you using swfObject to embed your Flash content, anyway? Because you probably should be.  swfObject is an  XHTML-valid javascript  method of displaying Flash content without using unwieldy <embed> tags.  The script will fill any old <div> with your Flash, and changing the layout is as simple as adjusting the <div> with your style sheet.  It detects Flash player versions and will help a user upgrade or install the Flash player "in-window" if necessary.  It is a fantastic workaround for the annoying IE "Eolas patent dispute" requirement to "activate" Flash content by clicking it once before any buttons are active.

And -- thanks to the way that it degrades gracefully -- swfObject lets you "hide" accessible content behind your Flash.  I often use text describing the Flash content to boost a page's search engine indexability. Though this text is visually replaced by swfobject.js, it remains in the source code when the page renders.

In the case of the iPhone, the Flash is simply not displayed, and whatever originally was in the swfObject-specified <div> shows through. This is where you put a static but more-accessible version of the Flash image. You can include any kind of xhtml, links, images, or even embedded swfs.

In this case I simply made an html-friendly version of the client's site navigation, placed it in the navigation <div> and specified that swfObject would replace that content with the Flash nav where possible.  Voila!  The client sees her subtle Flash nav effect on her home computer, and can use her site from her iPhone as well (with minimal visible difference, as the Flash effect was a rollover effect anyway).

I have also used this trick to "hide" a jpg of a site's logo or header behind a Flash version... this way when viewing on the iPhone, that most important piece of your site (your identity) isn't lost!

swfObject was created by Geoff Stearns.
Click here to download the project from Google Code.

Tags: iphone, swfObject, flash, accessibility, javascript, iphonedev

I've added Twitter search and #hashtag search to iTweet.net's iPhone interface.  I did it before I took off for Macworld last week, so I could see who was talking about what.  Unfortunately, this didn't quite work out as apparently we Twitterbugs got a little excited with Macworld fever and crashed Twitter right down.  The API didn't become usable till about 24 hours later!

I started tracking "macworld" that morning and my IM sounded like I'd won a jackpot! I had to turn it off 'cause it was way too distracting.

Anyway, #hashtag support is in as well, #hashtagged words are green.  Click them to see an archive of words with that tag.  For now I've decided to strip the preceding # off of the tagged word to make the system totally legible.



I made the search button in the menu BRIGHT RED just to beat you over the head with it for now.

Search is provided by the Terraminds Twitter Search API.

Tags: itweet, twitter, iphone, hashtags, terraminds, twittersearch, colby palmer

I got an Airport Express unit for Christmas, yippee!  Finally the massive wealth of songs on my iMac are flying through the air and spilling gloriously from the speakers in my living room.  It's awesome!  Although setup was a little funky with my aging wireless router, once I got it working I was amazed at how simple iTunes makes it to switch between speakers via AirTunes, and how nice the music quality is.

Especially cool is that, with one stationery and two laptop computers in the apartment, it's simple to control the flow of the music via shared libraries.  Keeping a laptop in the dining room, for instance, makes it easier to play DJ without going to the office on the other side of the apartment when a track needs skipping.

But even BETTER, I'm using Remote Buddy on my iPhone to control the tunes.  I can use it to change AirTunes speakers from my office to the living room easily, and navigate through my playlists to find what I want to hear.  Then it offers a simple remote-control interface to control the song or volume.  This app is almost freaky because you can operate all kinds of apps via a set of custom menus, or log right on and control your desktop computer via screensharing!  (I typed this sentence into the Flock blog editor on my iMac using my iPhone!)

There are a number of apps with custom menus. These ones caught my eye as being especially useful:

• DVD Player


• Front Row


• GarageBand


• Google Earth (I tried this one, it rocks)


• iPhoto


• iTunes


• Keynote


• Miro


• Photo Booth


• PowerPoint


• VLC Media Player

---

I'm going to have lots of fun with this!  I think now I have a great reason to put an Apple Mini in the living room for watching movies and photos and touring Google Earth.

I live in an apartment so I don't want to go crazy wiring it, but I imagine you could control your house lights, security system, gate buzzer, garage door etc. from your iPhone as well.  I'd love to hear from anyone who has done something like that!  Now if I could only program the iPhone to change diapers, I'd be all set.

Tags: iphone, remotebuddy, apple, airport express, itunes, airtunes

The January 2008 issue of iProng Magazine just came out and I am featured in an interview about iTweet, the Twitter UI for the iPhone (and now the desktop) that is my pet project.  iProng is an iPod- and iPhone-centric website, magazine, and podcast that is headed up by Bill Palmer (no relation, I swear!).

iProng's tagline is "Voice of the iPod Generation" and this really describes the focus of their collective efforts well.  The magazine and podcasts feature Mac-geek interests such as Macworld Expo articles, interviews with Web/iPhone developers like Joe Hewitt (and, um, me I guess), coverage of PodCamp, BlogWorld Expo and VON events, and also cultural interests like album/concert reviews, interviews with musicians like Silverchair, Rebecca Loebe and Internet darling Matthew Ebel, features about yoga podcasting, iPod games and more.  There's a little something for everyone.

iProng has a main website where you can contact them for information, read reviews and find out where they are appearing at events.  You can find the magazines available for download here.  They are also provided in an iPhone-friendly format here (nice touch!)

I've been listening to the podcasts for a while and I'll vouch that they're as entertaining as the magazine.  You can listen to them from your browser or subscribe to them in iTunes for free.

Bill lives in Los Angeles and has a remarkable talent for getting pictures of himself with celebrities.  His Twitter updates often make me laugh and miss living in Hollywood, you can follow him here if you're interested.

Click here to download the latest issue of iProng Magazine. (My interview is on page 4!)

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

Tags: iprong, interview, ipod, iphone, colby+palmer, itweet, twitter, podcast, magazine, apple, bill+palmer

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

When I imagine a "digital lifestyle", it is long on "lifestyle" and short on "digital". I picture a level of integration between tech (iPhone, home computer, web applications and services), life (home, family, travel, friends) and the digital tracings of my life (photos, video, music, design, blog/microblog/ tumblelog) that allows me to enjoy what I'm doing without thinking about transferring from real life to digital.  It just happens, at least it does in my mind's eye.

The advent of the iPhone had made it seem like the "digital lifestyle" was ready to integrate in this way.  Unfortunately, the actual product and process has fallen short of this mark.

Apple's announcement that they are releasing a "real" iPhone SDK for native third-party applications is good news for the iPhone.  Applications so far, whether they were Safari Web apps or hacked native apps, have been restricted to a fairly primitive set of features. The main reason for this: no integration with the features that should make the iPhone a mobile wonder: camera, microphone, speaker, accelerometer on the hardware side, and Address Book, Calculator and Clock on the software side.

A good mobile app should be as transparent as possible while allowing you to complete the intended function.  They should take little energy and attention to operate. Save that for desktop apps - when I'm using my mobile the last thing I want is to be "that guy" who spends the entire time at a social event tapping away at his phone.

Here's an example: since I'm always Twittering from my iPhone, I often get people wanting to see pictures of something I'm doing, while it's happening.  So I will post to my tumblelog, or to my flickr account, and then direct them to that location via my iPhone's Twitter client.

It takes 15 button presses to shoot and email one of my photos. FIFTEEN!  I won't be tiresome and list each one, but that's what I came up with.  This could easily be streamlined by an app with access to the iPhone's camera AND the Web.

I can only share the photo's address via a general URL.  Since there is no copy/paste on the iPhone, once I've uploaded my photo and I want to share it, I might Twitter/text/etc. a link to the general location: "Check out my photo on Flickr, I'm colbyworld" or "Photo on my tumblelog at fun.colbypalmer.com".  This doesn't provide a link that people can save or share, once I've uploaded a new set of photos the one I'm trying to share will be buried.  I know there is a remarkable Flickr-to-Twitter service available...but what if I want my photo to go to Facebook or Tumblr? How about all four? Not to mention other sites like Radar, MobyPicture and the rest. There are methods of emailing photos to upload to these services, but no standardized method of tagging/titling/commenting.  This could be handled by an app that stored prefs and login/API information for the different services.

At this point, I'm fussing with the iPhone when I should be doing something fun. If I wasn't doing anything exciting I wouldn't want to share a picture, right? About the time I get to step 8 and I'm fumbling with tags and deleting my signature from the email so it doesn't appear in the Flickr comments, my fiancee is frowning, my baby is squirming, and my Twitterpals still have no picture.

A fully integrated app could slim this down to only four steps:

1. Open the app.
2. Take picture.
3. Select options: take more pics, review/tag/edit, upload to (flickr, tumblr, blog, select socnets you want), post to (twitter, jaiku, pownce, tumblr, facebook etc). Most of these will be pre-set as preferences, so no selection would be necessary.
4. Press "Done".

The app would perform basic enhancements (this is something else conspicuously missing from the iPhone), tag, upload the picture, then post a link to it on your Twitter/Flickr/Tumblr/Facebook/etc. account.  Unfortunately this just isn't possible yet with the tools that Apple has given us.  Cookies aren't stored reliably, there is no place or method for storing local data, and there are NO ways to access the cool features of the iPhone that could transform it from an Internet-capable device to a true multimedia wonder.  This keeps us coming up with workarounds and hacks, and expending more effort than we should have to in order to maintain the "digital lifestyle" that Apple has been selling us.

A primary goal for mobile apps should be TRANSPARENCY.  Hopefully with the release of a proper SDK, iPhone apps can help us slim down the button-pushing and get on with the fun.

This is the first part of a series of posts, starting with the present and leading us into the future of the mobile Web. Stay tuned.
Next up: Was the failure of the Safari SDK anticipated by Apple?

Technorati Tags: iPhone, twitter, mobile, web apps, apple, photos, colby palmer, sdk, digital lifestyle