Author Archives: Livia Labate

Planning is imagination and preparation

Yesterday I had a phone interview with Peter Morville who is writing a book about planning. We talked about planning, career and some of the things I’ve noticed so far living in Rwanda. The interview will be out next week.

Peter asked me what planning means to me. I love questions that require reflection like that one. I realize that over the years my thinking about planning has changed a lot. I tried to articulate some of that while we talked. The first thing is, I think of planning distinctly from goal setting.

I am certain that would be met with disagreement by most people. However, figuring out what you want to accomplish and why, and stating that clearly and unambiguously, mostly precedes the act of planning, which is what you do in order ready yourself to fulfill the goals set.

Sure, sometimes you may have a weakly defined starting point, or something like a fuzzy goal, but nonetheless, I consider planning to be what comes after you identified a problem space and decided to do something within it.

Having said that, these days I think of planning as a two part effort: imagination and preparation.

The first part is an exercise of envisioning scenarios, playing them out to understand what are the required actions and inputs, and the resulting effects and outcomes. I use the term imagining because I specifically mean playing it out in your mind. More like watching it unfold in your brain than actively playing it out yourself in the physical world. This does not mean you don’t use the physical world to figure out scenarios, I just mean the central concern of this aspect of planning is exploratory, observational and introspective (externalized if you are doing collaboratively, but still).

When considering scenarios, sometimes the constraints are self-evident from the get-go, sometimes they unfold through the process of going through scenarios themselves. Like imagining a camping trip and considering “What if it snows?”, “What if I run out of food?”, “What if a bear shows up?” The goal setting exercise that precedes this often creates a frame for the scenario landscape, sometimes with soft boundaries (i.e.: to become more emotionally aware and in touch with one’s own emotions), sometimes with hard boundaries (i.e.: to complete a sprint for a set of features in a software project).

In my view, by anticipating/considering a diversity of ways in which things can play out you can consider more or less likely scenarios and the next stage, preparation, can happen in alignment. This is where a lot of people hit a wall in a professional context: exploring how you are going to plan in this manner can clash with a presumed or pre-established work process, which has built-in assumptions about how planning takes place.

Having worked on projects with very different approaches along my career has reinforced the value of going through this exercise, even if it is to assume a pre-defined process to follow (and even if you are only doing it for half an hour to get yourself situated). At a minimum, it helps identify risks and potential obstacles, allowing you to be subsequently better prepared, and in certain situations it may give you insight into why you should reject the presumed process altogether.

A good distinction for me is that imagining, or identifying and playing through scenarios, is about effectiveness, reaching your goal. Preparation is concerned with efficiency, going through the real live situation with minimal disruption until that goal is met.

Preparation can be so many things though. Your packing list for a trip, a mise en place when you are cooking. These are the things we traditionally think about when we talk about preparing for something. However, I believe preparation also includes things like: getting into the right state of mind, setting expectations with yourself and others, minimizing likely disruptions, ensuring infrastructure is available, testing some aspect of the scenario, prototyping, and so on. My point is: what’s in scope for preparation is whatever is needed to satisfy the goal within the presumed scenario or scenarios you picked out.

You can prepare for one specific scenario, some variations on a scenario or multiple distinct scenarios, based on your judgment of the likelihood they will happen. You can emphasize your preparation for primary scenarios and have alternate plans for secondary scenarios. That’s what we mean when we say we have a plan B. And C and D and so on.

At the end, what we call a plan is a presumed set of circumstances (scenario or scenarios) and presumed artifacts, participants, flow, that were chosen to reach a particular goal.

I don’t know if this frame makes sense to anyone else, but it is currently helping me. I’m personally more attuned to the imagination stage of planning, though I usually prepare sufficiently, but know that I enjoy winging it too. Winging it is not ‘not planning’, it is not just ‘showing up and seeing what happens’. It means dealing with the scenario that plays out in reality without the proper preparation. And it’s just more fun that way sometimes. ;)

Introducing Carebot

You may have heard about Carebot in the media and you may have talked to us about the technical aspects of what it could be, so here is a quick update about what Carebot is today and where things stand.

What is Carebot for?

I started describing Carebot as “meaningful analytics for journalism” when I noticed that the conversation about success in journalism always turns to what data people are looking at and what tools they are using rather than what problem it seeks to address and why.

We are not creating Carebot because there is a shortage of analytics tools or even a shortage of interest in analytics in journalism (at this point, there is great interest and tools abound). There is, however, a misalignment between the day-to-day of newsrooms and the level of insight journalists want and need about the performance of their work once it’s out in the world.

Carebot’s objective is to better align analytics for newsrooms to the reality of the journalists working in these diverse settings. That requires building a tool to deliver information but it also requires understanding the workflow and needs of the journalist, acknowledging that there are a variety of storytelling devices that can be employed in their work, and developing metrics that best align all these characteristics.


Analytics are collections of data points; in order to be meaningful they need to be contextualized and relevant to the circumstances in which they are presented. What makes analytics particularly meaningful (as opposed to a handful of generic tracked data regurgitated from a database into a dashboard or report), is how well it drives people to act, whether to tweak a story, celebrate their success or make decisions about subsequent work.

The drive behind Carebot is a set of hypotheses. Our project is a prototype for the approach we believe can help us test and explore these hypotheses and understand how things play out in the real world of day-to-day journalism. We are exploring a few different facets:

1. New thinking around what newsroom analytics should be. This includes what we measure (what’s ‘a story’ and what it can be compared to – or not), and how we are measuring (which measures and indicators make sense for what questions, and which ones are NOT appropriate, or misleading, or deceiving).

2. The technical implementation and adoption of those analytics. This concerns how we are measuring (the technical approach to tracking, analyzing and reporting) and when and where we are helping journalists become aware of these insights (the content, framing, frequency, volume and scope of information shared).

Since Carebot is first an experiment, the way it works today may be completely different from how it will work in six months, but the premise is always of continuously exploring newsroom analytics and appropriate implementation fitting with newsroom circumstances.

How does Carebot work?

The mechanics of Carebot are extremely straightforward: Ze collects usage data on live stories and reports specific metrics as notifications to the newsroom over a finite period of time. In our current phase of experimentation, here’s how it’s done:

For every story, Carebot uses a tracking component (a little snippet of code) which captures a few different aspects of how users are accessing and interacting with a story.

example tracking of on-screen visibility for graphics

example tracking of on-screen visibility for graphics

This information is fed into Google Analytics (as events and event categories, if that lingo matters to you). Carebot is also tracking some aspects of usage for things more granular than a story, such as graphics and images (which can be interesting in an of themselves).

This is not unlike any other measuring and tracking approach on the web, with the exception that we are intentionally focusing on a very narrow and specific set of measures — measures and indicators we are developing and testing to understand their relevance and usefulness to decision-making in the newsroom (more on that in a later post).

Newsrooms are busy places, so after aggregating this data, Carebot does two things differently from other reporting tools:

a) it only surfaces metrics identified as possibly most useful in understanding story performance for a given story type and

b) it offers this information through periodic notifications over a finite period of time, following the usual traffic pattern for a story.

a notification about the graphic on-screen visibility for a story

a notification about the graphic on-screen visibility for a story

Currently the notifications are being delivered via Slack in a channel used by a specific desk (our Graphics desk) because we are prototyping Carebot in a newsroom where this particular technology is in use. Carebot is agnostic to the delivery method and the notification would work just as well as a text message, an email, a mobile app, or as a bot integration on other services like Hipchat or Twitter.

When Carebot first becomes aware of a story (the story gets published and the tracking mechanism starts gathering data from user visits), it alerts the newsroom so they know Carebot is keeping track of things and will start sending relevant notifications over the course of the next 3 days (3 days only due to the current scope of our work):

first notification carebot shares about a story

first notification carebot shares about a story

The scope of our current experiment is only stories with graphics and the metric we are testing is an indicator we call the “linger rate”, to assess how much time users are spending with the graphic, not just the time they spend with story the graphic is in.

After the first notification to indicate tracking has begun, Carebot reports that metric for the story every 4 hours for the first day, then twice daily for the second and third day. This frequency and volume are part of our experiment to find a good balance of awareness without nagging.

example of wording variation used on 2nd and 3rd notifications

example of wording variation used on 2nd and 3rd notifications

Some stories contain multiple graphics or graphics may be used across different stories. These unique scenarios are helping us explore different presentation needs and how to best answer questions raised by journalists when the right metric is available at the right time.

early example for a story with multiple graphics

early example for a story with multiple graphics

Carebot is currently a broadcasting tool more than it is a bot that responds to specific user requests, but we are beginning to add a few capabilities based on user feedback and what we are learning as they receive information from Carebot.

test query for specific graphic information

test query for specific graphic information

What’s next for Carebot?

We have been developing Carebot for just four weeks and in this short time have seen great potential from the questions designing it has raised, as well as from user feedback. We are working on 2-3 week cycles where we increase Carebot capability by growing scope of stories we analyze, scope of metrics we develop and track and report, and scope of features we develop.

Our work is currently supported by a Knight Foundation Prototype Grant through May 2016. In this time, our goal is to have a concrete set of metrics (well articulated and documented), with a functional tracking and reporting mechanism (Slack notifications for now) being used in a live newsroom setting (NPR), actively helping the work of journalists (Visuals’ desks).

This will help us demonstrate the potential of Carebot’s approach and share the lessons we learn over the course of experimenting with this notification based approach and new metrics to improve understanding and assessment of performance for journalism.

Note: The Carebot team will be at NICAR 2016, March 9-13, and more than eager to talk to anyone interested in understanding performance and analytics for journalism. Please connect with us in person (there will be a session about this very topic in the conversation track!) and online through @thecarebot. You can follow our progress on Github.

Sustainable file system hygiene

“Does anyone have good tips/tricks for file structures? I keep losing track of my projects.”

I hear this question or a variation of it frequently. Just got asked today during a skill share session I was in with the other OpenNews Fellows so I thought I’d write this up.

It is very easy to generate data (whatever form that data comes in — photos, project files, databases, notes, etc) so data accumulates rapidly. No matter how systematic you are about putting it somewhere, your context will change or the volume of data will exceed your ability to keep it under control.

It’s a challenge for everyone whatever their occupation or workflow so how do we deal with it? Here’s my solution:

  • Projects
  • References
  • Archives

Let me elaborate.

First, what problem are you solving? The central question is not “How do I keep stuff organized?” it is “How do I find this later?”, so your goal is findability above all else.

Rule #1: Everything needs a place. If you don’t have a place for things to go, they will go wherever and you won’t find it later.

Second, your data deluge problem is cross-platform and ubiquitous so you need to solve the issue for that scope, not just for one platform or device. It’s not just how you nest and name folders on your laptop but also how you organize things on Dropbox, Google Drive and so on.

Rule #2: The system is inherent to YOU, not the place where things are, it just gets mirrored there. It needs to be abstract and simple so it can be applied wherever you go and wherever your things might be. Over and over again.

Third, we are talking digital things so presume a file system will be involved and acknowledge that a file system is a constrained hierarchy which forces a certain set of decisions to be made.

(Yes, you can always search, great, but you also want to know where stuff lives so you can put more stuff like it along with it. Also don’t minimize your natural desire to want to browse because you will want to do that too.)

Rule #3: It’s a file system and hierarchy is inherently insufficient because categories evolve in meaning over time. Deal with it.

Your system is going to evolve over time so more important than what is the system, is how are you going to respond to the change over time. I have 5 active projects now but what will happen when two of the projects end? What and when do I back things up? And so on. Also:

Rule #4: Hygiene is about maintaining a healthy state. Only you can tell if the state of things is not healthy or going downhill. It’s also up to you to put the time to get things back to shape before it falls into a complete state of disarray.

Ok, back to the solution:

  • Projects
  • References
  • Archives

This is no surprise to anyone who has practiced Getting Things Done, but even if you haven’t, this is a sufficiently good place to start. Why does this work?

  1. Too much nesting is bad (for your own recall and because some backup reasons – some systems really choke with 8+ levels)
  2. Too much scanning is bad (for your own speed/efficiency, long list of projects you are not really working on won’t help you find things quickly)
  3. Trash/distractions are bad (also for your own speed/efficiency), but random stuff will accumulate. You don’t necessarily get to put things where they belong as you are working with them, but you have to at some point.


Whatever you are actively working on. Be descriptive. One folder per project. Anything that involves more than a step that has a supporting set of data/files needs to live in there.

“But I have 100 projects!” That’s not an organization problem, that’s a lack of priority problem. “But I don’t like mixing personal and professional!” ok, create those two folders and then put your projects in them – but remember, the more nesting/complexity, less likely to stay functioning and healthy.

Usage frequency: You will use what’s in this daily or every few days until you are done with the project.


This is a library; things you need to consult on a regular basis or review periodically. They don’t need to be cluttering your projects but need to be accessible and readily available. I have a copy of all my important IDs and docs in folder here. Also all my purchased fonts live here.

For example, when I finish a professional project, I move it to a folder in references called /Portfolio. I know that when it comes time to update my resume, LinkedIn profile or website, I can review this folder for the history of what I’ve worked on since the last update.

Usage frequency: Occasional or on recurring basis in service of active projects.


I put all my backups on the archive folder of my home computer. I back up my various devices to that location as well. Periodically I check my computer’s download folder and move any software to a /software downloads folder in there should I ever need a previous version of an app. I put all my photos here. I have albums I publish to places and such, but every photo taken is put away here.

Usage frequency: Rarely if ever. This only exists for an eventuality but also helps you get rid of stuff from Projects and References that is not that important to your day to day but you don’t want to get rid of.

Over time when I check that References/Portfolio/ folder I find projects that I have no interest in ever talking about again so I move them to archive. If I ever needed to read my graduation thesis ever again, this is where I can go get it (Chances: 0.000001%).

Rule #0: A sustainable file system hygiene depends as much on your workflow maintaining the system as the organization of the files themselves.

(It’s last to make a point, but really, it’s the first rule in importance and impact)

If you focus on organizing, you can go down a rabbit hole of eternal taxonomization that will not stand the test of time because when you are trying to find a thing your focus is on the thing itself.

The file system really should reflects your workflow. Your workflow needs to include a) put things in one of those places b) put the right things in the right places c) move things between those places as the context changes and they evolve/change status d) give all the orphans a home when you come across them (and if there isn’t one, the trash is where it needs to go).

If you do this across all your various systems you will find that findability improves but you also become ruthless about what’s occupying your attention and as long as you use the same pattern over and over, and periodically restore the pattern when it starts to deteriorate, you can stay on top of things.

Introducing Lunchbox

I’m happy to share the launch of Lunchbox, a suite of tools to create images for social media sharing.

The app combines a few tools created for newsrooms to share the links in social media with relevant imagery: one for pull quotes, another for list of facts (great for breaking news situations) and third for watermarking photography with attribution.

It can be deployed as a desktop app (great for those working on social media and may need be offline for periods of time) or online via AWS or your own server. Configuration takes less than an hour and post-deployment the end-users can use immediately with no training.

Tyler Fisher and I wrote about how we put Lunchbox together during an OpenNews Code Convening in Portland.