<i>Things are looking fairly slick thanks to jQuery UI and a lot of AJAX, but it has been a bit of a handful to test. If you have suggestions for doing so, I’d love to hear about them in the comments. Mostly I have been doing unit testing for models which are likely to have failures, and then doing manual testing to verify that the UI works how I expect it to.</i><p>I have suggestions. Use Capybara with Selenium, driven by either Cucumber or Steak (Steak is just rspec + some extra syntactic sugar; I prefer it, myself).<p>You won't be able to test <i>everything</i>, especially complex user interactions. However, you should be able to test about 80-90% of the site functionality, and, importantly, you should be able to test the purchasing functionality (the balls of your app, so to speak) since that should always be simple.<p>One of the decisions we've ended up leaning towards on Woobius is that we think twice about implementing UIs that can't be tested. If it can't be tested as designed, we spend some more time trying to figure out whether it can be redesigned in a way that can be tested but is still clear to the user. It's just one more design constraint, basically - can it be tested. If it really cannot be done in a testable way, at least we provide an alternative method that doesn't use fancy javascript and/or flash. For example, for the flash uploader, we also have a basic uploader. This means everything else can be tested, just not the multiple upload.
If you don't have time to read the whole post, at least read the "Speaking To Customers" section. It has great illustrations of the eye-opening ideas you get from listening.
I appreciate the simplification of a lot of lingo from lean/custdev down to something closer to "you make fewer mistakes when you talk to customers." Much less intimidating and great to see some tangible results already.<p>Will be interested to see how you keep utilizing the virtual assistant. I have a terrible habit of hiring them with a particular task in mind, getting all excited, and then letting them idle for months.
This is great. Hits several things in completely different areas that I've been dealing with too. (Namely setting up Rails in production and talking to customers on the phone.)<p>I think the best thing about these kinds of posts is how down-to-earth they are.<p>I mean, I do love the posts about the successful startups that are now running with 5-man teams, scaling their production environment to handle millions of visitors, etc. But those posts are a glimpse-of-the-future to me and probably to most others here.<p>This post on the other hand is basically about the exact situation I find myself in right now with my product.<p>Thanks for posting!
I love reading these kinds of posts, and Patrick always does a particularly great job at explaining why he makes the decisions he does. It's like usesthis.com for startups.
When I clicked through to your Wufoo form to sign up for launch notification, the visual change was quite jarring--from soothing green to washed-out grey. It felt very alien. Maybe if you carried over the same green background over it wouldn't have had the same effect.<p><i>I</i> know what Wufoo is, and that it'll be safe to give them my email. But your less-savvy customers might wonder where the heck they've bounced to.
Patrick, Thanks for sharing so much about your new service and what it takes to get off the ground. I'm curious if you plan to use a true merchant account for handling credit card payments since AppointmentReminder orders are probably going to be larger in value than Bingo cards.<p>Also, do you plan to form some kind of business/formal entity? I see reference to Kalzumeus but is this just a placeholder? I'd love to hear thoughts on those aspects when launching a new service.
Glad to see Patrick's aiming for a November launch. Patrick, have you considered adding Appointment Reminder to the startups at <a href="http://www.startupmonth.org/" rel="nofollow">http://www.startupmonth.org/</a> or joining the facebook group?