The CRUX of the Matter: Amplifying Authentic Voices Across the Institution
•Descargar como PPTX, PDF•
33 recomendaciones•3,143 vistas
In 2015, Dartmouth will launch a shared content repository to serve as the bedrock of our 200+ institutional sites. With an emphasis on the content repository user experience (CRUX), we are separating content from form, building a digital commons that renders silos invisible on the surface, and empowering site editors to join the narrative wave. Follow along as we tangle with questions of territoriality, authorship, and credit while we bring the COPE model to a diverse, distributed network on sites. This session will cover: Transitioning from high geek to high speak as we follow the arc of the web from data to conversation. Modernizing the digital press to execute the distributed message. Managing the community: how we provide education to help people understand both the toolsets and the concepts of shared content (in plain language).
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (16)
Último
Último (20)
The CRUX of the Matter: Amplifying Authentic Voices Across the Institution
- 1. The CRUX of the matter Amplifying Authentic Voices Across the Institution
- 2. The Web Services Team
- 12. “Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs
- 26. Will the crazy thing fly?
- 27. The Holy Grail
- 34. Hope
- 39. A Trinity of associations
- 41. The Octopus
- 42. The Candelabra
- 44. ONWARD! Courtesy of Sven Aas
- 48. Things will get broken
- 49. We are here Deep in the machine
Notas del editor
- We’re undertaking a project that will modernize the way we create and share content across the Dartmouth web, where the hinge point for success lies in the the design of a content repository user experience.
- We like to think of ourselves as a progressive web team, focused on User Experience Design from the perspectives of content strategy, architecture, design, and engineering. We are: UX designers Information architects Content strategists Front end developers And we fully support the sites that we build. Here’s a picture of the team in 2012 when we started this project. We need to add some new faces to this collage.
- I’m Sarah. My title is content strategist. In that role, I focus mostly on user experience design, usability, and building our community of practice.
- I’m Susan, Director of Web Services. An architect by training, I believe the web is a critical part of our built environment. I come to this project with interests in system design and universal design. And I have had a long term relationship with mass communication tools – how to use them, how they work, and how they are built.
- We all work on the web, most of us in higher ed. We have a lot of frustrations in common. We struggle to create, distribute, and maintain useful, usable, accessible content. And we’re hampered by systems that no longer fit.
- Why is it so hard? To begin with, there is just so much of it. Erik Schmidt, CEO of Google, shared an incredible stat: every two days, we are producing as much information as we did from the dawn of civilization up until 2003. Every two days. He said that in 2010. Today, in a single minute, we collectively upload 72 hours of YouTube videos, post 216,000 photographs on Instagram, and write 26,000 Yelp reviews. In one minute. No wonder we struggle. We are drowning in it.
- In 2005, there were 64 million websites on the Internet. Today we’re at 960 million. Now, it’s been estimated that up to 75% of those sites are unactive or just domain parking. But that still leaves us with a quarter of a billion active websites. At Dartmouth, on our little corner of the Internet, our team manages 10% of the thousands of sites under the dartmouth.edu domain. Within the 200 sites we support there are over 10,000 “pages” of content.
- With this much content, It’s hard to find our way. It’s hard to find what we need. It’s hard to keep track of it all. It’s hard to get it in the right place at the right time. It’s hard to be consistent. Let’s face it: we’re in the dark ages of content management.
- How many people have participated in a web redesign project? How about a migration to a new CMS? At Dartmouth, we were overdue for a new design and we had a lot of technical debt. Often redesigns focus on looking better. If you’re just putting a new skin on the same old content organized the same way, it’s like putting new paint on a rotting house. It’s not going to solve your problems. At best, it will hide them for a little bit.
- Sometimes redesigns include new content and structure at the highest level (home page and top-level navigation pages). But once you get a little further down in the site hierarchy, you’re back to old design, old structure, old content. We often only staff the top layers of our web presence with skilled communicators and are then shocked when we discover that most of our web content is not so good. With more people arriving at our websites from the side doors through search and social, we need to have a comprehensive approach to improving communication in the middle layers.
- But there’s a reason people do surface-level redesigns. Tearing down rotten infrastructure and putting up a shiny new site with better layout and better navigational paths is a huge undertaking and you’re going to want a new site again in 5-10 years. To make it worth it, you can’t follow the same old plans to build a new house. You want to build something that will be remodelable. You need to create pieces that makes sense for now and can be reused in the future.
- Redesigns shouldn’t just be about appearances. If you’re really talking about design and not just surface appeal, then you’re talking about function.
- In higher ed, we tend to have a lot of silos. We’re divided and it’s making us nuts. But we’re not alone. After 10+ years of siloed web content management, all industries are in the same situation. The CMS made it so anyone could update a website. So everyone updated websites, often independent of each other and without any sort of over-arching content strategy. The result: inconsistent navigation, hard-to-find information, conflicting information. Content management systems have matured and are now capable of so much more than they were before, so our approach needs to mature, too. From being siloed, we all need to shift to a sharing model.
- The solution that we are circling around is both audacious & inevitable. As in the case of the Zonkey, it’s something that can happen and will happen under the right circumstances. 5 years ago we couldn’t have this discussion about changing the way the system works under the hood. Our websites were pretty simple and delivered flat content, but today the lines have blurred between website and web application. And we expect more from them. They are our communication engines and equally important, they now manage critical operational information for both external and internal audiences. As the web evolves beyond information presentation towards engagement & personalization, we’re perfectly positioned to tackle this change.
- From high geek to high speak, the evolution of the web is the driver for this project. When we consider the arc of the web, it traces the increasing role of communications expertise in content creation. In the early days, indexical sites delivered simple information with hyperlinks. Later they became more organized and searchable, driven by improved search engines. These older sites employed the pull model, where the information sat there until someone wanted it. Now our audiences desire purposeful, story driven narratives, increasing the need for engagement through social channels and moving us towards the push model of personalization.
- Social media can be a model for how our websites evolve. People are creating content more than every before. Anyone with access to the web – and that number is growing – can contribute. The information that users find most valuable gets shared and spread and reused. Gartner says that by 2020, 80% of all web content will be user-generated. So what does this mean for our websites? What if we commit to shared content as the foundational principle for our institutional websites? Instead of just looking better, we can be better. We can offer: More consistent user experience More accurate and up-to-date information More authentic voices that represent our institutional goals, values, and experiences A more flexible system that separates data from display, so we’re ready for future changes, whether that means a simple visual refresh or a change in distribution And an easy-to-use system that encourages community participation
- To do this, we need to develop new tools. Our models come from social media and include crowdsourced blogging platforms like Medium and the ease of editing in Facebook. But we all know that these systems are created and held together by deep corporate pockets. Lacking said pockets, we need to do this in a methodical, iterative way. We’re taking a phased approach to building a shared content repository that will ultimately underlay more than 200 institutional sites.
- But here’s where we came from: Even though our academic department sites have the same types of content (courses, major/minor, events, people), the IA was totally inconsistent from site to site. Users were forced to relearn navigation paths. Design was inconsistent from site to site, with no shared visual language, giving users the impression that we were a disjointed or uncooperative community. Content almost exclusively informational and targeted to internal users (in opposition to analytics data). Often the IA reflected internal structures rather than user behavior. Information hoarding (can’t let go of content, even if no one outside dept. needs it, because they don’t know where else to put it).
- Phase 1 updated addresses these general problems on academic department sites. New design, new CMS, new consistent IA approach. Content more narrative and more externally focused. Home pages are dynamically generated and include news, recent publications, and events (no static content).
- Here’s an example of an internal page on one of our academic sites on the legacy CMS. It’s a giant wall of text. The text itself is not bad. Like Jessica Rabbit, it’s not really bad, it’s just drawn that way.
- Here’s the same page, essentially the same text– only very minor edits. But it’s more structured. During phase 1 migration, we worked with site editors to clean up their content and add better structure. We were starting to introduce them to the idea of content as chunks, not pages.
- Here you can see how we implemented consistent information architecture during phase one. Undergraduate is always on the left. If there is a graduate program, then graduate comes next. News & Events and People are always on the right. In between is where we can adapt to department needs.
- Phase 1 for admin and center sites, we did a visual refresh. This is still in our legacy CMS. But it accomplishes a few things: one, it slammed sites back into an institutional template to prepare them for what’s coming in terms of design consistency. It also soothed anxieties (“When is it my turn?) and bought us time. More thorough content/IA cleanup will come with migration to Drupal.
- Old attitude: set it and forget it. Some site editors were attempting to use their sites to highlight news, events, etc. but many would update only course info once a term. Many pages on old sites that hadn’t been touched in years. With new system, trying to shift understanding of sites as entities that must be nurtured, cared for, fed and pruned on a regular basis. Distinction between evergreen content (basic pages), which shouldn’t need updating often, and dynamic content, which should be added regularly. One tool that has helped site editors begin to understand this approach is an editorial checklist, which includes suggestions for weekly, monthly, termly and yearly tasks. We have a starting point, and I work with site editors to customize it to represent their particular goals and needs. It helps encourage an active rather than reactive approach to their content.
- Another of our challenges is content overlap, ultimately leading to incorrect information. Copy/paste is not a content sharing model. Here are 3 examples that describe our challenges: When Dartmouth hired a Title IX coordinator and gave her ownership of all content around sexual respect, She discovered it was distributed on multiple sites. Ultimately, we ended up rounding up and consolidating all this content on a single site and created links to it from the other sites. This is the only solution when you have static content. Our student handbook is assembled of numerous policies, which are owned by different departments. The handbook appears in part or in whole on multiple sites. Updates have to be carefully coordinated. And finally our faculty directory. Faculty or department administrators would maintain profiles on dept. sites that were completely different from those maintained in the institutional faculty directory by DOF. Duplication leads to conflicting information; from a user’s perspective, if two pages disagree, then they are both wrong. We knew we needed a system which held content separate from the display from which our editors could curate consistent content into their sites. In phase 1 of our project, we make strides by creating two mini repositories to demonstrate distributed but shared content authorship and content curation: the event calendar and the faculty directory.
- Like many projects, you start with a list of everything you can possibly want Then go through the tedious process of cutting things out and identifying priorities Figuring that out takes commitment and time with ongoing discussions about where to make hard fast rules and where to compromise Our biggest challenges were: 1. Creating standards in a community that is highly individualized “We want it to be automatic …. Except when we don’t, and in case 1, 2, 3….” 2. Balancing the creation of an intuitive interface that doesn’t make the system so complicated that it is a difficult to maintain and extend We are building in Drupal where flexibility can mean either you’re a gymnast or a contortionist – we definitely want to be a gymnast!
- Create once publish everywhere, the COPE model, is the Holy Grail of the digital publishing world. It was important to have a POC that our community could use as a toe hold to get involved in the important work of breaking down content silos. In the first phase of the project where we tackled new design – “looking better.” We also dipped our toes into “being better:” in 2012 we made our home site responsive – at a time when only the Boston Globe had committed to this mobile strategy and we launched the renewed faculty directory and events calendar, both acting as precedents for the COPE model At the time we didn’t fully realize that this was the POC for the content warehouse concept, but people liked the functionality and we got excited about the possibilities. We’ve learned a lot from these first attempts and are applying that knowledge to the work in progress.
- The faculty directory is the source of truth, where the editing gets done by individual profile owner. Faculty have access to a single piece of content, their profile, but can hand off their editing privileges to someone else, if needed.
- As it is sent to other sites, we needed to apply site specific configurations – typically taxonomies that sort people into different groups. For example: regular faculty, assistant or associate professors, and lecturers. In the biology site, Professor Ayres has multiple categorizations within a single site, adding even more complexity to the sorting of his profile. This need to apply different configurations in every location was a driver for our eventual content repository distribution model.
- As a test bed for our site editors to understand the concept of content sharing, the faculty directory paved the way. The learning curve was variable, but the payoff was enormous, and success lies in the fact that our users are asking for more of this type of functionality! There were some problems, of course! Fine tuning caching and explaining the mechanism to our editors understanding who applied the taxonomies and when assigning and handing off profile editing privileges Our team was able to address these issues through improved training, clear process communication, and technical solutions. We also learned that we didn’t need to build every nuance of functionality in on day one; it was better to put out an Minimal Viable Product and make improvements over time.
- In preparation for the building the digital press, last summer in two sessions, we dedicated time to looking at our project with an outside consultant – a technical architect. The goal was to re-envision our publishing platform to create a comprehensive approach for shared content that improves information quality and consistency, and to position Dartmouth to be ready for the next big jump to more personalized experiences. In addition to giving ourselves time to inventory our requirements and map out a tentative architectural plan and a functional spec, we studied the needs of our editors and created user stories. The challenge is to introduce a sophisticated system without overwhelming editors who are already overburdened with technology changes.
- First part of redesign focused on improving user experience for site visitors. But we’re also focusing more on improving user experience for site editors. We’ve gathered feedback from editors about what works and what doesn’t for them, and we’re trying to improve that experience in new platform. This includes taking the time to pay closer attention to microcontent and helper text on user interface, which we couldn’t really address in phase I because of time constraints.
- Persona development and user stories were critical to the success of the content repository. We decided to think about our users on a scale based on their level of comfort as web editors: Did they like the work? Did they understand the system? Did they want their content to be useful for the end user? Did they know too much and get frustrated by the restrictions of a tool? Our team supports 500 site editors and now about 600 faculty who maintain their individual profiles – range of digital literacy and technical skills is highly variable.
- Additively our team had 25 years of experience working directly with our community of editors Institutional knowledge adds up to several decades. We were able to map our site editors along the spectrum from web savvy to web comfy. With day-to-day support, we mostly interact with the outliers, so it’s easy to lose perspective. It turns out that most of our editors actually fall in the “web comfy” space.
- What do we mean by web comfy? Although not necessarily web savvy, they do want to learn and would benefit from a community of practice. We knew we should be enabling their growth as web editors by providing a good UX interface and improving training opportunities.
- Bulk of burden for creating and maintaining content falls on department admins. Editors don’t see themselves as communicators. Web falls under “other duties as assigned.” New narrative/external approach presents a big challenge for our site editors. Previously, training focused solely on how to use the CMS. We didn’t offer content curriculum, in part because we didn’t have a content person until I was hired two years ago. We used to say “we build the roads and you drive the cars.” A big part of my role is drivers ed: teaching our site editors how to use their sites to present content that furthers their goals.
- We’re stepping up content curriculum. Writing and editing for the web part of our standard site editor training now. (Short version for small groups; longer interactive session for departments or professional development workshops.) Before we give editors access to new Drupal sites, they complete a two-part training. The first session includes writing and editing for the web, as well as an introduction to content strategy, taxonomy, editorial strategy and calendar planning, and content types. Second part shows them how to use the CMS. We had a learning curve with our training. Can’t just say, “Here’s a new tool!” Need to anticipate training needs and articulate how tool should be used. Future classes and workshops focusing more specifically on working with specific content types and developing new content, not just text but also visual media.
- We’re also encouraging them to crowdsource content (ask students, faculty). Some have hired student helpers for this purpose. We’re easing them into the idea of a future where your site is a curated collection of content originating from multiple content creators. A lot of curriculum now is paving the way for understanding new platform. Current Drupal system asks editors to consider purpose, behavior, and timing of content in a way old, static sites didn’t require. Complete shift in thinking.
- Our next steps were gearing up for the build. It was critical to have multiple perspectives on the design and good oversight on the build. We asked the questions: 1. Had someone had already designed this wheel and we just needed to copy what they did? 2. Was this something only the wealthiest corporations could afford? We needed to expand our horizons on precedents and advice for what we knew would be a complex system design. The best way to do this was to look both inside and outside of higher ed. We had selected Drupal as our content management system in 2012 during the redesign phase when the visual and interactive design was done in partnership with Digital Pulp. We partnered with Acquia for Drupal hosting and additional professional services to help get our team up to speed. And early this year we selected OHO Interactive for the engineering and the build of the new platform.
- Let’s take a quick look at the process of choosing a content distribution model. The first question we needed to answer was: Are we a hub/spoke or are we a tree? Our priorities were deceptively simple: 1. Make the operation within the content repository as seamless as possible for our editors; at the extreme end of that requirement, they shouldn’t even know it exists. 2. Keep the content repository system completely separate from the sites that display the content.
- In the hub/spoke model, which we called the Octopus, all content would originate in the content repository and get distributed to sites for assembly. Think of a shopping cart and your closet, two very different experiences. Although this model was elegant and simple, it didn’t address the reality of site specific needs for content – remember the faculty directory. It also required that our editors create and manage content in two different interfaces.
- In the tree model, the candelabra, all content would originate in the “leaves” - the child sites. Depending on the type of content, it could be made shareable or kept local. Shareable content could be locked and sync’ed or made available for duplication. This model makes it easier to apply site specific configurations such as the ones we knew were needed for the faculty profiles to work differently on many sites. The ease of using and interacting with eventually thousands of distinct pieces of content would make or break the project, so selecting the right distribution model was critical. All our decisions about the design, from content tracking, taxonomies, where to break data into separate content types, and how people would search, find, and distribute content to individual sites, responded to the touchstone of user experience.
- When you’re building a cathedral, it’s easier to have vision, than it is to execute the plan. We can’t emphasis enough the importance of a clearly documented blueprint in order to maintain momentum under leadership changes. To get the resources and keep them, communicate the vision and demonstrate small successes along the way. Create a 5 year plan that fully describes the goal through a series of realistic steps and be prepared to shift when the road turns unexpectedly. Access to budgets need to be creative at times and we were able to piggyback the phases of our build on other capital improvement projects.
- And you’re going to need a champion! It doesn’t have to be a single person, in fact its better if the champion is a team. The champion needs endurance, persuasive voice, humility, an understanding of technical and political challenges, and contagious enthusiasm. Be prepared to tell your story again and again until you can't stand saying it anymore
- Connect with your village: the community needs to feel ownership. Clearly define what you're asking them to take on and make sure it is something that they want to do. Define the small steps that start to lay the groundwork for an improved system and push back on crazy launch timelines in the interest of building durable systems. Be a voice for crafting the invisible layers.
- Buidling a cathedral describes the community vision and dedication it takes to make big changes and to see improvements through from start to finish. Cathedrals embody the idea of people working together to realize a shared dream and hone their skills while achieving it. Appeal to a sense of community craftsmanship – where everyone has a role, everyone is learning, everyone is contributing, everyone has a chance to try something new A craft is something you get good at over time, through improving your useful tools, and sharing knowledge.
- Most importantly, this is an iterative process, never ending. What we learned in the last two years has influenced our current direction. 2012: we tackled design and build 2013: launch and learned 2014: envisioned improvements 2015: design and build By the time we finish the build, it will be time for another visual refresh.
- Manage expectations! Things will definitely get broken along the way. Those moments lead to new ideas and opportunities for strengthening the system. Pressure testing can only happen in the hands of the user. Building confidence and commitment to an idea, sometimes depends on the current system being terribly broken. This is a major transition for people and systems. Be realistic with everyone about bumps in the road along the way.
- So where are we today? Working with OHO and Acquia, we’ve taken a tour through the first diagrammatic UX prototype and we are optimistic. We’ve received a first delivery of a working repository where content creation, sharing, syncing, and locking has been demonstrated and works! Next, we will be doing user testing, crafting the content types, and we look forward to launching our first sites in the new system by the end of the year.
- Where do we want to be in 5 years? How does the amplification of the authentic voice - the voices of faculty, students, alumni, and others who have interesting stories to share - get accomplished from here? Today we’re trying to move the needle from informational sites to narrative engagement. We’ve had significant success in phase 1 and in the migration of our academic sites. By the end of phase 2 we should have a nascent intranet – MyDartmouth.
- MyDartmouth will begin its life as audience gateway pages with some simple options for personalizing links, updating your profile, and submitting community announcements. Then we’ll return to a discovery phase and map out its growth as the portal for crowdsourcing content.
- Once the system is in place, how do we get the users there? We need to produce good documentation, create a curriculum, and build a community of practice. Ideally we would like to create a certificate curriculum in which editors need to become proficient in certain skills before they have publishing privileges. These skills would include: Writing and editing for the web Creating accessible content Visual literacy (selecting and adjusting appropriate visual content) The number of content creators is predicted to grow and putting the tools in place now to anticipate that growth is a step in the right direction.
- Success also depends on learning to share. We all own a piece of the pie We need to make sharing easy and demonstrate the benefits. Create sturdy content types that have conditional logic that allows different skilled editors to engage with content creation at a level that is appropriate for them. Use a universal taxonomy based on department of origin and apply additional filter states based on content types and, when possible, audiences types. The system will need to prove itself by being accepted by users.
- And we expect that our users will teach us how to use the system. Once they are in there, they will use the system in ways we can’t even anticipate, and again, it’s an iterative process. We’re also thinking about the persuasive design elements. How we do make people want to contribute? Once possibility is to gamify the system to help elevate good content and give people incentive to improve. Over time, contributors will see what content is successful and what isn’t. The system itself becomes a part of the curriculum. In the future, the system trains the user.