Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind

7,629 views

Published on

Published in: Technology
  • Be the first to comment

Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind

  1. 1. Best Practices in Moving from a Static Website to aCMS (or from one CMS to another): How Not toLose Your Mind in the ProcessJulia Kulla-Maderhttp://www.juliakm.com@JuliaKM
  2. 2. Julia Kulla-MaderIT Manager at the AASHEDrupal user/developer for 4+ years 2
  3. 3. Why am I qualified to give this talk?• Website redesign alumna• Just relaunched AASHE.ORG• Long-time Drupal user/developer• New mom 3
  4. 4. Some Assumptions• You are interested in redesigning/reorganizing your organization’s website while you move it to a content management system (CMS)• You are familiar with the concept of a CMS• You work for a nonprofit organization with a board of directors• You work in nonprofit technology 4
  5. 5. Four Things I Want You to Remember• Rely on objectives, not hunches• Build the new site for the person who will be maintaining it two years from now• Design and implement a user-driven redesign process• The fourth trimester: plan for support after the launch 5
  6. 6. Four Things I Want You to Remember • Rely on objectives, not hunches • Build the new site for the person who will be maintaining it two years from now • Design and implement a user-driven redesign process • The fourth trimester: plan for support after the launchSection: Rely on objectives, not hunches. 6
  7. 7. Start By Identifying Stakeholders Sandra BobSection: Rely on objectives, not hunches. 7
  8. 8. How do we meet Sandra and Bob’s needs? • Doesn’t see a need for change • No familiarity with HTML, comfortable to send edits to IT • Wants to be able to quickly point members to website information • Prefers to spend as little money as possible SandraSection: Rely on objectives, not hunches. 8
  9. 9. How do we meet Sandra and Bob’s needs? • Thinks the current site is “cluttered” • Heard about a great new CMS from his nephew last week • Wants the site to look professional • Loves lots of pictures and movies BobSection: Rely on objectives, not hunches. 9
  10. 10. Before You Begin: Gather Background Information • What is the problem we want to solve? Why are we doing this? • Has this been attempted before? Why did it fail or succeed? • Is anything at my organization in flux that might change this project?Section: Rely on objectives, not hunches. 10
  11. 11. Develop Objectives with Sandra and Bob • How will we measure whether the project is successful? • Each person on the team needs to agree to the project objectivesSection: Rely on objectives, not hunches. 11
  12. 12. Example - from AASHESection: Rely on objectives, not hunches. 12
  13. 13. Plan to engage stakeholders throughout the process • What phases of the decision process would benefit from involvement by various stakeholder groups? {What phase would not?} • Should Bob participate in every decision? What about Sandra? Core Team Extended TeamSection: Rely on objectives, not hunches. 13
  14. 14. Example - Engaging Stakeholders Core Team Sandra - Program representative You* - IT Manager/Web developer Matt - Web developer Paul - Exec. Dir * Project Manager Extended Team Board member Member representative Representative from Team A Representative from Team B Representative from Team C Core Team
  15. 15. Objectives: Rinse and Repeat • Throughout the process, when questions or suggestions arise, measure against your objectivesSection: Rely on objectives, not hunches. 15
  16. 16. Four Things I Want You to Remember • Rely on objectives, not hunches • Build the new site for the person who will be maintaining it two years from now • Design and implement a user-driven redesign process • The fourth trimester: plan for support after the launchSection: Build the site for the person who will be maintaining it two years from now 16
  17. 17. Two Years is a Long Time Ian “Intern”Section: Build the site for the person who will be maintaining it two years from now 17
  18. 18. How do we meet Ian’s needs? • Doesn’t care about what a CMS is • Wants to quickly edit the website • Wants to integrate the latest social network, Care12.com • No familiarity with HTML IanSection: Build the site for the person who will be maintaining it two years from now 18
  19. 19. Choose a CMS that Works for Ian and You • Maintainability • Marketplace • Building Blocks • WYSIWYGsSection: Build the site for the person who will be maintaining it two years from now 19
  20. 20. CMS Maintainability • Can you easily upgrade? • Can you add security fixes?Section: Build the site for the person who will be maintaining it two years from now 20
  21. 21. CMS Marketplace • How hard is it to find people who are familiar with your CMS?Section: Build the site for the person who will be maintaining it two years from now 21
  22. 22. CMS Building Blocks • Can your CMS potentially handle all of the fantastic features you want to add in the future?Section: Build the site for the person who will be maintaining it two years from now 22
  23. 23. WYSWIYGs What’s HTML? IanSection: Build the site for the person who will be maintaining it two years from now 23
  24. 24. WYSIWYG: Advantages • Anyone who has used Word can add or remove content • Anyone can “make it bolder”Section: Build the site for the person who will be maintaining it two years from now 24
  25. 25. WYSIWYG: Disadvantages • Extraneous tags • Time wasted cleaning up bad HTML • Pasting from Word can be a headacheSection: Build the site for the person who will be maintaining it two years from now 25
  26. 26. WYSIWYGs: An Alternative • MarkdownSection: Build the site for the person who will be maintaining it two years from now 26
  27. 27. Markdown/Textile: Advantages • Your site will look the way your designer intended it to • Easily edit text and perform simple formattingSection: Build the site for the person who will be maintaining it two years from now 27
  28. 28. Markdown/Textile: Disadvantages • Users have to learn the basics of a new markup language • Users cannot “make it pink” easilySection: Build the site for the person who will be maintaining it two years from now 28
  29. 29. WYSIWYG: So what should I do? • What’s best Ian and you? • Who will be updating your site on a daily basis?Section: Build the site for the person who will be maintaining it two years from now 29
  30. 30. Bottom Line • Choose a CMS that works for you (Maintainability, Marketplace, Building Blocks) • Choose a WYSIWYG that works for you and future youSection: Build the site for the person who will be maintaining it two years from now 30
  31. 31. Four Things I Want You to Remember • Rely on objectives, not hunches • Build the new site for the person who will be maintaining it two years from now • Design and implement a user-driven redesign process • The fourth trimester: plan for support after the launchSection: Design and implement a user-driven redesign process 31
  32. 32. What does a user-driven process look like? Before you launch Develop clear, Use card sorting to Wireframe Again and test with universally accepted develop your Again While Testing stakeholders and objectives navigation Against Objectives non-stakeholders Throughout the Process: Create, follow, and revise your migration planSection: Design and implement a user-driven redesign process 32
  33. 33. Start with Navigation • Navigation visually defines your organizations priorities • Navigation helps people from veering off track • Navigation keeps people on your websiteSection: Design and implement a user-driven redesign process 33
  34. 34. Navigation: Card Sorting Is Your Best FriendSection: Design and implement a user-driven redesign process 34
  35. 35. Wireframe Everything Major • You can go through iterative wireframes and data migration at the same time • All pages where people are likely to have strong opinions should be wireframedSection: Design and implement a user-driven redesign process 35
  36. 36. Wireframing Tools • Balsamiq, Omnigraffle, Visio, PhotoshopSection: Design and implement a user-driven redesign process 36
  37. 37. Test Wireframes • Test wireframes with your stakeholders through questions against your objectivesSection: Design and implement a user-driven redesign process 37
  38. 38. Wireframe and Test Again Until You Feel Good • Making changes to a wireframe is easier than making changes to a live site designSection: Design and implement a user-driven redesign process 38
  39. 39. Create a Migration Plan Early • Migration always sucks! Plan to fail 3 times. • Create a migration plan BEFORE you start implementing anything else.Section: Design and implement a user-driven redesign process 39
  40. 40. Migration Step One: Clean up that HTML No programming knowledge needed • Use Dreamweaver Clean Up HTML • Use HTML Tidy Interface (http://infohound.net/tidy/) • htmLawed (http://www.bioinformatics.org/phplabware/internal_utilities/ htmLawed/) Programming knowledge requiredSection: Design and implement a user-driven redesign process 40
  41. 41. Migration Step Two: Plan for Import • Cut and paste • Use a module/plugin that comes with your CMS • Import directly into the database using SQL queriesSection: Design and implement a user-driven redesign process 41
  42. 42. Migration Step Three: Content Inventory • Go through each page on your website and assess whether you want it to be importedSection: Design and implement a user-driven redesign process 42
  43. 43. Migration Step Four: Test in Bunches • Migrating everything at one time is a recipe for disasterSection: Design and implement a user-driven redesign process 43
  44. 44. Reflect Before Moving On • Does something not seem right? It’s easier to change things before you launch. • Feedback Army is a good resource for quick testsSection: Design and implement a user-driven redesign process 44
  45. 45. Test and Test Again • Develop personas to test your site Claire - Grant Officer Shironda - StudentSection: Design and implement a user-driven redesign process 45
  46. 46. Engage Stakeholders Again at the End • Let your stakeholders evaluate whether you have met your objectivesSection: Design and implement a user-driven redesign process 46
  47. 47. Launch! 47
  48. 48. Four Things I Want You to Remember• Rely on objectives, not hunches• Build the new site for the person who will be maintaining it two years from now• Design and implement a user-driven redesign process• The fourth trimester: plan for support after the launch 48
  49. 49. The Fourth Trimester: Support after the launch • Monitor feedback to your revised site • Have a plan in place for responding to questions and concernsSection: Plan for support after the launch 49
  50. 50. Think Carefully About Permissions • As you give staff access to the website, think about who should have what editing privileges carefullySection: Plan for support after the launch
  51. 51. Educate and Support Your Content Editors • Provide a knowledge base for answering frequently asked questions • Have one line of communication for questions (ticketing system, email address, etc.)Section: Plan for support after the launch
  52. 52. Don’t Forget to Update Your Site’s Code • Update code when needed • Have a plan in place for how you will find out about and implement code updatesSection: Plan for support after the launch
  53. 53. Summary: Four Things I Want You to Remember• Rely on objectives, not hunches• Build the new site for the person who will be maintaining it two years from now• Design and implement a user-driven redesign process• The fourth trimester: plan for support after the launch 53
  54. 54. Thanks for listening!

×