The document discusses the three stages that dynamic systems go through: 1) simple content management, 2) beyond basic features like calendars and forums, and 3) building custom web applications. It also covers designing for dynamic systems by using templates and planning for user-generated content. Open source options are discussed, including choosing an existing open source project, using open source, or building your own. The benefits and challenges of using plugins and modules as well as frameworks are summarized. The key takeaways are that the web is becoming more dynamic, systems need to interconnect, and one should consider their business model.

1. Boris Mann Raincity Studios http://www.raincitystudios.com http://bmannconsulting.com The 3 Stages of CMS

2. If I had a tag cloud… Bryght Raincity Vancouver tech evangelist Drupal open source hand waver beer XMPP social software Northern Voice

3. Uh oh. Is he just going to talk about Drupal?

4. But I’m not going to be a Dick

5. Uh oh. Is this one of those talks? (thinks the guy in the back) (be thankful: at the last minute, I almost switched everything to Comic Sans )

6. Oh, and if I don’t mention your favourite dynamic system, it’s because it sux. (actually, it’s all about interoperable systems, but that’s probably someone else’s presentation)

7. INTERACTIVE! (I’d like to keep asking you questions)

8. The 3 stages of dynamic systems. Ugh. Sounds like a thesis.

9. Do I need to convince you that “dynamic systems” are where we’re at? CMS, web apps, RSS feeds, etc. (there’s that pesky thing about dynamic being great for SEO, too)

10. So, here’s the think: every single “page” is becoming a dynamic system all by itself. (Insert hand waving)

11. Furthermore, implementing basic features (such as comments or forums, or a flexible array of RSS feeds, or a decent site search engine) is needlessly complex and difficult in Dreamweaver. … Because online journalism without such basic features is crippled. Dreamweaver Sux

12. This is the part where you tell me about “static” pages.

13. Now we’re going to build an OpenID server in just one “static” page.

14. <link rel=&quot;openid.delegate&quot; href=&quot; http://home.bryght.com/user/3 &quot; />

15. Bonus slide: Remember when your business model was updating individual pages? (We’re actually going to come back to the business model thing)

16. ANYWAYS

17. The 3 stages Designing for dynamic systems Choosing open source Plugin mania Frameworks

18. frack There is SO much to talk about (Maybe we should just listen to Oberkirch’s presentation again)

19. The 3 Stages Simple content management dude, the client wants to edit their own content Beyond the blog calendars. and forums. better add a wiki, too Building web applications I’m pretty sure we need a custom function for that

20. Of course that’s too simplistic. There are stages within those. Upgrades. Redesigns. Budget. Level of technical expertise.

21. How many people use a version control system?

22. Web Applications At some point you wake up and realize you’re adding custom functionality to something that started as “just a website” Congratulations! You’ve got your very own web application! user profiles, personalization

23. 4th Stage “Power of remixable data” (insert Brian Oberkirch’s presentation here)

24. Me == Oberkirch fanboy

25. RSS. APIs. Microformats. OpenID. OAuth. Attribute Exchange. (RDF and the Semantic Web…maybe)

26. Got any other names or labels for types of sites? Does your company slot a customer into a type?

27. Designing for Dynamic Systems The new site map Templates UGC sux (Note: presenter is not an actual designer)

28. The new site map A sitemap used to be literally every page in a site Now, it’s more like an outline of the templates that have to be built Type of page Landing page Maybe: APIs, different types of feeds…and admin screens, too

29. Templates Need to be designing across the entire site Use a grid Use realistic example text e.g. long names; like Really Long Name That No One Will Enter Oh yeah, and you should probably plan for users

30. UGC Sux Your design is finished, then.... comments! forum posts! italics, bold, break tags, and more

31. UGC Sux Less? Include styles for UGC Strip out / close tags Live preview Image resizing (crop / scale / placement)

32. Back to Templates.

33. Template LANGUAGE?! This is the ultimate Designer meet Developer CSS is programming! And then the developer was all, like, just learn this little code snippet…

34. <meta http-equiv=&quot;X-UA-Compatible&quot;…

35. That was a cheap shot. But, MSFT made fun of my hair once

36. Push vs. pull is kind of interesting.

37. TEMPLATES. Whatever. They’re all painful. Suggestions? (I’m pretty sure any phrases involving XML and/or XSLT transforms is going to be painful)

38. Choosing Open Source Open source doesn’t mean free Become an expert Small local firms rolling their own

39. What’s your business model? It’s probably not selling bits What are you actually selling? It probably is process, expertise, design Maybe a side of services (but, like Josh said, hosting sux)

40. .NET open source? (Sharepoint, not so much, unfortunately. Plugins, maybe?)

41. Community Return on Investment (ROI)

42. Why the frack is this guy talking about open source?

44. Three choices? Resell someone else’s code Use open source Roll your own (I know we’re in Vangroovy. But rolling your own is not cool .)

45. A story about local web design dev firms.

46. Everybody else’s code sux! I’m building my own! I’m going to get $paid$ to code more stuff, too.

47. Wait…what’s your business model again?

48. Of course… …open source SUX. It’s badly documented, it’s unsupported, and it doesn’t work like it says on the box. (but at least you’ve got someone else to blame)

49. We’re all in this together. Going open probably means more of the open web gets built more quickly.

50. Anyone got some business models to share? (it’s all about the icons and Facebook apps)

51. Plugins and Modules Virtually all systems have a way to extend the base Sweet! New functionality for free! Except… Installation, training, configuration Updates and security “Just one more tweak” to the design

52. We’re going to take an interlude to the base of the system you’re using.

53. Don’t hack the core.

54. Well, if you’re going to hack, make some patches.

55. Back to plugins… (They’re like hacking without the hack)

56. Build up a set of features / list of plugins that you know are good. Covet them. Don’t add to them. Have a backup plan. (Like: this goes on the we might add this in phase 1 list. Might.)

57. Of course, you can build your own. (Oooh! Maybe this is your business plan?)

58. Designers: make some mock ups. If they’re pretty, developers will want to build it. (can you crowdsource your next website?)

59. Clients/Users: maybe you have the same pain as other people. Can you fund a common solution? Can you make an existing one suck less?

60. Developers: please don’t re-invent the wheel. (Except, sometimes, we need a crazy one to do things differently)

61. Got any cool plugins to share?

62. Frameworks 100s (thousands?) of frameworks Rails (Ruby) Django (Python) Symfony (PHP) (Note: building from scratch is not an option) (No, really, it isn’t)

63. Where is it going to be deployed? PHP tends to run everywhere. (Tip: sneak PHP into enterprise by deploying it on a Java stack)

64. Real programmers tend to love just about anything better than PHP. Except for Java.

65. Are there people locally that use your framework? (There are tons of TYPO3 users in Germany)

66. Don’t forget about libraries!

67. Yeah, I know the frameworks bit in here was short. Did you think I was going to start a flame war? Got something else to share?

68. Let’s wrap it up

69. The web is only going to get more dynamic.

70. All these things need to talk to each other.

71. Think about your business model.

72. And I didn’t even talk about internationalization. (the English web is a pretty small place)