Sometimes (a lot of times) I’ll design a screen or some code and I think “not bad”. Since it’s not bad, it gets my approval and gets moved into production. Thankfully, I often realize that it’s not a bad idea to revisit those designs and see if there’s something I can improve upon. That just happened (Ricky Bobby, anyone?) with SendAlong’s upgrade confirmation page. The differences were drastic enough that I figured they merited mention, if only so that you can learn from my mistakes.

Here’s the original “confirm upgrade” screen:

I look at the above screen now and it’s painful – the design is horrible. Let’s think about the goals for this screen:

• Tell the user what to expect (how much do I have to pay?).
• Reassure the user that they’re going to get what they expect (clear information, no surprises).
• Encourage the user to complete the process (click the button).

I think the above screen does a pretty lousy job of achieving those goals. Here’s why:

• It’s crowded – there’s too much going on for the user to be able to easily focus – buttons, text, blah blah blah…
• It’s too general – I used an existing template for this page – but sometimes certain pages can benefit from a bit of extra attention.

If you’re a designer, I’m sure you see more problems that just those two. My poor naïve eyes only see the most surface level problems – but the good news is that surface level usually catches 80% of the problems, as seen in the new screen below…

I like this page a lot more. Can you see the difference? It just works better, it’s more focused, and it’s tailored specifically to the goal:

• There’s a lot less information – the user can focus on the task at hand.
• The user knows exactly what to expect – the prices are printed in big bold font, not in small print.
• All of the extra navigation has been removed – this helps direct (”funnel”) the user to the goal.

Not bad for a little bit of work. Here’s the same screen before and after, but in this scenario the user has already entered his payment information and all that is needed to complete the upgrade process is clicking the button. Which of the below screens do you think will result in more upgrades?

Do you have any other suggestions for improvements?

Today was a very exciting day for SendAlong – it’s release was picked up by several sites (mostly the US and parts of Europe). I was absolutely blown away this morning when I checked the system and saw the number of sign ups – let’s just say it was a bit more than I expected! If you’re interested, I posted about some of the reviews on SendAlong’s blog.

The bad news is that I might have to purchase a paid plan for CrazyEgg.com – I’ve been using the Free plan which records up to 5,000 visits per month. SendAlong’s gone through that many visitors since Monday alone! That means CrazyEgg has stopped recording statistics for me for the time being. The month rollover will happen on Saturday, so I think I’ll stick it out on the Free plan for a bit more, but CrazyEgg is definitely a service I can’t live with out, so I’ll probably wind up upgrading (no, they’re not paying me for saying that!).

I can’t describe how hard it was to make myself *not* check my email throughout the day as I worked. Talk about an exercise in self control:).

Ok, back to work. Looks like it might be a late night.

One more thing worth noting – I actually just pushed a new version out to the servers. Mainly just some UI tweaks and small bug fixes. Let me know if you like the new tour page and home page better. And if you haven’t signed up for a free account yet to try it out, you really should:).

Just a quick bit of news that makes me very, very happy to be able to announce:

I’ve officially released SendAlong 1.0!

It’s been a labor of love and…labor, but it’s been worth it.

I’ve got so many things planned for SendAlong – it’s exciting that I’ve finally got 1.0 out the door so that I can refocus and start implementing what so many people have been asking for.

Oh, I’m not sure if I mentioned this before, but SendAlong is built primarily on Amazon’s S3 and EC2 – they provide a very secure, reliable, and scalable architecture that’s suited quite niciely for what SendAlong is providing.   I can’t *not* mention eapps.com as well, though – part of SendAlong is hosted on there as well, and their support with getting things set up has been invaluable.

SendAlong is just about feature complete for the 1.0 release, which will hopefully be in mid February.

To help roll out 1.0 smoothly to the general (paying) public, I’ll be running a beta program up through the 1.0 release.

Here’s where you can help: if you’re interested in helping shape SendAlong or just lending a helping hand in general, email me at jon@sendalong.com to get in on it.

Of course you’ll be rewarded handsomly for your help. How does 6 free months of a Premium account sound?

Contact me if you’re interested.

I have to admit, for single sign on in Java, CAS and Acegi go together about as well as peanut butter and jelly. Milk and cookies. Cake and ice cream…I should go grab some breakfast.

If there’s any interest, I may write up the steps I took in integrating CAS with Acegi.

Up next is making the CAS login page look the same as the rest of SendAlong, which should be pretty easy. Other than that, there are just a few loose ends to tie up with regard to SSO, and then I can be on my way to more interesting endeavors.

I’ve got the basic CAS demo up and running, successfully doing single sign on between different webapps running on different servers. That link is actually an excellent guide to get you up and running quickly with CAS. Give it a shot if you’re just getting started.

Now on to Acegi integration…

I’ve decided to go ahead and try to get JA-SIG’s CAS configured alongside Acegi (Spring Security). I gave the Acegi docs and the CAS demo docs a couple of reads and it looks like it shouldn’t be too hard to get things set up properly. I think the thing that befuddles me most is all of the SSL configuration, but that’s going to be a requirement with any (secure) option, so I figure I might as well go the CAS/Acegi route since someone else has already documented most of the work for me.

Any time I find myself working on security of any sort for an application, I realize how difficult security is to get right. It’s one of those fields that has SO many variables (what the heck is an X.509 certificate?!). But thankfully it’s a problem a lot of people have already encountered, and therefore there are lots of how to’s out there. Thanks goodness:).

On another note, I realized that I’ve never laid out any big picture ideas for SendAlong on this blog. Seeing as how the name of the blog is “SendAlong Blog”, in the near future I am going to make more of an effort to write up some of the details about SendAlong itself.

Does anyone have any ideas on how to accomplish an easy single sign on (SSO) setup?

A little background: SendAlong is built using a sort of spoke and hub architecture – there’s one main server (the hub) and several secondary servers (the spokes). It’s worth mentioning that the secondary servers are far away from the database, so database access is slow, and therefore needs to be minimized and optimized like hell.

When a login occurs on the hub, the user will eventually spend some time on one of the spoke servers during the same session. Instead of the spoke prompting the user to log in again, the user’s credentials should be carried over to the spoke transparently (thus the SSO).

Any ideas on how to do this (easily)? SendAlong uses Acegi (Spring Security) for security, and right now I’m investigating CAS for SSO. CAS and Acegi seemingly integrate very nicely, although there’s a LOT of configuration required to make it happen. I’d be happier with a less complex, more limited in scope solution that I actually *understand*. That said, security is tough. No, security is really, really tough. So perhaps a simple solution isn’t in the cards.

All that to say – anyone have any ideas?

Gosh, I hadn’t realized how bad the main SendAlong logo looked until Chris pointed it out to me. After a little reworking, here’s the before and after.

Much better!