This has been sitting in a tab for way too long, so here it is: Ryan Carson on 12 Things You Wish You’d Known Before Building a Web App. Blog post here, slide deck here, audio here.
The audio seems to be for a slightly different deck, but it more or less meshes. Lots of great advice, and well worth listening to a few times.
In the interest of actually getting off the pot, as it were, and posting something about this (and thus triumphantly closing some Flock tabs), I’ll just focus on a few points:
Thing 1 (slide 2): Keep one user database.
The idea here is that if you’ve got more than one web app, put all the users for all systems into one user database, so users of one app will automatically become users of another, thus reducing a barrier.
I disagree with this one. There may or may not be privacy concerns and/or potential security exposures to worry about, but I’m primarily against the idea from the perspective of an eventual exit strategy. Selling one site that contains user information that’s used on another site could be complicated if the sale doesn’t include all affected properties at once, which may not be the scenario that finally happens.
On the other hand, I’m mostly in agreement with the next slide/thing, which recommends having one e-commerce system. I only maintain one non-PayPal commerce system right now, and I’d love to be able to say that 10 years from now. Web users are pretty used to going to a separate site for credit card entry (I’m not sure, but it might even make things seem more secure that way), and keeping everything on one box lets you capitalize on split tests etc., provided your client sites are in roughly similar markets.
In both cases, of course, the back end can be common with different UI code and/or databases (same schema, different db).
Thing 3/Slide 4: Don’t have your coder do the XHTML/CSS
The timing’s funny on this – up until now one person’s handled the whole enchilada, partly because the design firm we usually work with does great Flash and PSDs but lousy markup, but also due to the company size. We just started a project this week where we had the option for the client to supply complete markup.
This was a bit of a gamble on our part (to be honest, I was inspired to go ahead due to Ryan’s talk), since the project timeline and other factors meant we’d have limited ability to send things back to be re-worked if there were problems, but it turns out the XHTML was passable – it wouldn’t validate, but hey, at least it had a doctype that said it was XHTML! The project’s still ongoing, but at this point it looks like we’ll get through it without having to open Photoshop, which is a huge win and has moved “in house designer” way up on my “to hire” list (yes, we’re experimenting with various levels of outsourcing and contractors, but this concept of separation of responsibilities has the potential to create enough work to justify a full time body.)
So a few quibbles here and there (but then again, we’re in a different part of the web industry than Carsonified is), but overall highly recommended. Check it out as soon as you get a chance – if you’re busy now, I can vouch that it sits nicely in a browser tab.
Leave a Reply