Dear friends, loyal readers and newcomers,

For quite a while I have been working on my pet project JungleDragon, a social image sharing community that focuses on nature and photography. Today, the very first public test version is launched and I need your help to test it. Everybody is invited, including your friends, coworkers and family. The best tester can win a cash price of 100$!

It does not matter whether you actively test or just peek around, all feedback is welcome. Please do consider the following important resources:

• staging.jungledragon.com (the permanent test location)
• About the test environment and contest
• How to give test feedback
• JungleDragon FAQ (gets you acquainted with the project and features)
• JungleDragon Facebook fanpage (where you go for feedback and discussions)
• JungleDragon blog (behind the scenes development updates)

If you are in my network, I may bother you via other ways as well.

Special thanks to Bas Peters for sponsoring and helping to setup the test environment, and of course many thanks to you in advance for helping out!

Enjoy. I need you.

For the past two years, my project JungleDragon has dominated this blog. I very much realize that although I have shared all progress that I made, I have failed to truly involve you all. This will change very soon.

Within a matter of days I will launch a public alpha test environment of JungleDragon. I will invite all of you to test it and give me feedback. I invite you to bring friends along as well, the more the merrier. I will even reward the best tester with a 100$ reward.

The alpha test environment will consist of what I call the JungleDragon core functionality. It is pretty much what you can expect from a social image community. Nevertheless, I want this base thoroughly tested before I move on to production code and more sophisticated features. The alpha environment is for testing only, its URL and data are temporary.  I do intend to keep a permanent testing location open so that I can keep on getting your feedback. It is about time.

I'm currently in the middle of some unholy tasks such as cross browser testing and fixing, and writing help documentation. Next awaits the configuration and preloading of data. As I said, all should be ready within a few days.

I need you more than ever. When the alpha environment is ready, I hope you want to be involved in testing, whether it is 1 hour or 10. If you cannot find the time or interest, what about your friends?

Stay tuned...

Although I promised earlier to cut back on dead tree tech books, I was lured into the above title. I'm a web standards man, largely because of the Jeffrey Zeldman movement. Therefore I have been keeping an eye on the development of HTML5 and CSS3 via the blogs.

When I heard Zeldman launching A Book Apart, a publishing firm targetting web designers and developers I could not resist getting a copy of their first title HTML 5 for Web Designers.

The goal of the book is to give a short (only 85 pages) overview of the history of HTML5, it's major features and strategies for usage. It very much succeeds in doing that. Topics are explained in a mild, human writing style. You should see this as a nugget of knowledge, a 2 hour light and practical introduction into HTML5.

Still I was hoping for more. Some of the more intruiging features of HTML, the ones you do not hear about on the blogs, such as local cache stores and the UndoManager are hardly spoken of. Maybe this is because the HTML5 spec is not done yet. The book is reasonably priced, but combined with international shipping, it turns out quite expensive for such a short knowledge intake.

All in all the book is solid, entertaining and to the point. I am happy, but I do not consider this book a must-have at this point. Still, I look forward to additional titles from this new publisher.

For a few months now I am considering implementing OpenID for JungleDragon. But some things are holding me back. Hereby I want to share those things. 

First, a very limited explanation of what OpenID is...

OpenID is designed to avoid the issue of having a set of credentials for each seperate website that you sign up for. Unlike previous commercial attempts like Microsoft Passport, OpenID is a non-profit organization that seems independent and free of any special interests.

How does it work? OpenID is a distributed authentication model. OpenID is not a singular service that lets people authenticate to all websites from a single place. Instead it defines a standard for authentication and let others implement it. Those are called providers. Sites like Yahoo and Facebook are providers of OpenID authentication. 

Sites that let users log in via OpenID are called OpenID consumers. Some sites are both providers and consumers. In theory, OpenID brings two very practical benefits:

• For users, it will be easier to join and sign into web applications. They can reuse their set of credentials at a trusted service of their choosing.
• For developer, there no longer is a need to waste effort on implementing login forms, login logic, account management such as password resets, and the general need to store user passwords securely. All of this is "outsourced" to the provider. All a developer needs to do is link the open ID to his own internal user store.

Such is the theory, but as often in life, real life gets in the way...

OpenID usability

You'd think that OpenID improves usability, and it can. But there's a few drawbacks too. 

The first problem is in OpenID adaptance. Very few OpenID consumers exist (sites who accept an OpenID login). Therefore it not considered a convention. Your users may not be used to signing in the OpenID way or may not trust giving their credentials to a site this way. But there is more confusion. It seems a proprietary authentication mechanism called Facebook Connect is gaining popularity too. This is yet another way of signing in. Unlike OpenID, Facebook Connect's authentication stays on the original site, which is better for usability.

Second, the OpenID experience is different. With OpenID, you basically sign in using a URL (of your provider), and next optionally using your provider's authentication mechanism (most often email address and password, but not if you're signed in to the provider already). In this process, the user is taken from the original site to a different site and then back. 

A popular way to make signing in using OpenID easier is to place shortcuts of the most likely or popular providers at the login screen, as is implemented by StackOverflow:

I am a big fan of this implementation. But I'm an internet savvy user with an existing account at one of these providers. Not all users will be in this situation or will be comfortable with this method. And what if their provider is not listed? They can log in using the field at the bottom but how usable is that? How we can we expect a "common" user to even know what OpenID is, how it works and remember their provider ID?

OpenID security

OpenID is as secure as the OpenID provider is. Google Mail is my provider and I trust that it is safe.

That does not mean that OpenID in a holistic scenario is safe though. The biggest threat is phishing. Users who regularly use OpenID will be comfortable with a site redirecting or popping up a login form of the provider of the user. This trust can be misused easily. I can create a login screen and place popular provider icons on it. Next, when the user clicks on Google, I launch a popup with a fake copy of the Google login form. The address bar will still be in green. My fake popup will not have the Google.com URL but only eagle eyed users will notice this or even know that this would matter. Next, I capture the user's credentials and their Gmail account is "hacked".

As far as I know there is no solution for this. It is inheritent of the fact that you authenticate at another site.

OpenID effort

OpenID can save a developer a lot of work in authentication, password storage, etc. However, it can also add a lot of work and complexities. Whilst I have not done an OpenID implementation yet, I did read into it and investigate the issues. The most common challenges seem to be:

• If you truly would like to server a large group of users, you will want to implement OpenID on top of your own authentication logic. This is to maximize the comfort of the entire user group. This issue may not apply for a controlled environment or special audience. Needless to say, if this issue occurs, OpenID will only add effort, not reduce it.
• Actually implementing OpenID robustly seems to not be trivial. One big issue is that there are differences in how the different providers actually handle and implement OpenID. You may need to make a few code variations of the same thing.
• At one point, you will need to integrate OpenID identifiers with your own user store. Such an implementation can be confusing, because you need to offer the user a way to disassociate a provider with your internal account. Why? Perhaps because the user no longer holds an account at his provider or perhaps because the provider just stopped their service. To make matters worse, the same user could authenticate to your site using different providers.

My impression so far is that implementing OpenID is not impossible or rocket science, but not trivial either.

Conclusion

I've passively went through the thougts above for a few months now. I can see the value in OpenID, but I don't take the drawbacks lightly. For now, I've decided to not implement OpenID in the first version of JungleDragon, a decision I may revisit at any point. My main reason for not going the OpenID way right now is in the messy authentication landscape (OpenID, Facebook Connect, Twitter oAuth, etc). The other reason is effort. With a long todo list and limited resources, it just does not play it at this point.

This post was mostly me publishing my internal decision making. I hope it is useful in triggering you to think about OpenID as well. What do you think is it's future? The consequences of an implementation? Reasons to use it or not?

Passing on a quick tip that I learned about last week: If you are on IE8 and want to test your website for IE7, you can do that very easily, directly in IE8. Just hit F12 to open up the developer panel:

Next, in the top menu (see red box), set your browser mode to IE7 and your document mode accordingly. Keep this panel open for as long as you want to test.Of course, there is also IETester if you want to test for even more IE versions. Whilst pretty good, I found it quite unstable and prefer the more "native" approach used here.

Continue reading...