Alex Hardy

A video of yesterday’s SDK event is online at Apple’s website.

Much will be said in the coming months. In the words of Jason Fried of 37Signals:

What we saw today was the beginning of two decades of mobile domination…

Enterprise features (e.g. Exchange support). AOL Instant Messenger. Console quality games (the Super Monkey Ball demo was allegedly built in just two weeks). A comprehensive software development kit, to be released in June.

The 30% sales tax by Apple seems steep at first, but developers can set their own prices and won’t have hosting/bandwidth or credit card processing costs. They also gain a platform and delivery channel with millions of users and an installation mechanism that’s as easy as buying a song. I think most will find these terms livable.

The iPhone / iPod Touch platform just became a deadly rival to every mobile phone, PDA, media player and handheld videogame console out there.

I bought TextMate last night. While I use Dreamweaver at work, TextMate is now my editor of choice at home for my personal projects. It completes a trio of shareware development tools which also includes CSSEdit and Transmit.

My reasoning is simple: I don’t like Dreamweaver very much. To say that its feature set exceeds my requirements and it has performance and stability issues is probably the kindest way I can express my feelings about it. It’s also very expensive.

If you are a Mac-based web developer, these three apps are a winning combination.

As a follow up to my post about the future of Microsoft Internet Explorer, I should note the passing into history of another browser. AOL ended support for Netscape as of February 1st, effectively pulling the plug on its life support.

I started to learn web design and development at university in 1996. At that time, Netscape Navigator was a major player in the browser market. Since then its market share was eroded by Microsoft’s integration of IE with Windows, upstarts like Firefox and an apparent lack of interest and direction from AOL (who bought it in 1999).

So Netscape joins IE5 on the list of dead browsers where the difficulty of supporting them massively outweighs the benefit. The number of visits I get from Netscape users is so negligible (0.13%) that it is no longer worthwhile to test against it.

AOL’s advice to Netscape users is to upgrade to Firefox.

UPDATE: Corrected a factual inaccuracy in the original post.

Microsoft have posted on their IEBlog that they have decided to modify their stance on version targeting in Internet Explorer 8. The previous suggestion that developers would have to explicitly invoke IE8’s standards compliance mode (via a meta tag) was a well-meant but controversial move.

The rationale was that the doctype switch is no longer effective. Less educated web developers were expected to omit the doctype in ignorance of its purpose, but equally well-meaning software authors have added them into the page templates in their applications.

Microsoft, quite rightly, take their responsibilities as the dominant browser maker seriously and don’t wish to “break” millions of websites in pursuit of web standards support. The goal was to find the lesser of two evils.

Purists were not happy, even though high profile developers like Jeffrey Zeldman and Shaun Inman came out in favour of it. In Inman’s words:

The strong have always been tasked with carrying the weak. In the case of the ongoing X-UA-Compatible bluster, the strong are the savvy standardistas. The burden? A single meta tag or http header. Can we move on now?

If you were knowledgeable enough to add the tag they argued, then go ahead and add it and stop moaning. Fair enough…

Microsoft have decided though that even this is not fair enough, and have done a u-turn in favour of standards. A meta tag switch will remain, but for those that want their pages to render as under IE7. If your website looks wrong under IE8 standards mode, it is far less painful to quickly add a tag while you address the problems than to have a broken website.

I applaud this move, and Microsoft’s commitment to openness and interoperability. Apple could learn a thing or two about that. The “browser wars” will be truly over not when only one app is left standing, but when web professionals can get on with creating content without worrying about browser quirks.

Check out Trism, an upcoming puzzle game by Steve of Demiforce. GameSetWatch have posted an interview with him. It looks like the accelerometer may do for the iPhone what the stylus did for the Nintendo DS.

If people like him can create gems like this with no tools, documentation or support from Apple then I can’t wait to see what appears once the SDK is released.

As I’m now working on simpleContact Pro I need to tackle licensing a commercial self-hosted application. I’ve been looking into how others do it and there seem to be a variety of options. Putting aside price for now, the dilemma is actually a collection of smaller issues:

• I want as many people as possible to use and benefit from my software
• If many people profit from my work and few buy it, I’d call that “getting ripped off”
• Per-domain licensing seems a little bit too strict
• Usage of an app where the code is not compiled would be impossible to police
• My resources are too limited to invest significant time and effort in the above

On reflection, the licensing model I’d like to adopt is as follows:

• Application costs x, for a personal use license (not restricted to one domain)
• Installation for a third party (e.g. a web designer working for a client) dictates a transference of ownership and requires a new purchase
• A user is not permitted to re-sell the software
• They may however charge for installation as a service at their discretion
• Charities or non-profit organisations may request a free copy of the application
• Users are trusted to act in a professional manner – no active policing
• Support will be denied to users who do not have a license

So what do you think?

I’ve added a support forum to this website. I refer to this as a “soft launch” because I haven’t integrated it with the rest of the site, graphically or in the navigation. The only exception is a link on the footer for the downloads page.

My reasons for this are simple:

• I wanted to add a forum to help support current users of simpleContact 1.2
• To get it live before releasing simpleContact 2.0 Pro, so I can document it
• I didn’t want to be sidetracked from building ‘Pro to make the forums purdy

You’ll find sections for FAQs, installation, troubleshooting, requests, miscellaneous and a section that I’ve called “Out and About”. This is where you can earn yourself some link-love by posting about your simpleContact powered website.

Let’s get a discussion going

UPDATE: Added a link to the contact page.

Cabel Sasser has released the JavaScript image zoom used on his blog and Panic’s website as FancyZoom. It provides a nice smooth zoom effect, caption and drop shadow.

Free for non-commercial use or $39 per domain.

Some may find the price a little steep for what is no more than a slick alternative to Lightbox (which I use myself) or Thickbox, but I can see it being popular with people who want a web gallery to be über cool.

One of the best things about web development is that there is always something new to learn, no matter how much you know. If you want to really learn how to build a solid, portable application then I’m convinced that the best way is to release one.

Users will be swift to report bugs and incompatibilities for you. This isn’t negligent; it’s natural. A developer can’t anticipate all possible configurations and behaviour. Your response is what matters. You may be equally swift to issue a fix, but issues may sometimes go unaddressed because the effort outweighs the benefit.

Issues with simpleContact have been rare, but a self-started forum thread caught my attention last week. A member commented that they hadn’t been able to submit their name properly. I’ve researched the matter and in the interests of transparency I’m going to present what I found and what I plan to do.

Character encoding is a thorny issue that few bother to understand and implement in a considered way. There are articles on the web that cover the subject in detail, so rather than re-hash their points I’ll add some relevant links at the end.

The issue

simpleContact uses MySQL’s default collation, which is latin1_swedish_ci – fine for English and most Western European languages, but other languages (e.g. Greek, Japanese, Russian etc) will not be stored or represented properly. This is a matter I wish to address because I want as many people as possible to use my software.

The ideal course of action would be to process and store data in UTF-8 encoding. UTF-8 is a multi-byte character encoding that supports the characters of just about every language in the world.

Advice abounds for how to reconfigure your server and scripts to use UTF-8, but matters are more complicated when users will host an application on their own site. As developers of apps like WordPress and Mint know, ideal configurations in shared hosting services and availability of non-default PHP extensions like mbstring can’t be guaranteed. Some of the servers I have access to lack the necessary functions.

The easiest thing would be to put up a wall and say “If you don’t have x, you need to get a better host”. Meanwhile back in the real world, users are far more likely to reject an app than swap hosts. A middle ground has to be reached.

The solution

UTF-8 support must be added, but not without respecting a user’s situation. I plan to keep Latin-1 encoding and collation as a baseline standard for compatibility. It is better to support a subset of commonly spoken languages than not to work at all. For users whose server supports mult-byte string functions, the database will be silently upgraded to UTF-8 and appropriate methods will be used in PHP.

Beyond that, there isn’t much else. If you want a truly international solution and your host won’t support mbstring then you really do need to choose another host.

So what next?

I have fixed the feature-set for simpleContact 2.0 Pro and don’t intend to add UTF-8 support to it. When 2.0 is done, it will become a high priority feature in version 2.1, which will be a free upgrade. I will add it to simpleContact Lite in due course.

Useful links

• Joel Spolsky – The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• Nick Nettleton – PHP UTF-8 cheatsheet
• Gabriel Walt – StumbleUpon PHP: [Tutorial] Character encoding
• Wikipedia – ISO 8859-1 (Latin-1) and UTF-8

I started work on simpleContact 2.0 Pro tonight. That is, I started to sketch my ideas on paper. To decide what will make the cut for the first release. To start working on answers for the what ifs and formalise the database structure that’s 80% designed in my head. The key features will be:

• Custom form fields. My most requested feature, which was always planned.
• Double opt-in mailing list. Services like Campaign Monitor insist on this.
• CSV export. This acts as a bridge to other software and services.
• Client-side validation. Powered by jQuery, a nice-to-have that I want to add.
• Easy upgrade. simpleContact 1.2 users can migrate settings and data easily.

I’ve gone back to good old fashioned paper because design comes first. I want to use my experience as a web designer to build an elegant solution to real needs. There will be no comparison tick list. I won’t add useless features for their own sake. I’ll be adding some over time however, that I’ve seen nowhere else…

I want to make something that’s remarkable because it makes a difficult thing easy. One user was kind enough to share that he’d tried seven other products without success before simpleContact 1.2. It is very rewarding to get feedback like that.

I’m not going to commit to a release date because of my schedule, but I’m going to aim for May/June. Version 2.0 Pro will cost $25, and the existing free version will remain, re-branded simpleContact Lite. Version 1.3 Lite will follow thereafter.