Well, we decided to hold back our app for a day or two. Unfortunately, there were a number of surprises in store for us on the iPhone’s Safari. Things we were not expecting, to be sure.

First of all, it’s not the same Safari you’re used to. Not even Safari 3 Beta, actually. Quite a few sites that we use frequently, such as Basecamp, have rendering issues, as do pages in the New York Times and even Apple’s site! I would imagine that Apple has some updates in store, so I’m not too worried, but the rendering issues hit our app pretty hard.

We’ll probably take the weekend to iron out some of the kinks. Besides getting used to the keyboard, the interface widgets take some getting used to, as well. They’re not regular Aqua widgets, they’re different. And drop-downs open a half-screen interface that’s really weird. It’s like a wheel that you spin to view your choices. So our whole fancy AJAX interface for choosing between different options is almost a drawback! We’ll have to think about whether we want to keep this interface, or just use Apple’s fancy drop-down thing. In no way did I anticipate that widget.

Playing with the iPhone is certainly a learning experience, and John Gruber has posted a good list of first impressions that summarize much of what we noticed. For now, we’re still very much looking and learning, but it’s a beautiful day outside, so we’re not in any hurry.

So we’ll keep you posted.

Not actually having an iPhone yet to test on makes it rather difficult to develop an application for it. However, we persevere. It helps to have iPhoney to test on, because you get an idea of how many pixels you have to work with. And watching the videos on Apple’s site, you get a pretty good idea of how small the screen is, and how big your fingers seem.

So we’ve tried to make the interface obvious, and finger-tap targets large. Our application is for tracking vehicle mileage on your iPhone, and here is what one of its screens looks like:

We were sure to keep the buttons large. Also, in this example, you choose between several “drivers” of your vehicle. Rather than list them out as choices, with radio buttons, we made one big button that switches from one driver to the next. It’s not quite as obvious what it does, but you figure it out quickly, and it doesn’t matter how many drivers you have – they always take up the same space. Simple and elegant.

As much as possible, we’re trying to get it to look and work like a real iPhone application. We suspect that once you get used to an iPhone, using it will be second nature, and our applications should attempt to blend right in with that nature.

We’ll see tonight!

So a few days ago we decided to write a dead-simple application for the iPhone. Just to test the waters, if you will. Once we found out that all iPhones will have access to the web from everywhere, even though the speed might change, we realized that “Web 2.0 applications” really were going to work. The only thing that’s missing is the ability to put a button for them on the main screen!

Anyway, we made up some wireframes last night in OmniGraffle, here’s a peek at what they’re looking like:

In order to accommodate the small size of an iPhone display, we’re using a bit of AJAX trickery, so that a single button toggles between a number of choices. And we’re looking for ways to match the style of the iPhone apps themselves, while still fitting a lot of information onto the display.

So what is it?

It’s going to be a mileage log for your iPhone. Pretty simple. We hate carrying a mileage log in our car, they just never work quite right for us, and they’re not very flexible. So we realized the iPhone would make a very handy (albeit expensive) substitute!

Stay tuned, we just might launch it tomorrow night. We just want to see it on our ‘Phones first!!

In the latest issue of SmallBiz magazine, there is an article about a website design project that turned into a nightmare. Since we only want happy clients, we had to give it a read. In it, there’s a list of six tips to “make sure you get what you expect from your web developer.” Here is a summary of those points:

1. Register the domain name yourself, in your name or that of your company.
2. Stay local.
3. Check references.
4. Get a clause in your contract … stating that you have the right to use the material on the website.
5. Be as clear as you can about what you expect.
6. Ask the developer to produce a “shadow site” on his own server that you will approve before the site goes live.

These are pretty good suggestions, and for the most part we would encourage our clients to follow them as well. The most important one, however, is the first. We always want our clients to own the domain name of their website, because we believe it’s what’s best for them.

What can happen is that an under-principled web designer will decide that they want more money, or just want to be a jerk, so they’ll refuse to turn over the domain name to you. This can pretty much prevent you from even having another developer work on your site, which is about as worst-case as it gets! It can be very hard to get it back, as it might involve taking them to court.

This just gives good web designers a bad name. So be sure to own your domain name!

Lately, we’ve been thinking quite a bit about the sort of information that mailing lists are ideally suited for. One of my favorites uses is replacing stale website coming soon pages with a mailing list sign up. If you already own your domain name, why not let it start working for you right now? Our friends over at Pamplin Family Winery are doing just this.

By the time their new website and wine is released, they’ll have a list of folks waiting to hear about their product!

We all know that launching a new websit is exciting. Having a bunch of people to tell about it is icing on the cake – and makes all the effort much more worthwhile. Our friends over at Presents of Mind announced their site redesign to clients, letting them know:

Well the day is finally here and we have a truly lovely web site, if we do say so ourselves. We have focused on bringing better, cooler gifts to all. We have heard time and time again from visitors and people who leave the area that they have trouble finding so many great unique gifts for friends and family where they live. Now they can get many of our great lines and products shipped right to them! (see full mailing)

Artist Kendra Binney took an opportunity to get the word about about both her site redesign and new work:

In case you haven’t had a chance to see it, my new website is up and running and oh so stylish…I have some new prints up for sale as well as a couple of originals in the shop section so please check it out. (see full mailing)

It is not uncommon to wait 3 to 6 months before a search engine like Google indexes your site, so it is even more essential to take the opportunity to get your own word out – and a list of interested people is quite a start!

Yesterday afternoon we decided to do a little update to Ladybug. We’ve been having a problem with users uploading large images, which is a big part of the software. Months ago, we learned that switching from one “library” to another, in the software, would let us overcome that issue. However, the host that runs Ladybug only recently installed that software library, so it seemed like a good time to fix our code to make use of it.

It didn’t seem like a huge task – I had set aside an afternoon to do the update. Thanks to fine coding work by Peat of Blue Hill Solutions, there was only one file that needed to be rewritten, and it was very clear and accessible to a non-expert programmer like myself.

But here’s what I didn’t expect: I dove in, rewrote the library in one swift pass, and it worked perfectly the first time! These kinds of things rarely happen in the software world (trust me), but are far more common in Ruby and Rails than in other languages and frameworks.

I can’t tell you how happy this made us! The benefits were instant and very real, for both us and our clients, most of whom are using Ladybug. What a rewarding afternoon!

I was in a meeting with a client the other week, and we were talking about our technology choices, made in the course of developing the current version of their site. I was basically trying to talk them into a “site refresh,” feeling that the technologies supporting their current site weren’t serving them as well as they should be.

This is a hard sell, especially when you are the person who helped choose those technologies! Sure, the client always has opinions, and those sometimes aren’t as flexible as you would like. But time marches on, and so does technology. A few years ago, we were all about making websites 100% Flash. We still love building those websites, and many of my favorite Needmore projects are those sites. In fact, the site belonging to the client in question is one of those very sites!

So how do you talk them into changing?

During that meeting I uttered a quote (and I’m surely not the first to say this) that I remember quite well. “We make the best decisions we can based on the information that is available to us at the time.” That means that it is entirely possible for times to change, and for better ways of doing things to come along. When we and our client decided upon the Flash-based site, there were several distinct advantages:

1. It looks awesome, especially with great photography.
2. You have an incredible degree of control over the user experience.
3. Thanks to Ladybug, it’s easy to update the site.
4. No-one can steal your graphics (or text, for that matter).

Yet over time, we found a greater number of disadvantages that would be addressed by an HTML-based site.

1. It can still look awesome, with the same photography, fonts, and color scheme.
2. You can still have great user experience, thanks to JavaScript interaction and effects libraries like Prototype and Scriptaculous. (Don’t believe me? Look at Apple!)
3. Updating the site is easier than ever. As a Flash site grows in complexity and features, it becomes ever-more-difficult to make that site update and interact as well, without writing ever-more code. HTML-based sites alleviate that problem.
4. Maybe you actually want people to steal your graphics and text! In fact, maybe you want them to print it out, email it, and talk about it. Might that not actually help your business?!?
5. You also get better search engine visibility and ranking, RSS news feeds, print-friendly pages, faster page load times, and much better browser compatibility. (No Flash on the iPhone?)

There are probably millions of websites that will continue to benefit from Flash, and we hope to make many more such sites. But sometimes you need to take a step back, practice some zero-based thinking, and make a reasoned decision about your website’s long-term goals.

So we’ve had our iPhones here at Needmore for a couple weeks, and figured it was time to write a little bit about our observations.

Just kidding. We’re certainly looking forward to getting some, but we’re not going to be first in line! Sometimes it’s good to wait a little bit on brand new, very expensive gizmos like that. My cell phone works pretty well and was very affordable, thank you very much.

Watching the iPhone videos, and Steve’s last keynote in January, one can’t help but notice that you only ever see a single website on the iPhone’s Safari browser: The New York Times. And I think the reason is pretty obvious – the narrow columns. The iPhone has a screen that’s very tiny, a mere 480 pixels wide at a vision-impairing 160 dpi. They have a clever little click that lets you tap on a “column” of text to zoom in, which works great on a site with columns no more than 350 pixels wide (and many as narrow as 180 pixels).

That’s a big deal. While the Safari browser on the iPhone is capable of showing real web pages, as opposed to the mediocre browsers on most small mobile devices, it does benefit from those narrow columns. They never show an interior page of the New York Times, with its 620 pixel wide columns. If they did, you might notice the text being a bit more difficult to read, although they do bump up the font size.

The lesson the iPhone is going to teach web developers is to properly adhere to good line length guidelines. This has been worded a few different ways, but my rule of thumb is 10-12 words per line. If you get wider than that, it’s going to be hard to read your pages on such a small screen (unless users are able to enlarge the text, or the iPhone has some built-in intelligence to compensate for this).

I’m sure we’ll learn more lessons as more folks get their hands on an iPhone, but I think paying attention to column widths and line lengths is a good place to start.