Tag: information architecture

Consolidated or Distributed Site Structure?

One conceptual conversation Simon and I had recently was about how far to go in trying to consolidate the “news harvest” workflows and tools with the publishing and distribution workflows and tools.

At present, the workflow is distributed across many different tools and services. (A single news item that ends up in the Daily Bulletin publication might touch or be viewed in a web browser, a Zapier zap, a Slack channel, a Google Sheet, a WordPress publishing UI, a MailChimp publishing UI, a social media account and more.) While this allows for a lot of flexibility, it also creates a lot of places where the team has to think about how an item will appear, and how all of those services will connect with each other to make sure it does appear.

Building something new presents an opportunity to consolidate significantly, but we don’t want to go so far towards “one tool to rule them all” that the project can’t easily evolve or adapt to future needs. Clearly part of the project’s success has been how agile the team is and how quickly they can spin up a new tool or service to add value to what they’re doing. I imagine that this tradeoff is something newsrooms around the world have to consider on a regular basis.

To help with the conversation, I tried to visualize two main scenarios I thought we were considering and put together some diagrams.

Scenario A is a centralized administrative tool, but still with separated out publishing channels:

The news harvest functionality on the far left all feeds into a central admin tool, which in turn publishes the curated and updated information to other tools hosted and managed elsewhere, which are in turn the public-facing experience that community members will interact with.

A key benefit of this approach are that we don’t have to reinvent some key functionality: WordPress already has content management system functionality covered, MailChimp already has mailing list functionality covered, and so on. By abstracting the information management workflows from publication and viewing, we keep our new tool focused and lightweight, making it easy to add new features to that part of the workflow.

Continue reading Consolidated or Distributed Site Structure?

Data Model

Based on our planning work and stakeholder conversations so far, I’ve been working with Simon to develop a data model for the new tool that will serve as the central dashboard for the news harvest workflow.

Here’s the Google Sheet and a few screenshots are included below:

A data model is a way of showing how all of the different data elements in the system will be organized, and how they will relate to each other. It’s a fun document to work on because you can focus on (and completely rearrange/rework) the core information that the system will manage without yet worrying about things like user interface, performance, features or other implementation details. Getting the data model “right” helps ensure that as the software is built, we’re clear on the core concepts of what goes where.

This document doesn’t capture every last detail and is likely to change, but it provides enough depth to allow us to begin mocking up the user interface and representing these concepts in a more concrete way. Those things will in turn be useful in further planning and stakeholder conversations.