Add new ebook and tweak univserities go rogue ebook.

src/ebooks/keeping-government-consistent/chapters/chapter-1.md

@@ -0,0 +1,22 @@
+---
+title: "Introduction"
+image: "illustration_many-departments.png"
+image-alt: "your alt text here"
+layout: chapter
+---
+
+A state government's web presence is often a loosely coupled network of websites that act as subsidiaries under an umbrella organization, which might be a separate state agency or some digital services governance group. This arrangement presents unique challenges because there are so many stakeholders involved, and the varying needs can conflict.
+
+To make matters worse, the umbrella organization might be responsible for the overall web presence but has no real authority. It can entice, persuade, and cajole, but it cannot enforce any mandates.
+
+In the words of one member of an umbrella organization: “All we have is carrots. We don’t have any sticks.”
+
+Decentralization becomes a challenge when you need to ensure that:
+
+- Consistent branding is applied at every level of the organization
+- Content quality remains high across a variety of independent teams
+- Accessibility requirements are met across every property
+
+We call these decentralized organizations “archipelagos,” borrowing the word used for a collection of islands or sometimes the sea containing a small number of scattered islands.
+
+Of course, state governments are not the only ones suffering from this problem. It can also be seen in universities, large media organizations, and sports leagues. But it shows up reliably in government due to the different ways that stakeholders, intended audiences, institutional conservatism, and agency politics can mix.

src/ebooks/keeping-government-consistent/chapters/chapter-2.md

@@ -0,0 +1,16 @@
+---
+title: "Why Governing Archipelagos Can Be Challenging"
+image: "illustration_umbrella-org.png"
+image-alt: "your alt text here"
+layout: chapter
+---
+
+With most website projects, there are two main stakeholders: the organization and the users.
+
+With archipelago projects, there are three groups of stakeholders: an umbrella organization, its subsidiaries, and the end-users they both serve. This triangle adds a lot of tension. In many cases, the subsidiaries hold sway over the umbrella organization (a Department of Transportation or DMV, for example, brings in more revenue and therefore commands more influence). 
+
+As a result, the umbrella organization spends more time responding to subsidiary needs than to the needs of end-users, and it loses focus on the real audience. Universities never send out RFPs with the primary goal stated as “We need to primarily design this site for tenured staff and the departments that bring in the most money from alumni.”
+
+But this ends up being the goal for many university website projects.
+
+Success in this environment means meeting the needs of these internal users before you can serve any other audience.

src/ebooks/keeping-government-consistent/chapters/chapter-3.md

@@ -0,0 +1,36 @@
+---
+title: "Three Types of Archipelagos"
+image: "illustration_all-models.png"
+image-alt: "your alt text here"
+layout: chapter
+---
+
+Not every archipelago suffers from this “all carrot, no stick” problem. There are three types of governance models we have identified.
+
+### Centralized
+
+The umbrella organization is strong. It holds sway on the technical platform and its implementation across all the subsidiary organizations. Everything from the content model, branding, design, style guide, content management system...all of it flows from the top down.
+
+Typically in a centralized model, most of the staffing in terms of development, design, and strategy also lives in the umbrella organization. There will be subject matter experts acting as editors and content authors in the subsidiaries. Still, to ensure consistency and adherence to standards, their content will often be subject to further review by the editorial staff at the central organization.
+
+### Decentralized
+
+The umbrella organization is weak and subject to very strong subsidiaries. Everyone owns their own properties, and there is no centralized authority whatsoever. Subsidiary organizations will have their own staff, their own rules around content authoring, and, in some cases, even their own branding and design systems. Each island is its own fiefdom.
+
+Harvard University is one example of this model. Departments run Drupal and share a small amount of common code, but aside from the 100 or so pages of the main website (harvard.edu), everything else is 100% autonomous. Each site chooses its own look and feel, branding, and messaging.
+
+### Mixed
+
+The umbrella organization maintains some level of control, and the subsidiaries maintain some level of independence. This is the most common scenario and potentially presents more challenges.
+
+Typically, the umbrella organization owns the technology platform, and the subsidiaries own the content. In some cases, the subsidiaries even have complete control of their branding and design system, but it is more common that they conform to some sort of design consistency.
+
+On the surface, this model makes a lot of sense. Each entity owns a piece of the pie that falls within its area of expertise. But problems occur when the umbrella organization wants to have a coherent content strategy across all these sites or maintain certain standards and they don’t have the authority to make it happen.
+
+Investing a lot of money in a new strategy or platform comes with many risks if the subsidiaries can just take their toys and do their own thing. You must take care not to give them excuses to leave. If too many subsidiaries avoid the new standards, the whole project might be a waste.
+
+Not to mention the potential human cost involved. At state agencies, for example, an ideal platform is responsive and accessible so that it can serve the most vulnerable of the population. If an agency decides not to use that platform and its own solution fails to live up to certain standards, it can leave many people in the lurch. As one end-user answered, after being asked what would happen if she couldn’t access certain state services: “Then I guess I don’t eat.”
+
+How do you succeed in a “mixed” model environment? How do you solve the various challenges and juggle conflicting demands when you have no authority to dictate terms and solutions?
+
+You have to build the most enticing carrot you can possibly imagine.

src/ebooks/keeping-government-consistent/chapters/chapter-4.md

@@ -0,0 +1,19 @@
+---
+title: "The Magical Intersection of Success"
+image: "illustration_umbrella-subsidiaries-users_diagram.png"
+image-alt: "your alt text here"
+layout: chapter
+---
+
+Your task is to find commonality among a group of subsidiaries with different use cases and different audiences, allowing them to work within the same system without excluding their unique aspects. Instead of final end-users, you focus on the people in the middle to find that magical intersection where all their needs can combine into one solution.
+
+After this common ground is established, you must figure out how to extract implementable ideas from it. You must remain focused on this common ground. If you don’t, you risk isolating groups or individuals. They feel disempowered, so they strike out on their own to find solutions within or outside of the system.
+
+And even when new solutions are rolled out successfully, they can fall apart over time due to a lack of persistence.
+
+If your state’s web presence is one of these “mixed” models, where the umbrella organization has limited (or no) authority to mandate standards, four key tasks must be completed to manage the archipelago successfully.
+
+- Do The Research
+- Build Bridges
+- Verify Solutions
+- Measure and Iterate

src/ebooks/keeping-government-consistent/chapters/chapter-5.md

@@ -0,0 +1,109 @@
+---
+title: "Research"
+image: "[email protected]"
+image-alt: "your alt text here"
+layout: chapter
+---
+
+The first step is to investigate the problem and identify patterns and commonalities that can be used to advance the project and gain buy-in from all stakeholders. Two approaches are available: user research (both internal and external) and content analysis.
+
+### User Research
+
+Most user research in the last decade has focused on external users of a website. Your “customers.” For a state government, these might be constituents, vendors, news media, researchers, visitors from out of state, and more.
+
+However, in an archipelago, it can be useful to apply those same tactics to your internal customers. These will be agency stakeholders and staff, including content authors and website administrators.
+
+Why user research? It helps you prioritize your target audience. Otherwise, you just try and do everything for everybody. 
+
+For external users, that can manifest as dumping every piece of information out there “just in case” with no sense of how it should be prioritized. Or worse: everyone fighting over how it should be prioritized. Users have to lean on a search function that probably doesn’t work very well. No one can find anything. No one is happy.
+
+For site editors, it can manifest as giving everyone HTML access and hoping for the best. This leads to an unmaintainable mess with zero chance of standardization or content reuse.
+
+User personas are typically used to focus on solutions for customers, but you can use them effectively for your internal user base. For example, the State of Georgia created very detailed user personas for their agency users, dividing them into the six most common personalities and laying out a variety of information that defines them. Each persona included their motivations, frustrations, common software, goals, and much more. They also defined common “verticals” for their agencies, such as Elected Officials and Law Enforcement.
+
+Just like with your customers, personas allow you to take a very broad base of people and narrow it down to the groups you need to focus on. They also allow you to spot commonalities. So, develop some personas.
+
+**Now, as you talk to users about their use cases and pain points, you can ensure that each persona is represented well. You are also more likely to include the full range of subsidiary use cases.**
+
+As you interview them, you will hear a lot of complaining and cataloging of needs. You need to dig for the “why.” What motivates their use cases? What are they actually trying to accomplish when they hit roadblocks? Often, the obvious issue isn’t the actual issue.
+
+Here is an example.
+
+On one archipelago project, everyone wanted us to address design issues. They complained about not having access to something, or they needed to move a photo here, or make it bigger there, or control the output for a call-to-action.
+
+Many of these needs contradicted one another. There was no consensus other than everyone wanting some variation of “just give me HTML access.”
+
+We asked two questions to get to the root of the problem and try to find the magical intersection.
+
+Why did they need this specific design control?
+What was the driver or business goal behind it?
+
+Internal politics or directives from those in authority might be common reasons for these requirements, but that was not the case here. As it turned out, there were no specific design goals. They also were not trying to fulfill specific requests. They didn’t actually need to place a specific photo in a specific place.
+
+The main driver: they just wanted to “break up the wall of text.” They thought their pages were “boring” and looked “dated.” The more we researched, the more this specific complaint popped up.
+
+With the problem identified, we could now design a solution and validate it with acceptance testing.
+
+When doing user research, don’t take what people say at face value. This adage is true: you need to ask why five times before getting to the heart of a problem. It’s easy to just do what you’re told, but you won’t be serving your users very well.
+
+When you understand users’ motivations, you can design for them, and if you can design for them, you have a way better chance of keeping them happy.
+
+There is no shortcut to this—just a lot of conversations.
+
+By applying the user research tactics normally used for end-users to internal users, you can get a better picture of your stakeholders at the subsidiary groups. By constantly focusing on the “why” of their needs, you can start to identify commonalities and gain real insights into problems.
+
+And if you can solve some real problems, you’ll be able to dangle a very tasty carrot in front of these users.
+
+
+### Content Analysis
+
+To do proper analysis, you need to do an inventory and audit. At the scale of archipelagos, this can be difficult. You might not even know all of the sites that exist under your domain. And once it’s all gathered, you need to be able to sift through it to find the relevant content for a particular conversation. Out of the millions of pages of content, what items are relevant to the three stakeholders I am talking to today?
+
+This is more art than science.
+
+Here is what you must do:
+
+1. Get an aggregated inventory of all content from across your sites
+2. Divide in different ways and research the outliers
+
+Use a tool like Screaming Frog to crawl your sites and generate the inventory of content. At every URL. Your initial instinct may be to limit what you crawl because there is an enormous amount of data at this scale.
+
+Kill that instinct. Crawl everything.
+
+Large data sets can be filtered, sliced, and organized, but you can’t do any of this with data that you don’t have. Every time you have to go back to the well to crawl more content causes additional delays. Do it once. Get it over with. If you have a large amount of data, don’t expect to use Google Sheets to sort through the data. Just get Excel.
+
+#### Find the extremes
+
+Armed with this large amount of data, start looking for the extremes. Extremes of what? Anything. Outliers can provide a lot of insight into the various teams within your archipelago and the content they create.
+
+Look for edges around these items:
+
+- Page size (largest and smallest)
+- Google Analytics visits (what is nobody looking at? Why?)
+- H1/Title size (can point to poor editorial practices and difficult migrations)
+- Text:HTML ratio
+- The number of embeds (images, tables, social media, etc.)
+
+But you might also come up with other custom properties to measure.
+
+Let’s look at page size as an example. Seeing what lives at both the highs and lows of this measure can be really interesting. Some of the reasons will be obvious, like huge tables. But sometimes you find something interesting.
+
+In one archipelago project, we found the largest page on the entire network of sites. Someone had base-64 encoded an image and embedded it into the HTML using the WYSIWYG. This told us a lot of things, but mainly that end-users of the CMS can be very crafty in getting around limitations. You can use this information when planning out editorial tools.
+
+Looking at the smallest page sizes can also yield insight. In one case, we unearthed some document management problems by looking at this metric. A large number of pages were nothing but an uploaded document with no context or metadata.
+
+Most of the time, you won’t find anything of note. This is good. It lets you move on to the next thing. You don’t want the extremes to be a nightmare.
+
+#### Aggregate and divide
+
+In an archipelago, some information will be important in aggregate, some will be more important based on the islands, and sometimes both will be important in different ways. You shouldn’t ignore the importance of either and always look at the data through both lenses.
+
+Here is an example. On one project, we noticed that, across all sites, there were far more PDF and DOC files on the sites than there were HTML pages.
+
+In aggregate, this told us that an enormous amount of information was locked away in these documents that might be worth getting out.
+
+However, when we zoomed in, we discovered that the highest PDF-to-HTML content ratios were limited to a smaller number of sites. Many sites did well and limited PDF abuse. And even in sites with a lot of PDFs, there were outliers.
+
+If a site has to offer many printable forms (like a Department of Revenue, for example), then having many PDFs makes sense. But some sites posted weekly meeting minutes, and those went back ten years. This highlights potential problems around governance and best practices. How long should these documents be kept? Are they really that important? Are there better ways to manage them?
+
+By examining the content being created from different viewpoints, you’ll gain insights and identify systemic issues for the organization at large and the individual islands.