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.

Carebot

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.

Projects

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.

References

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.

Archives

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.

So you think you can dance

You made it. You are a Knight-Mozilla fellow. You are past all the self-inflicted anxiety of applying, interviewing and getting in and you are ready to start this thing. Now what?

Or you are considering and waiting until the 11th hour to put in your application. Or you are telling yourself the many reasons why this sounds like the coolest thing every but how you are not qualified.

I was you once. I did all of the above and I am here to tell you: DO IT.

What you want out of this

There are many reasons to become a fellow and one is unlike the other. To me, the fellowship was the right thing at the right time; as an experienced design manager with over 15 years of UX design practice, I had decided I wanted to have a more hands-on technical experience: programming, shipping code. Having accumulated more and more responsibility over the years, I both missed the satisfaction of shipping code myself and the depth of knowledge I like to have in order to manage developers. I was going to make this happen one way or another, and the fellowship offered the setting to do so (among many other reasons I can tell you all about if you ask).

Pick something; even if it seems only somewhat aligned to the spirit of the fellowship, apply. The OpenNews team is really excellent and will be completely honest with you about matching; don’t presume you are not a fit because you are probably wrong. They know better.

Shaping your fellowship experience

I asked several fellows about their experience and scarcely saw a pattern among them. Each fellow’s experience is distinct because it comes out of a combination of:

  • one’s goals, skills and expectations,
  • the culture, projects and work/team dynamic of the newsroom, and
  • whatever is going on with the community of nerds in journalism at the time (conferences, hot topics, talent pool, etc).

As you probably presume, the newsroom is constantly changing (breaking news! new staff! new business models!), the community if ever-evolving (new amazing things get open sourced every day! people change jobs! cross-disciplinary pollination!) and most of all, YOU change (because, humans) so picking something to start with helps keep you grounded, but not fixed in your path forward.

To me, how the fellow approaches the fellowship can be seen (and planned) from these three perspectives. (I framed these as questions to myself to make it easier to remember and answer):

  • Q1: What/how am I doing towards my main objective/reason for doing this?
  • Q2: What/how am I contributing to my newsroom/team?
  • Q3: What/how have I engaged with my peeps across the community?

You can use this to plan how you’re going to tackle these brief 10 months as well as to assess what you are trying at any given time (taking stock of what you have done and what you have planned next on a weekly basis is a good level of granularity and keeps you honest/sane).

Note: I treat this entire thing as a big experiment. That’s why I say “what you are trying at any given time”. Experiments are great; there is no pressure to get the outcome “right”, just to get to an outcome. In that sense, an experiment cannot fail. You set it up, you run it and you see what data you get at the end and hopefully you can draw conclusions and learn from it.

This helps with the anxiety that comes from starting something new, and the weirdness of doing something so unlike other things you’ve done before. It also helps make concrete what things you might try since OpenNews sets this up completely open-ended, where you can decide every single aspect of how you want to do things (more on that later).

Here’s my hyper-summarized list of answers to those questions:

  • A1: Immerse myself in all things programming; Learn how programmers approach projects and problems; explore any and all languages and approaches to building things for newsroom; contribute to projects primarily through code.
  • A2: Work on newsroom projects only (no independent projects); Bring in my UX practice development expertise to bear on projects and team process improvement opportunities; help optimize process by which apps are made by advising on workflow and governance (my strengths); finish things in a timely manner; collaborate with all involved.
  • A3: Remain constantly involved in the community; offer contrasting perspectives to UX Design on whatever I encounter new; hang out with people I don’t know, who do things I don’t know; Find out where they are and follow journalists, data scientists, developers, writers and researchers across media, government, academia and the arts; Ask why things are done the way they are in this space; Figure out what are barriers for entry to UX people and how to overcome them.

Nobody told me what the above should or should not be, which is why I am offering my example here. Knowing that the three different types of concerns should be related was not obvious to me at first, but once I saw that it became easier to reconcile them.

For example, *because* I am with the NPR Visuals team and they launch a lot of 2-3 week long projects that span graphics, tools (internal web apps) and full-on stories (external web apps), it didn’t make sense to have a separate fellowship-long independent project. It would have been distracting because of the short project timeframes AND all the traveling I have to do for the fellowship, and I didn’t have sufficient skills to really do it efficiently. Also, their variety exposes me to the breadth of approaches, languages and skills I was seeking, so better to focus on that then create something else I would not get support, pairing power or advice on unless I sought it out specifically.

Also, one item influences the other. I call out collaborate with all involved specifically because I knew the NPR Visuals team is an incredible group of highly capable people and I wanted to make sure I got to work with all of them in their various areas of expertise. Where some other fellows may not have such explicit goals around becoming a competent developer because they already are, that is pretty central for me, that’s why it’s so front and center. Consequently, when I participate in the broader community, my interest in/concern for helping the new learner is pretty obvious and I am constantly raising that angle when discussing things, whatever the topic.

I am very interested in how teams and organizations frame their objectives and how they ultimately assess what they do, which is why all this stuff above emerged naturally without me thinking about whether or not I needed to do it.

What the day-to-day is like

  • I work 9-5, Monday-Friday. And so should you. I’ve found the broader community of journalists, specially the coding kind, is really bad with their personal time management. Barring breaking-news that you have committed to working on (if that’s the kind of thing you’re focused on doing), do your work and GTFO.
  • I travel at least once a month. That’s a lot of travel, specially if you have people in your life you like to be with, like friends, a spouse, or children. There are events happening constantly (seems like every other day), so you end up speaking, presenting, facilitating and/or attending at least one in any given month.
  • Consequently, I spend a lot of time dealing with logistics. In my case it’s mostly due to having a 2-year-old I need to tend to and a spouse who does shift-work so schedule planning is very time consuming (as is booking flights, hotels, researching transit options, timing of things, etc). Making the time for this as work as well as filling out expense reports and such should not be downplayed.
  • I talk to people about what I am doing practically every hour I am awake. Twitter is very convenient for this and I am already comfortable there so it was an easy decision to use that primarily. It’s also a good match as 100% of the journalism nerds community is present on Twitter (Disagree? Fight me). This includes meeting new people, having lengthy debates and letting serendipity drive discussions that lead to projects, collaborations and more.
  • I write code most days. This is relevant because it’s my explicit goal for the fellowship. I know exactly how hokey it is to do this, but: Github contributions
    (I was working on an audience research project in May)

What you do, specifically

The NPR Visuals team works on many things, including daily graphics, storytelling web apps, tools and photo editorial for all of NPR. I work on whatever project the team is working on that week.

The capacity in which I work varies, but mostly it’s been playing a supporting developer role, pairing with the ever-patient Tyler Fisher and David Eads.

As a new developer, I have a lot of basic concepts I need to grasp, so I am not learning any one thing at a time; it’s more opportunistic: I need to do X, X requires Y so learn Y and keep trying to make X happen. Oh now it needs W, go learn W and come back. Oh now…

I spend a lot of time asking questions of my peeps and Googling how things work. I’ve learned that programming is many parts trying things out that sound sensible and then reading how to actually make it work on Stack Exchange (I’m only sort of joking).

I also have just enormous amounts of fun being silly with the process of learning. This is where being in an environment that’s welcoming to it (and therefore allows me to pursue my primary goal) as well as having ubiquitous access to the community of people doing similar work (via Twitter), creates a really rich and self-reinforcing cycle of learning, sharing and getting the positive feedback (building confidence) one really needs to keep going.

What’s really important is at the end of the day I’m contributing to work that a) actually gets shipped and b) is open-sourced. I know I lucked out with the NPR Visuals team because open-source and working in public is in their DNA, so that was a smooth transition.

But I was also unprepared for the neck-breaking speed they publish things, so getting in that mode has also been great. This is a list of things I’ve worked on in my 5 months of fellowship so far so you can get a sense of the kinds of projects I touch and what I actually do on them:

  • Look At This/Photo I Love: A Brother and Sister In Love
    Web app showcasing the story of John Fugelsang’s parents as narrated by the comedian, in the Photo I Love series for the NPR Visuals Look At This blog.
    My role: Paired with Tyler to build story using the NPR app template, implemented first multivariate testing for NPR Visuals. I touched CSS, HTML, app template, Google Analytics events.
  • Multivariate Testing
    Live experiments using a research method that allows users to interact with slightly different versions of the same page and assess which version people respond to more positively.
    My role: Paired with Tyler to plan and evaluate outcomes of multivariate testing across three projects. Created reports for test variables in Carebot and co-wrote lessons learned in comprehensive blog post. I touched CSS, HTML, app template, Google Analytics, data analysis.
  • California Civic Data Coalition Campaign Browser
    A Django app to refine, review and investigate campaign finance data drawn from the California Secretary of State’s CAL-ACCESS database.
    My role: I closed small issues during Fellowship orientation and at NICAR. It’s the first project that gave me exposure to the workflow and opportunities in open source projects for journalism, as well as meeting some of the smartest and funniest people in that space. Covered: Django, HTML, CSS.
  • Can’t Go Home
    Story about four Syrian families struggling to stay together during wartime.
    My role: Paired with Tyler/Aly to build story; Touched CSS, HTML, Bootstrap, navigation design, NPR app template.
  • Look At This/Photo I Love: Space Pix
    Web app showcasing a favorite photo of astronaut Reid Wiseman in the Photo I Love series for the NPR Visuals Look At This blog.
    My role: Paired with Tyler to build story. Touched CSS, HTML; NPR app template, Google Analytics events.
  • IA Summit Bingo (I was presenting at the IA Summit so decided to do this as a side project to learn how to work with Twitter bots and deploying a game)
    A bingo game played via Twitter using photos and hashtags. It generates a card from a spreadsheet of terms (hashtags and descriptions). Users interact with a twitter bot to request a card and submit their filled boxes by tweeting photos with the relevant hashtag
    My role: UI design and development, deployment, promotion at IAS. Touched Python, SQL, HTML, CSS, Twitter API, Twitter bots, AWS deployment.

  • Audience Research (not public)
    Assessment of performance of 6-months worth of NPR Goats & Soda stories for a specific target audience. Found correlation between type of photography and story subject among other interesting patterns that became guidelines for stories in an upcoming series the Science Desk is developing.
    My role: Google Analytics, data gathering, analysis, reporting and presenting.
  • Reverse2nsScreen
    Reverse Second Screen helps set the mood and context of a story through ambient sound and images presented on a secondary screen, while the user is going through the core story content on their mobile phone. Better suited for longer form features as it helps to set an enduring mood by creating a sensory experience that stays with the user throughout. Project done during SNDMakes.
    My role: UX design, documentation, presented the final concept at SNDMakes. Covered: HTML, CSS, JavaScript, JSON; video editing, device management/broadcasting.
  • NPR Concept Modeling
    Concept model to illustrate how NPR works done as part of NPR Serendipity Days (2-days of open time to hack at things). We accomplished a lot in the short time but the value of completing a complex model like this is dubious. The blog post expands on lessons learned and the whole process.
    My role: Ran the 2-day project, facilitating concept modeling exercise with two others. Covered: Concept modeling, content modeling, facilitation. Fun fact: all the whiteboarding for this became background for the NPR One ad (0:26)
  • Graeae
    Graeae is a tool to aggregate data about published web content. It includes a growing set of scrapers to collect data from Facebook, Google Analytics, and others, store, analyze and report on usage and performance across several criteria. Includes a UI for photo editors to evaluate quality of images used across stories so we can correlate photo quality and story performance.
    My role: Paired with David to build scrapers, perform data analysis, create reporting UI. Covered Python, SQL, CSS, HTML, JavaScript; data analysis, DB modeling, scrapping, RWD.
  • Lunchbox
    Lunchbox is a desktop-based suite of tools for newsrooms to create images intended for social media sharing. It collects 3 tools that provide photography watermarking with attribution, conversion of textual quotes into images and bulleted list of facts into images.
    My role: Paired with Tyler to combine three previously existing tools and wrote documentation to open-source the project during a 2-day code convening put together by OpenNews.

Other things I’ve done:

Why did I list ALL this stuff? Because my fellowship is not about a really big project, but a lot of small and medium sized contributions with different emphasis and I wanted you to see what they are like. Also because the things I work on vary in how they leverage all the expertise I bring in versus all the enthusiastic ignorance with which I tackle things (and how I learn from those experiences).

Your fellowship experience I am sure will be completely different!

I hope this is relevant to anyone, but I specially hope that user experience designers of all stripes—those with content strategy inclinations, UI design proclivities, service design aficionados, consider taking on this opportunity. (I did not come in to it with a programming background, just an explicit commitment to get into it. And look how far I’ve come in 5 months. You can too.)

The newsroom is a fantastic place to be (and I spend very little time talking about that in this post) and journalism is a domain that’s transforming rapidly, influenced by cultural and technological shifts. It’s a particularly great industry that’s ripe for design practice to make a contribution. It’s up to you now.