50 Caleaxioms for Webapp Development

1. 1. If you choose your technology before your application you'll need to re-invent some wheels.
2. 2. If you decide how your application will look before you decide what it will do you're not building an application for users.
3. 3. You need Personas, Workflows and Use-Cases.
4. 4. Don't let your engineering team define the features.
5. 5. Framework and Feature set can be different.
6. 6. Hire a real project manager.
7. 7. When real users can't be found, talk to Professional Services or Sales. Not marketing or Engineering.
8. 8. Nobody thinks like users – except users.
9. 9. Extra clicks aren't bad if the path is helpful.
10. 10. Wizards are good once – make sure you build a tool that can use them and turn them off.
11. 11. People like MS Office, and it works.
12. 12. Write proper contextual error messages.
13. 13. Build multiple messaging systems.
14. 14. Sometimes webapps need a training system.
15. 15. AJAX won't save you.
16. 16. AJAX won't scale.
17. 17. Hire a proper DBA.
18. 18. Fully addressable apps are better than not. (Multiple access points)
19. 19. Make sure you have someone on your team that knows about session management.
20. 20. Single Sign-on.
21. 21. If your search is broken, fix that first. Then your filtering. Then your navigation.
22. 22. Data grids are a pain in the ass. Everyone wants one and none of the pre-built ones are any good.
23. 23. Nobody wants to Drag-and-fucking-Drop except for sales guys.
24. 24. Spend as much time as you can with the team that is building you app – they will make it or break it
25. 25. Group consensus will kill you and the project.
26. 26. If anyone tells you they need an icon for something and they can't tell you what that something is – punch them in the eye.
27. 27. Feature creep will happen – this is why you need to have a good relationship with the people building your app. (see #24)
28. 28. Don't ignore your Log-in page, error pages, 404′s or anything else.
29. 29. If your app takes more then 2 seconds to do something and you can't make it faster, you need to add a status message, bar, throbber etc.
30. 30. Separate From from Function in the beginning and you can work on them in parallel the whole time.
31. 31. Keyboard controls are sweet as.
32. 32. Users will want to print complex pages – let them and provide them with the right tools to do so. (I like pdfs)
33. 33. If you're going to let your users customize you app, you have to provide support to them.
34. 34. Inline help is awesome, but if you can't support it fully you're better off not having it.
35. 35. Images will need to be localized – make sure your designers have done this before. You do not want to make a "submit" button for every language.
36. 36. German has some very very long words and will ruin your carefully constructed layout.
37. 37. Vertical scrolling isn't bad – Horizontal scrolling looks like a mistake. Always.
38. 38. Your app should use the same language and abbreviations as your users.
39. 39. Business logic doesn't always make sense, but it's what your users are accustomed too.
40. 40. Don't put the "United States" at the bottom of the damn drop down list just to keep it in alphabetical order if 95% of your users will select it.
41. 41. Auto format my telephone numbers, dates and zip/province codes for me. I don't care what the database looks like.
42. 42. Metadata.
43. 43. Prototype everything you can every-time you can.
44. 44. Internal surveys will tell you nothing.
45. 45. Jacob Nielsen and the "Tog" are tools but they are occasionally correct. Although frankly, they've done more harm than good.
46. 46. The Five Hat Racks will save your ass. (Category, Time, Location, Alphabet and Continuum)
47. 47. If you can't draw it on the whiteboard then write it down. If you can't do either you're a manager not a do-er.
48. 48. You need to have a multiple phase and release plan.
49. 49. Testing in the real world is time consuming, expensive and frustrating, but ignore it at your own risk. If you're committed to doing it, hire a professional.
50. 50. Agile development is cool but it runs the risk of becoming too focused too fast and losing sight of the larger picture.
51. 51. Don't read lists. Write your own.

It all started pretty simply… I guess it usually does.

9:16:53 AM goatiki: Any genius thoughts on the right "approach" to application interface design? Any good sources you've seen? We've got a potential project in that vein a'comin', and admittedly, after all of my marketing design years, hard core app interfaces are a little outside my realm of day to day knowledge. 9:17:55 AM calepeeples: throw away the first two and don't let graphic designers on the project 9:18:07 AM goatiki: nice. 9:18:41 AM calepeeples: talk to customers not marketers and engineers are not good project planners 9:19:04 AM calepeeples: I'm gonna write a book 9:20:15 AM calepeeples: Seriously, I follow a UCD approach and it's worked pretty well. the most important thing you need to know is how the users will use the product day-to-day and make those tasks simpler for them. 9:21:16 AM goatiki: okay… sounds like the usual, expected blah blah of good design, but i apprecaite the validation… 9:21:40 AM goatiki: "make it red" was usually enough at the ol' target. 9:21:41 AM calepeeples: it's really that simple – the trick is getting it done