Well, after pretty much everything going wrong dealing with AT&T for around a total of 8 hours in phone support or in store, I finally got my iPhone up and running on Friday, and here’s my take after the first weekend. I’ll try not to repeat everything that has been said already, other than to summarize that the iPhone is great however the battery and 3G network are laughable.

But I did want to do a quick write up to discuss some technology vs. design experiences so far. I give Apple alot of credit for the simple and intuitive interfaces used in the iPhone (and iTunes to manage it on your computer). I’ve got some issues with over-simplicity here, but I’ll save that for another post.

For now, I wanted to discuss a few things I found while building my first iPhone App. Now, I started out easy and just built a web-based Safari app (to get a quick start) rather than learning the native application SDK (which I’ll tackle next). If you’re not familiar with iPhone web-app development, there’s a great User Interface library (iUI from Facebook’s Joe Hewitt) which developers can easily implement to simulate most of the iPhone’s capabilities in Safari.

So I grabbed iUI, and threw together a quick application to show each DC Metro Station’s next train arrival time. I figured this would be very handy for me when I’m on the go to see how much I have to rush (or stall) to get the next train. The basics are working if you want to check it out (on your iPhone) over at metro.orangewiz.com, however I can’t guarantee this will be speedy or stay up (or even stay there) permanently.

The major issue I found with the iUI interface is that it is AJAX-based by default. If you’re not familiar with this, AJAX basically means that data chunks (and in this case full pages) are loaded into the current page without having to reload the whole current page. This is great for many things, such as the new Google Suggest which is basically an “auto-complete” that loads and displays related search terms as you type in the search box. However, AJAX has some real disadvantages when not used properly.

In iUI, AJAX is used to simulate the iPhone’s “sliding screen” feature (seen in the first few seconds of this video) to fully load the next page and animate it sliding in over the current page when you click forward. This is some great eye candy, but is not very practical for my application. Loading the next page into the current page (without actually changing pages) means you can’t bookmark anything. In my App, I really need to be able to bookmark my home metro station that I use most often, rather than having to navigate through all the stations from scratch. Luckily, iUI lets you override this default behavior to deliver bookmarkable (but non-sliding) pages. (Techie info: use “target=_self” to bypass the AJAX swipes.)

In most cases, my recommendation would be to only use AJAX to alter small individual components within a page, rather than loading in full pages. Of course, there are places where AJAX on a larger scale makes sense, but only when your users will not have to repeatedly navigate through a maze of links to get to content they will access frequently. Google Maps is one example where almost the entire page is AJAX so that you don’t have to reload a full new map just to scroll around. In this case, this provides so much of an advantage over the alternative that its worth it. And Google is smart enough to provide a “Link” option in the upper right hand corner where you can Copy/Paste (and therefore bookmark) a link that will bring you back to the exact same spot on the map.

Lesson here: Just because you’ve got the technology to do something, doesn’t mean you should do it. Just because its “slick” doesn’t mean its usable. You need to take into account what the impact on your Users/Customers will be and how that technology can be used as a benefit, rather than a hindrance to them.