A Design and Development Process for Visual, Arts-Centred Web Applications
Unlike a traditional introduction to web design and development, this document follows a narrative format that aims to get technical definitions out of the way in order to focus on the small picture (requisite specifications) and the big picture (how a web application can be a tool, advocate, springboard, playground, didactic device, marketing engine, etc… for an institution’s strategic direction). Because, in my other life, I do significant reading in the genre of science, technology, and society studies (STS), I have borrowed the technique of highlighting key terms and concepts (in italics) which have something to do with process and practices so that the reader might begin to get a feeling for the particularities and language of web design. What follows is not meant to be comprehensive but rather to provoke possibilities for integration (how do business process, marketing, fundraising, community engagement, program details, initiatives, funding opportunities, staff, students, and other humans intersect with a web application?) and innovation (how can an interface or experience surprise, captivate, animate an audience?). It is, I suppose, a bit of a method manifesto—but I want to help clients ask the right questions.
I will focus less on the structure and layout of a typical website and more on generative suggestions as to how content (text, images, audio, video, files) can be expressed as story in the context of available web technology. I will also focus on method and practices in order to give a general impression of the “how” of web development given the state of the art. Many of my larger-scale institutional clients, having worked with larger-scale agencies, have expressed the sentiment that working with tech consultants has been a constant exercise in dealing with “no!”—whereby technical jargon, software and code constraints, and project timelines are used in a kind of sleight of hand to restrict possibility and creativity; I want to give the general impression that—with the right designer/developer—anything is possible.
In a traditional digital agency context, tasks are spread out to specialized cohorts (administration, project management, content development, UI design, UX design, coding, testing, so on)—much like the disciplinary context of the academy. I want to stress throughout, however, that (like the academy) an interdisciplinary approach holds great value; in practice, this means choosing a designer/developer who can see beyond departments and roles such that all details (visual, programmatic, meetings, needs, possibilities, forms, data, devices, available resources, the built space of the business/organization, the strengths and shortcomings of staff) are considered as part of the website. This requires a great skill for translation work and the ability to make technical details comprehensible to each and every stakeholder. Having a strong and vibrant concept at the outset in terms of marketing, presentation, functionality, interactivity, etc… can help mitigate this process. This document and the series of recommendations that emerge from a critical appraisal of current technical standards and user interface (UI)/user experience (UX) best practices serves a twofold purpose:
1) To educate and empower colleagues and clients such that institutional needs and possibilities can be expressed in a language amenable to what is currently possible in terms of data/content management and web design
2) To outline a method capable of taking inventory of a client’s existing assets through the lens of what is possible in order to articulate visual, functional, technical, accessibility, and budgetary requirements
2.0 Content Management and Technical Requirements
Of the many popular open source content management systems (CMS) available, WordPress (https://wordpress.org) is by far the most robust and well-documented (with both the WordPress Codex, a living repository for WordPress information and documentation, and myriad forums and online tutorials). The WordPress community makes available a large number of plugins (packaged code meant to extend the core functionality); the front-end (what users see) and back-end (what site admins see) are meaningfully customizable; the administration interface (dashboard) is easy to learn and use; and WordPress is primed for search engine optimization (SEO). A successful WordPress deployment will rely on a designer/developer with advanced knowledge of:
HTML 5 the basic language of web design that allows text, images, and video to be rendered on a page
PHP 5 the language that WordPress is built on that is able to generate HTML from content stored in an online database
MySQL the language used to create, access, and edit online databases; a developer will typically use a graphical user interface (GUI) like phpMyAdmin to edit, repair, or backup the WordPress database
CSS 3 the language used to visually style and animate HTML elements (text, links, paragraphs, containers, lists, tables, images, videos, etc…); a good designer will also include a print design-inspired print stylesheet so that users can print clean, readable output (only the content area of a page, no navigational elements)
Front-end frameworks such as Material Design Lite (http://getmdl.io); a collection of pre-coded interface elements (text, buttons, form fields, etc…) that may be used as a foundation from which to style HTML elements rendered on a page; a good developer is able to leverage front-end frameworks to speed up development without visuals looking cookie-cutter or out-of-the-box
SASS (Syntactically Awesome Stylesheets) a language that generates CSS and can be used to set global variables for fonts, colour, dimension, position, etc… such that iterating through different design options does not require rewriting many lines of CSS code; a good developer will use SCSS in a predictive manner to allow for the rapid prototyping of a new colour, font, or idea
WordPress knowledge of WordPress theme development, custom fields and post types, meta box manipulation, shortcode creation, plugin best practices, plugin development, user role management; a good developer will be able to un-WordPress the standard WordPress installation—this means being able to write functions, plugins, and template parts that go well beyond WordPress’ standard use as a blogging platform
Compatibility standards set of practices to ensure the site displays and functions consistently across all browsers; a good developer will code in such a way to support modern browsers (the most up-to-date versions of popular browsers) and redirect older, non-modern browsers to a page prompting users to upgrade
Responsive design (RWD) standards a method of using CSS to define breakpoints for variously-sized screens (desktop, laptop, netbook, tablet, mobile) such that a single site can be presented with styles that change or adapt as the window is resized larger or smaller; a grid of thumbnails, for example, might appear 3 across on desktop, 2 across on tablet, and 1 across on a smartphone—this is achieved without designing multiple versions of a site for multiple devices but, rather, a singular site with multiple styles; a good developer will leverage media queries (the code that allows different styles at different screen widths) to conjure up an experience unique to each screen size (for example the same navigation bar might be styled as a series of large typographic links on a desktop screen but as an app-style menu bar on mobile-sized screens)
Web accessibility and SEO standards these standards (including the way HTML elements are named, how pages are structured, how images are tagged, how and where text appears on a page, etc…) ensure that search engines can crawl the site and return meaningful results; they also make technology available to and usable to everyone—regardless of ability (visual, auditory, cognitive, neurological, physical), age, economic status (older hardware, slower connection speeds, use of public terminals), education and technical proficiency, and geographic location.
3.0 Development Method
Planning, design/layout, and development (coding) should be iterative, experimental, open to change, and able to respond to institutional requirements that arise/surprise mid-process. The “final” site that is delivered should be capable (programmatically and in terms of layout and functionality) of continuous improvement (Kaizen [改善] method, for example, which proposes to start from “thinking small” in order to build towards the “big picture” via continuous improvements). This means that the design and programming of the new site both prior to and post-launch will allow for iterative changes that circumvent the need for significant overhaul; will allow for functionality to be changed, improved, or removed; will allow for tracking and analysis (typically Google Analytics); will allow for design/layout tweaks (made internally and not paid for by the hour) like re-prioritizing items in a menu, changing the order of pages, adjusting a font size, so on. It is possible to create custom settings panels in WordPress, and a good developer will design some degree of customizability into the site’s structure (custom post types, custom fields, menus, widgets, categories, tags, drag and drop post order) and template (CSS [language that styles a page] controlled by PHP variables [language that pulls and renders database content] set by fields or dropdowns in a custom settings panel in the WordPress dashboard) such that structural and visual changes (within reason) can be made internally.
In keeping with this sensibility, training for staff or interns/volunteers by the designer/developer should begin during the development process and not simply once the site is “done” (while some staff may be familiar with WordPress, this doesn’t account for significant changes and customizations made by the developer). The entire point of using WordPress is to empower as many marketing/curatorial staff, volunteers, interns, or artists as possible to be confident content-creators and publishers without risk to the overall functionality and design of the site. Likewise, documentation (pdf user manual, internal wiki, screencasts, Evernote, a Google Doc) should begin at project start and allow all stakeholders to contribute to a living record that captures role-specific knowledge such that when a role goes away (maternity, new hire, so on) the institutional memory does not. A website for a mid-sized institution can be quite complex, and it is important that anyone who “touches” the site does so feeling confident and having already been educated.
4.0 Development Process
“Design could be thought of as embedding of intention . . . It includes the designing of design processes” 
— Anne-Marie Willis
In what follows, I will try to give a general impression of some of the details and possibilities that will be “good to think” at each “stage” of development. While development should not be thought of as a linear process, some details are contingent to or prefigure others. What I am trying to elicit, overall, is an ongoing answer to the question “what is the intention?” And, I want to ask this question with a number of inflections (marketing, aesthetics, fundraising/advancement, values, ethos, brand, the future) to a number of people (marketing staff, administrators, volunteers, patrons, clients, board members).
Gather Before beginning the development process, it is crucial to have at least a sketch of institutional needs (strategic direction, objectives/drivers, staff availability, marketing strategy), a loose design direction (brand guidelines, precedents and favourites, a wishlist), and an overall content strategy in place (what new copy needs to be written/old copy edited, what is out-of-date?, are raw image, audio, and video files available on an external hard drive ready to be used as placeholder as the design develops?). Rather than relying on the existing sitemap and sections to determine what “types” of pages or sections are required (exhibition pages, events section, etc…), one might begin to think of what “types of things” go on a page (headings, blocks of copy, slideshows or image galleries, forms, an ISBN for a publication). This represents a shift from thinking in terms of static pages towards a more dynamic content-driven approach and towards data. An inventory of content types, functionalities, attributes (e.g., a publication should have an ISBN and a cover image), and use-cases (e.g., a user will need to register for an event) will be much more useful to a designer than a list of types of pages—several types of pages, for example, might share a type of content and this can be created globally. This means thinking in terms of blocks of functionality (a “hero” or large slideshow that is swipeable on an iPhone; a list of exhibitions that is sortable; a search result item with a title, date, and thumbnail image; a mailing list subscription box). Are there special use-cases that will be useful internally? Should a page for a publication also include a Chicago-style citation at the bottom of the page so that curators can simply copy and paste this text when writing a grant proposal? Are the hours of operation locatable by staff or volunteers willing to self-educate? The nature of WordPress is such that anything stored in the database can be pulled out and manipulated in a number of ways—for example the main content of an exhibition page might appear on the “single” page for that exhibition as a full block of text and a large image, whereas in the sidebar of an event associated with the exhibition, the same data might be pulled but styled as a thumbnail and a short text excerpt with a link. What should a full text content block “do” and look like? What should a sidebar “pod” or “panel” linking through to that full page “do” and look like? The usability and marketing trifecta, here, is: content, function, language. What is the institutional story/flavour? What guiding principles will shape the language used in navigation (should a button say “for further information please contact” or “get in touch”?). Who is a type of content, a type of use for? Gathering material and existing resources also means gathering human resources; how can the site also serve internal functions, streamline a process for staff?
Anticipate It’s easy to get caught up in the language of project management; instead, one might communicate timing in terms of concrete deliverables (a proposal, mock-ups/wireframes, a live development site, a checklist of testing considerations) rather than abstract conceptual “phases.” Determine in advance what you do need to see and what you do not. Where it comes to oversight and project management, what is the intention? This is often a question of institutional values (what is more important, timing or getting it right?).
Design Ask for sketches, snippets, wireframes (mock-ups), and live examples before, during, and throughout the process. The designer should use real, existing content in the layout so that stakeholders can ensure affinity between the design and the varied content—implicit in this process will be questions like “how do we handle portrait vs. landscape images?” (http://moca.org does a good job of this) and “what happens if a title is too long?” With arts-related content this is especially important: should an image ever be cropped?, how and where should captions/attributions appear? The process of seeing “real” content in mock-ups should start early on so that the institution can anticipate if bulk edits to images, file conversions, and so on will be required; determine, in advance, who is responsible, the developer or in-house staff. Generally, developers will farm this kind of work out to interns or administrative staff which is a risk when working with artists’ images. Ask pointed questions about the small details (have you included a favicon—the little icon that appears on a browser tab?; does each page have Open Graph metadata so that when a URL is shared on Facebook, the title and image for that page are automatically pulled?; did you include touchicons for retina and non-retina devices so that when a user adds a link to the site on their iPad home screen, a custom icon appears?).
Test Testing and quality assurance (QA) are vital; test at the beginning, during, after. This should include functional, performance, cross-browser and cross-device testing. Every staff member should test on as many operating systems, browsers, and devices as possible. This doesn’t have to be laborious, it’s as simple as setting up a shared Google Doc or a dedicated email address (testing@) in which or to which a running list of changes, bugs, ideas can be collected. Ask the developer to complete peer testing (have colleagues and select industry contacts test). My testing barometer is my mother—if she can’t use the site… Ask the developer for a launch checklist: when, who, will our email be down, is there a temporary maintenance page in place, who is the emergency contact, what are the risks?
Evolve The site is never “done.” Even at the onset of the development process, training should be in motion. Have a spreadsheet of content ideas, a content schedule. A freshly-launched site should feel alive, dynamic; anything less than this is a missed opportunity. Plan to post to the news, events, or blog twice weekly; make sure to share these posts on Facebook, Twitter, and Instagram. Site launch is a good time to bring the cover/background images and overall theme and style of your social assets (Facebook, Twitter, YouTube, etc…) into consistency. Have a plan to surface archival content (e.g., a weekly blog post where an emerging artist talks about a long-past exhibition which links to the page for that exhibition). Plan to do a regular site-wide assessment (every 4 months?) in which to check for broken links and images, to check for style inconsistencies, so on.
In theory, it is possible to migrate database content from another CMS to WordPress. I have, however, rarely seen a successful data migration. The danger, here, is that bulk conversions are never “clean” and the specificities of one platform relate little to that of another. It’s like trying to fit a square peg into a cylindrical slot. Blind data migration of this kind flies in the face of every mindful content-first development strategy; in almost every case, I have recommended that my clients manually re-populate all content. Often it is the case that content will have to be adapted, edited, merged, reduced to mirror the design intent, content/brand strategy, and architecture of the new site. I view this process of manual entry as a powerful opportunity to have fresh eyes go over archival content. This is also a meaningful means to have volunteers or interns learn about the history and culture of an institution.
6.0 Guiding Design Principles
Given the current state of the art in web design and development, I would like to propose a series of guiding principles to shape the conversation to follow. A user-centred, design-driven website will be:
Visual The visual treatment should draw on “the foundational elements of print-based design—typography, grids, space, scale, color, and use of imagery.” Colour is experienced affectively and cognitively; use colour to elicit a feeling—and as a wayfinding resource, a visual cue to convey organization or function. Employ white space; the balance of positive and negative space is critical in an information-heavy medium which can often feel overcrowded and overwhelming. Use large-scale typographic elements; many commercial type foundries offer web font versions and any TTF or OTF font (the font format you will encounter if you riffle through your system fonts folder) can be converted to WOFF, EOT, and SVG (web font formats) for use across all browsers—provided you have acquired appropriate licensing. Display images and video edge-to-edge. In fact, the entire visual treatment should be conceived of as filling the entire window area on all screen sizes; the days of the centred content column are over. These print-derived techniques, when properly translated into online format, “create hierarchy, meaning, and focus.” Visual treatment should leverage the principles of responsive design (see 2.0 Technical Requirements, “Responsive Design (RWD) Standards”); while there is only one site structurally and in terms of actual pages, the styling should create a sense of unique experience at each breakpoint (desktop, laptop, netbook, tablet, smartphone). A good developer will capitalize on the visual lexicon of iOS and Android applications and mimic this app-like feeling for smaller screens.
Accessible The site should be highly navigable. This means having persistent navigational elements (like a menu bar which stays at the top of the screen as a user scrolls) and leveraging interface feedback (animations, fades, sliding elements, colour changes). Navigational elements can appear compact then change on hover; for example, a slim menu bar can animate out to display sections and links. Content areas which may have formerly been expressed as multiple pages can make use of accordions or collapsible areas; for example, a user might click on a large title and, instead of navigating to yet another page, a new panel of information slides down on the same page (see http://materializecss.com/collapsible.html). For more utilitarian functions like confirmation messages (“you have been added to our mailing list”) or form validations (“you forgot to enter your email address”), the interface can make use of modals (a temporary panel that overlays the current content, see http://materializecss.com/modals.html [teal buttons at top of page]), dialogues, or toasts (an unobtrusive pop-up notification, see http://materializecss.com/dialogs.html [teal button at top of page]). Fonts should be antialiased (smoothed) using CSS3 specifications and font sizes should be large, legible, and consistent. All elements on a page should be properly coded such that a screen reader (used by the visually impaired) can be used.
Flexible Designed components (content blocks with title and thumbnail, styled titles, page content areas, image galleries, buttons, form elements, etc…) and behaviours (animations, fades, dialogues, notifications) should be reusable across the site. All content stored in the database should be able to be pulled and used anywhere on the site. “Page” is an outmoded metaphor, instead the presentation should be dynamic and blocks of content pulled from the database should be accessible to any page; for example, on Tuesday you might want to feature a past exhibition in a “pod” (a visual block with a thumbnail, title, and link to the exhibition’s page) on the front page and Friday you might want to have a visual link to both a publication and an event (again an image thumbnail, title, text excerpt, and call to action to view the event details) appear on the page for an exhibition. From a data management perspective, content should never be duplicated; there should be only one point of entry. This means that an exhibition should be entered, data-wise, into an “exhibitions” entity in the database (in WordPress this entity is called a “custom post type”), a publication should be entered into a “publications” entity, and so on. At no point should the image, title, and text for a publication be copied and pasted into the content for an exhibition; rather, the user should be able to insert blocks of related content (a visual link to a publication) into the layout of an exhibition page as a “reference” that pulls the actual data from the publication’s own database entry. The concept of modular content is relatively foreign to most WordPress and other CMS developers. I have developed a WordPress plugin that accomplishes this kind of flexible content system and I’m happy to share more detailed information about it should you be interested. The idea, overall, is that you should be able to surface any content, anywhere, at any time without having to pay a developer and without having to manage duplicate content streams.
Integrated Your site should be completely centralized and make use of only one platform. This means that forms, events management, user records management, files and other digital assets, mailing list management, and so on should be fully integrated into WordPress. Fortunately, the WordPress community offers many free and open source plugins to accomplish such integrations. While a site is never “done,” it does represent a “finished product”; the site can be used as a central repository for boilerplate images and text. Instead of maintaining a number of files and folders on a shared server and on individual machines, the website should be the go-to resource for staff requiring text and visual resources for grant applications or marketing materials. It is possible, for example, to have a high-resolution image download link on the front-end of the site on each exhibition page that is visible only to logged-in admin users. WordPress can be your digital asset management (DAM) system. Think of it this way: the website is the final home for perfected copy, information, and image selections and instead of managing this data in multiple places (Word documents, spreadsheets, printed materials), a user can count on the website the be the most up-to-date place from which to clip materials. Thinking this way precludes issues of duplication, multiple update cycles, out-of-date files. A website is as much a business application as it is a presentation.
Social The site should be social. This means having clean, well-designed sharing functions on every page. A good developer will use Open Graph protocol to tell platforms like Facebook which images, titles, and descriptions to pull when a page is being shared. Sharing is also a point of integration for internal marketing functions; a content generation cycle should go like this: content is developed and posted to the site (an exhibition page, for example), the admin navigates to the newly created content and clicks the same sharing buttons accessible to any user, the content is shared to Facebook, Twitter, etc…, and Open Graph protocol ensures that the Facebook post or tweet automatically pulls in the exhibition’s featured image, title, and description. It is even possible to generate hashtags on the fly so that, with only one click, an admin has published a tweet with a title, a URL leading back to the site content, and a hashtag.
7.0 Existing Content
The scope, scale, and structure of existing content can help to show which content is important. In other words, thinking in terms of content does not render architecture (sections, pages, types, categories, organization) insignificant but allows structure to emerge as a logical consequence of content. From an existing sitemap, we can reverse engineer some priorities (namely, which “sections” hold which “content” and how far is that content from the front page) that help to gauge the amount of work it will take to plan, organize, design, populate, copy edit, edit images, etc… This will aid in assigning tasks internally and cue which sections to pay attention to.
8.0 Surface and Depth
Depth is an important metaphor for understanding the relationship between site architecture and content. Depth is not so much about distance as it is about duration: the amount of time “in” or “down” we are able to hold a user’s attention. How many clicks in is a block of content? How far “down” below the page fold (the bottom of the browser window) is a block of content? How long does it take to get to what I want? It is not so much about “where” a user encounters content, but “when” and “how.” Some strategies for “surfacing” content (bringing 3rd level pages closer to the front page, for example) might include a featured exhibition on the front page, a rotating weekly feature “from the archives” on the front page, so on. In addition, many 4th and 5th level pages and assets (links to pdfs, video files, etc…) can be eliminated with the creative use of screen real-estate: collapsible areas, overlays on the same page that pop-up and can be closed, interactive components on a page that allow a user to sort or filter exhibitions, events, or publications. The goal is to move away from a static conception of pages towards a more app-like user experience. Apps “happen” in one window; panels, dialogues, and overlays might slide in and out, but it is rare that a user would have to follow a trail of links down, down, down, or up, up, up to get to what they want. Effectively surfacing content means having prominent searching and filtering capabilities.
Instead of forcing a user to spend time looking for directions and contact information, the front page could have this content featured prominently (see http://bmoca.org, for example). In addition, a staff directory might be linked to directly from this “contact” block. This eliminates 3 levels of navigation. If a more detailed contact page is required, no problem—but it is the data from this page that should be pulled dynamically into the contact block on the front page; no two pieces of identical content should “live” in a different place in the database: one point of entry, multiple displays. An exhibition “listing” page, for example, could have all exhibitions in a list that can be live-filtered (like an app) along certain dimensions or attributes (online, current, future, past, satellite, outdoor); as the user makes a selection, the visual grid of exhibitions adapts, relevant results fade in, the rest fade out. Here, we have allowed the user to find what they want without having to navigate to a separate search page or to discrete sections (current, future, or past exhibitions); they are already “in” exhibitions, they know what to expect. This eliminates 2 top-level navigation items, allowing for the primary site navigation to be clean, minimal, meaningful. When a user is looking for something to “go see,” shouldn’t they also be able to encounter exhibitions-related events in the same listing? Here, the idea of flexible content (see 6.0 Guiding Design Principles, “iii. Flexible”) comes fully into play: while, in the database, events content may “live” in the “events” entity, it should be able to be pulled into the app-like experience of filtering/sorting through all exhibitions without the content itself ever having to be duplicated in more than one “place.”
As evidenced by the previous examples, a well-organized, semantic (the structure tells us something about what to expect content-wise) site architecture can be used creatively and dynamically. So, while it is important to think content and function first, it is also important to have an architecture that supports content and function. When thinking of content, of intentions (brand, story, conventions, design, appeal) and functions (depth, animation, forms, navigational elements), it will become evident that similar content with similar use can be grouped together in one “entity.” In the example above, it makes good sense to have an entity (a database table or, in WordPress, a custom post type) called “exhibitions.” Because we want to introduce dynamic, asynchronous, and interactive functionality (the ability for a user to browse exhibitions in an app-like manner), we will also need another dimension to our data: attributes.
Content which “lives” in the “exhibitions” entity will also need attributes which speak to type (online exhibition, satellite exhibition, etc…) and temporality (on right now, in the future, archived). Images, videos, PDFs, and other didactic material might also accompany exhibition content, so we will need attributes for these as well. Remember, we arrived at our entities and attributes by thinking, first, of content and the user’s experience of the content. It is also important to know if an attribute is singular or plural: do we need the capability for one pdf file for each exhibition or multiple? Can an entity have multiple of the same type of attribute (for example an exhibition that is both online and satellite)? Thinking content, design, function, and architecture together will also allow the institution and the developer opportunities to identify possible design challenges (how do we deal with landscape and portrait images on a page, on multiple screen sizes?) and opportunities (we could have all outdoor holdings on an interactive, custom styled Google Map embedded at the top of the page).
A successful design and deployment will rely on the institution communicating these needs to a developer at the outset of the project. A spreadsheet, matrix, mind map, or other diagram of entities and attributes should be provided.
Content, architecture, and navigation are intimate! Having defined entities and attributes, it is now possible to talk about “pages” and how one navigates between them. Page “types” will help the designer/developer to structure the WordPress template files which theme and organize the front-end of the site. The goal is to slim down to 3 levels of depth maximum, and to pull or surface as much 2nd and 3rd level content on the front page as possible while maintaining a minimal (uncluttered) and design-driven layout. Similarly, the client might create a matrix or table of page “types” (eg. front, listing or archive, single item, form page) to aid the developer in structuring the template.
Once an inventory of content, functionality, entities, attributes, and types of pages has been made, the designer/developer will be able to provide a set of wireframes or mock-ups that visually demonstrate how design and experience might come together.
 Mark Jenkins, “How to Use Kaizen Thinking to Design Better,” Simple = Human, https://medium.com/simple-human/how-to-use-kaizen-thinking-to-design-better-7302e45aa80d?ref=webdesignernews.com#.o56zkwxb8.
 Anne-Marie Willis, “Ontological Designing: Laying the Ground,” Design Philosophy Papers: Collection Three, ed. Anne-Marie Willis, (Crows Nest, Qld.: Team D/E/S Publications, 2007), 92, 95.
 Read a brief summary of “modular content” here (https://newfangled.com/the-way-you-design-web-content-is-about-to-change).