Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind
•
3 gefällt mir•5,808 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (15)
Ähnlich wie Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind
Ähnlich wie Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind (20)
Mehr von Julia Kulla-Mader
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Moving from a Static Site to a CMS or from one CMS to Another Without Losing Your Mind
- 1. Best Practices in Moving from a Static Website to a CMS (or from one CMS to another): How Not to Lose Your Mind in the Process Julia Kulla-Mader http://www.juliakm.com @JuliaKM
- 2. Julia Kulla-Mader IT Manager at the AASHE Drupal user/developer for 4+ years 2
- 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. 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. 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. 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 Section: Rely on objectives, not hunches. 6
- 7. Start By Identifying Stakeholders Sandra Bob Section: Rely on objectives, not hunches. 7
- 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 Sandra Section: Rely on objectives, not hunches. 8
- 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 Bob Section: Rely on objectives, not hunches. 9
- 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. 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 objectives Section: Rely on objectives, not hunches. 11
- 12. Example - from AASHE Section: Rely on objectives, not hunches. 12
- 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 Team Section: Rely on objectives, not hunches. 13
- 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. Objectives: Rinse and Repeat • Throughout the process, when questions or suggestions arise, measure against your objectives Section: Rely on objectives, not hunches. 15
- 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 launch Section: Build the site for the person who will be maintaining it two years from now 16
- 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. 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 Ian Section: Build the site for the person who will be maintaining it two years from now 18
- 19. Choose a CMS that Works for Ian and You • Maintainability • Marketplace • Building Blocks • WYSIWYGs Section: Build the site for the person who will be maintaining it two years from now 19
- 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. 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. 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. WYSWIYGs What’s HTML? Ian Section: Build the site for the person who will be maintaining it two years from now 23
- 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. WYSIWYG: Disadvantages • Extraneous tags • Time wasted cleaning up bad HTML • Pasting from Word can be a headache Section: Build the site for the person who will be maintaining it two years from now 25
- 26. WYSIWYGs: An Alternative • Markdown Section: Build the site for the person who will be maintaining it two years from now 26
- 27. Markdown/Textile: Advantages • Your site will look the way your designer intended it to • Easily edit text and perform simple formatting Section: Build the site for the person who will be maintaining it two years from now 27
- 28. Markdown/Textile: Disadvantages • Users have to learn the basics of a new markup language • Users cannot “make it pink” easily Section: Build the site for the person who will be maintaining it two years from now 28
- 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. Bottom Line • Choose a CMS that works for you (Maintainability, Marketplace, Building Blocks) • Choose a WYSIWYG that works for you and future you Section: Build the site for the person who will be maintaining it two years from now 30
- 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 launch Section: Design and implement a user-driven redesign process 31
- 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 plan Section: Design and implement a user-driven redesign process 32
- 33. Start with Navigation • Navigation visually defines your organizations priorities • Navigation helps people from veering off track • Navigation keeps people on your website Section: Design and implement a user-driven redesign process 33
- 34. Navigation: Card Sorting Is Your Best Friend Section: Design and implement a user-driven redesign process 34
- 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 wireframed Section: Design and implement a user-driven redesign process 35
- 36. Wireframing Tools • Balsamiq, Omnigraffle, Visio, Photoshop Section: Design and implement a user-driven redesign process 36
- 37. Test Wireframes • Test wireframes with your stakeholders through questions against your objectives Section: Design and implement a user-driven redesign process 37
- 38. Wireframe and Test Again Until You Feel Good • Making changes to a wireframe is easier than making changes to a live site design Section: Design and implement a user-driven redesign process 38
- 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. 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 required Section: Design and implement a user-driven redesign process 40
- 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 queries Section: Design and implement a user-driven redesign process 41
- 42. Migration Step Three: Content Inventory • Go through each page on your website and assess whether you want it to be imported Section: Design and implement a user-driven redesign process 42
- 43. Migration Step Four: Test in Bunches • Migrating everything at one time is a recipe for disaster Section: Design and implement a user-driven redesign process 43
- 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 tests Section: Design and implement a user-driven redesign process 44
- 45. Test and Test Again • Develop personas to test your site Claire - Grant Officer Shironda - Student Section: Design and implement a user-driven redesign process 45
- 46. Engage Stakeholders Again at the End • Let your stakeholders evaluate whether you have met your objectives Section: Design and implement a user-driven redesign process 46
- 47. Launch! 47
- 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. The Fourth Trimester: Support after the launch • Monitor feedback to your revised site • Have a plan in place for responding to questions and concerns Section: Plan for support after the launch 49
- 50. Think Carefully About Permissions • As you give staff access to the website, think about who should have what editing privileges carefully Section: Plan for support after the launch
- 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. 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 updates Section: Plan for support after the launch
- 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
Hinweis der Redaktion
- I ’ m Julia and I ’ ve been using Drupal for approximately 4. I work for the Association for the Advancement of Sustainability in Higher Education. We have multiple Drupal-powered websites and soon no static sites.
- In graduate school, for personal sites, and at my previous job at DesignHammer and at AASHE for 3 years I ’ ve participated in many, many redesigns - some of these were transitions from static sites, some were transitions from other CMSes, some were entirely different. At AASHE, I moved our static site to a CMS (Drupal) right when I started. We recently relaunched the site, still in Drupal, following the approach I ’ m going to talk about today. I also have a lot of experience with one CMS in particular, Drupal. I have used Wordpress before as well and have no experience with Plone.
- Before we begin, I think it would be useful to lay out some of my assumptions. First, you have an interest in redesigning or in some way improving your website as you move to a new or different CMS. Also, I expect you to know what a CMS is. I also am gearing this talk to nonprofit techies, who work with a board of directors. If you don ’ t, it doesn ’ t mean that this talk isn ’ t relevant, but my examples might not be.
- I know that memories are short, so I ’ ve organized this talk into the three things that I ’ d like you to remember. First, I ’ m going to talk about laying out your objectives for the project at the beginning. I ’ ll talk about how we did this at AASHE and how you might do this for future projects. My second goal is that you think about the person who will be working on your website two years from now when you make decisions like what CMS to go with or which, if any, WYSIWYG editor to choose. Last, I ’ d like to suggest that you pursue a user-driven process complete with lots of cheap user research. I ’ ll talk about the easy ways to involve users in your redesign process.
- I know that memories are short, so I ’ ve organized this talk into the three things that I ’ d like you to remember.
- Key Audience to keep in mind throughout this section: Sandra the long-time staff person, Bob the board chair. Sandra wants
- to have a website that she can easily edit and that meets the needs of all of the members she talks to on the phone each day.
- Bob the board chair is very concerned that the website make the organization look professional.
- In this example, Sandra and Bob would probably have very different perspectives. For example, Sandra ’ s biggest issue might be the time it takes to make a website update. Bob might be more concerned that a potential business partner sees the website as unprofessional. Bob might also know that the board is thinking of hiring a branding team, which could totally change the project and website.
- At the end of the day, we want Bob and Sandra to both see it as successful. The key to this is making sure that they agree on
- This is an example objective from the AASHE redesign. We started off including objectives about the CMS (drupal) but ended up taking them out because we wanted people to be discussing things on a higher level
- The key here is that your entire board probably doesn ’ t want to be involved in each phase of the project. Additionally, your whole staff probably doesn ’ t need to be involved in each step of the process.
- When engaging stakeholders, it is useful to separate out the core and extended teams.
- Whether you meet your objectives is the ultimate measure of success. Sandra and bob need to be able to explain why the project was successful when it finishes
- Meet Ian the intern. He ’ s in charge of updating the website. He also is an expert at care3, a new awesome social network. You want Ian to be happy but you don ’ t work at your organization anymore.
- The big question is how do we meet Ian ’ s needs in a way that still will make you happy. The biggest issue I ’ ve seen in my years of working with Drupal and running our local Drupal user group is the problem of maintainability.
- You want to make sure that someone at your organization can easily upgrade your CMS and add necessary security fixes. Some content management systems are easily to upgrade than others. For many years, Drupal was a horror show to update if you didn ’ t know a little system administration. It ’ s better in Drupal 7. Similarly, Wordpress tends to be darn easy to upgrade. If this isn ’ t the case, I ’ d highly recommend going with a software as a service platform.
- It ’ s important to scope out the job market for developers and administrators for whatever CMS you go with. For example, if you love Refinery, a Ruby on Rails CMS, are you going to be able to find people in two years to help you maintain or update it?
- There ’ s always something new and awesome. Ian is going to have some great ideas and it would be best to find a CMS that can grow with you. You want the best and brightest working on your CMS. For example, the White House uses Drupal and contributes back modules.
- Ian the intern doesn ’ t know a lick of HTML
- As part of the AASHE redesign, I spent a lot of time cleaning up bad HTML.
- In Drupal, we use Markdown and it has really cut down on the amount of crap HTML on the website. It is this crappy code
- Ultimately, I advise you to weigh the needs of Ian and the rest of the staff with your own sanity. You are the best person to decide whether your organization can culturally handle going away from a WYSIWYG
- You want Ian to enjoy using the site and for the site to be ready for whatever comes next
- Card sorting is an opportunity to engage many people in your redesign. It ’ s also a way to get around hidden biases. Show examples of card-sorting data.
- You can test your wireframes with your stakeholders and online using tools like ...
- You can test your wireframes with your stakeholders and online using tools like ...
- Test with stakeholders early, test with users later. Don ’ t let stakeholders give open-ended feedback. Just don ’ t.
- - Options for migrating static files - Writing custom code, utilizing existing tools
- One of the easiest ways to clean up HTML is to cut and paste into a text editor - this is the low-tech way
- Your opinion counts for something. If you have a hunch something isn ’ t quite right, then go for it. Membership section story
- Shironda is a student looking for academic programs information
- Let your stakeholders evaluate whether you have met your objectives
- This is tricky, it ’ s something we ’ re still struggling with at AASHE