Recently I was presented with a website navigation problem. The problem presented itself as we drew up plans to enhance security on our site. In our security scheme, some pages are accessible to authenticated users, others are not, and others require an extra layer of security. This is pretty typical. The problem is deciding how design user navigation through the site that does not enforce a overly rigid path, that flows through existing pages before presenting the final result.

When you speak about a series of steps or events that are preliminary to a final step, you often speak in terms of workflow, or wizards as a means to that end. Wizards are the generally the best workflow technique because they are easy to understand, use visual cues to indicate the progress, and because users are familiar with them. It’s a paradigm that universally relied upon by software developers. Wizards are standard interfaces for software installers. They are used heavily by web merchants. Even your mom knows what a wizard is. Why is that? Well, for one, there’s really no other way to do it. Anytime you can enumerate “In order to do A, you do first do X, Y, and Z”, then you are in wizard territory.

An installer or a wizard implemented in a desktop program can easily enforce the path of information gathering, through modal dialogs. There’s really nowhere else to go but forward or backward. Where web wizard interfaces are concerned, the code behind the wizard has to do extra verification to insure the wizard is followed correctly. The information is stateful, and must be persisted between steps; after all, the user can decide to browse off to facebook during the process, and may jump back into the wizard at any place in the series of steps.

This is why web wizards should be extra-friendly – they should outline the steps in advance, and they should show breadcrumbs in the intermediate steps to make it obvious to the user where she is in the process. The Amazon Services wizard is a case in point – it’s very easy to use and understand. Before the wizard begins, a graphic illustrates the number of steps to completion. The point is to make it dead simple to sign up.

More...

Tags: wizard, navigation, asp.net, redirect

Quite a bit has been written on this topic, and I’d like to add my two cents worth. I chose BlogEngine because I liked the architecture. Even though the default configuration does not support OpenId, the posts I read on the subject beforehand showed just how easy it is to integrate. This post isn’t a primer on that, however; if you are looking for that information, read this post at Chris Blankenship’s blog, or the thorough discussion on the BlogEngine forum, then go grab the latest code at dotnetopenauth.net.

I had several goals in mind when I set up this blog. First, I decided that I would not use the BlogEngine native user registration feature, except for my own authentication with Live Writer. To this end, I did the following:

• Before I modified any code, I registered myself as administrator, using the native inputs. I used the first segment of my OpenId user name as my blog user name
• I added my OpenId Url to the administrator list in roles.xml
• I removed the native inputs in login.aspx, and added the DotNetOpenAuth OpenIdLogin control

With the first part done, I stopped to sketch out the other features that I wanted from this integration. Some of this involved changing the default behavior of BlogEngine.

• Authentication is required to comment on posts (but not to read posts, of course). I added a login link next to the comment count, for non-authenticated visitors.
• OpenId authentication requires an email and a nickname, and requests a country.
  • If an email is not provided, authentication fails.
  • If a nickname is not provided, the first segment of the OpenId is used as the nickname.
• The flag is selected automatically by matching the default language and culture to find a country code. I have a feeling that this one is going to get me in trouble…
• When commenting on posts, there is no entry for user name (it uses the registered nickname). The email address is defaulted, but the user can change it.
• Authentication is required to send me a message using the Contact form.

  So far, I have no registered users! But I figure I’ll keep plugging away and sooner or later someone will decide to leave a comment. Overall, I’m pleased with the authentication rules; I have no plan to add captcha to this blog; do you think there are many spammers using OpenId?

One of my goals with these modifications was to change the BlogEngine code as little as possible. I had to change several pages to show or hide items based on the state of authentication – for instance, to hide the comment link on the title bar if the visitor is not signed in. I made no changes to BlogEngine.Core.

In the web project, I modified Contact.aspx.cs, Login.aspx, Login.aspx.cs, CommentView.aspx, and CommentView.aspx.cs.

In the theme, I changed PostView.ascx, PostView.ascx.cs, site.master, and CommentView.ascx.

For the future

I’m planning to add a feature in the near future to qualify certain downloads as only available to authenticated users. At present, any visitor can download the meager bits of code I’ve posted. I plan to post more substantial projects that will require authentication. I’ll also make that code available, when I get around to it!

Tags: openid, authentication, blogengine.net