Author Archives: Livia Labate

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.

Concept Modeling is Hard

Concept Modeling is a method used to visually express understanding. It forces the author to indicate the explicit relationships between the concepts that make up a domain. I became interested in this approach back when Bryce Glass created a very visually compelling one to explain Flickr (10 years ago!).

Flickr User Model, v0.2
Bryce Glass, 2005

I’ve talked to Bryce about how to do these things and how hard it is, and I feel like every time I try to do one I fail and abandon it before I get to a place where it can be useful for anything.

Since starting at NPR three months ago, I’ve met lots of people with very different answers to questions about how NPR works. Not conflicting, but nuanced based on their role (and using very specialized language). I thought creating a Concept Model would be a good way to capture these perspectives and hopefully generate an artifact that could help people start conversations from a common base of understanding so they could more quickly dig in deeper into whatever topic they need to address.

This past week was Serendipity Days at NPR (often called hackdays/weeks in other places) a time for people to work on things that they wouldn’t normally work on, but that are useful to the collective. So I decided to try to get others to help create a Concept Model to explain NPR and how users relate to it. Being new to the domain (NPR) makes me ill equipped to explain it, but I thought I could facilitate the process and get smarter and more qualified folks to contribute the content I lack.

We started out with a free-listing exercise generating one concept per post-it of “things that make up the NPR ecosystem”, then clustered like-items by affinity. First inspection showed that most things were quite understandable among us: the relationship between NPR and local stations, the financial model behind NPR, even how NPR plays out in social media, but the bucket of things we labeled “content” was a complete mess. There was very little clarity around what an “episode” meant in the context of radio versus podcasts, for example. So we decide to dig into this area more deeply to make that understanding more explicit.

Freelisting followed by affinity clustering

It was unavoidable: get 3 information architects in front of a whiteboard discussing definitions and you will very quickly see a taxonomy conversation shape up. As we discussed the differences in concepts and their hierarchical relationship across radio, podcasts, articles, photo essays, apps and web apps, we needed more robust language and structure that a general mapping was not offering. We were really talking about the Content Model needs of the whole organization.

The blob

So I went back to the procedural model of how you make a Concept Model and wrote down statements to define what the terms meant. This helped disambiguate situations where one term meant different concepts and single concepts that had multiple terms depending on domain.

Concept statements

Interesting to note that this did not flow well at first. My focus question was “how does NPR work?” and my statements were broad and useless. I reframed the question to “how does NPR tell stories?” and all the above came out easily: concrete and specific. A big lesson learned about Concept Modeling regarding the usefulness of the focus question. (Later iterations it became “How does NPR investigates and tells stories?”)

Once I had a good set to work with, we started visually connecting them and making the implicit relationships visible by linking the post-its on the whiteboard and using verbs to express the relationships between them.

concept model fetus

This was very revealing. We found we were missing more granularity and after flailing for a while (but asking and generating lots of new and interesting questions), we realized that we had hit a dead-end talking about this in terms of abstractions. We kept going to look at the website to see how things were actually organized, or looking up glossaries people had made internally.

Veronica suggested we map out specific examples so we could get a really concrete sense of the relationships and then see if a pattern emerged from them so we could go back to abstractions. That was brilliant and we found new terms we had not even included like “a desk”, “a beat” or the actual people that make the content. This is relevant because we observed that most of the work is organized around people, so that had to be a central construct in the model.

example relationships Screenshot 2015-05-15 15.30.14 Screenshot 2015-05-15 15.30.43

By this point we had identified something more concrete to model, but also gathered a lot of new questions we could not quite answer. For example, if a “desk” is a group of journalists that pursue a specific beat (topic area), are all groups of journalists with a topical interest a desk? It turns out the answer is no, but what are they then? The thing about Concept Models is that you need to be precise, so you have to come up with an answer in order to include a concept like this. Presumption without definition does not play well, because after all, this is about expressing understanding and vagueness is NOT understanding.

We almost got off track with the Concept Model because we needed to understand the Content Model of all of NPR for this part, but it raised the issue of how a unified Content Model would benefit the various areas that share the same concepts and relationships. This is how far we got with this exercise given how much time we had to explore, but serendipitously, I happened to tweet about what we were doing…

Paul Rissen, Data Architect from the BBC, who shares our enthusiasm for this geekery wrote back and told us that the BBC had done a lot of work in this area (Content Modeling, not Concept Modeling) and was kind enough to Skype with us for an hour and share some of the definitions, relationships and terms the BBC uses to express its content ecosystem (thanks Paul!).

This was helpful because it offered a concrete AND complete model to talk about the same things, as well as it offered different language to show us which of our terms has general application and what is just NPR lingo.

This was a few hours of work and now I’ve decided to spend more time continuing to validate the relationships with other teams and people in other roles (editors, reporters, producers, etc) to document the Concept Map as I originally intended. In addition, I drew some other conclusions from this exercise:

  • Creating a Concept Model collaboratively was WAY more productive than attempting to interview people and distill that understanding on my own, as I tried before. The process of quickly asking and answering questions together got me much further than I could have on my own.
  • I knew Concept Models were damn hard to do, but learned that the visual representation of the relationships is relatively easy in comparison to gaining agreement around the meaning of things.
  • Even though I didn’t finish the whole thing, Dan and I did a show & tell to explain how we went about it and I received a lot of positive feedback, validating that doing this and having an artifact is indeed desirable and worth pursuing (which is why I’ll continue doing it).
  • It is very easy to abandon the whole thing to avoid this complexity and attempt to write a glossary instead. Except that glossaries are definitional by nature, while Concept Models are relational. And it’s in this relationship between things that deeper meaning and understanding emerges. So, I doubt I’ll create a glossary again, unless it’s in the service of creating a Concept Model, which has already proven more useful.
  • We came to realize that the shape and emphasis of certain concepts in the diagraming was a political statement. So much so that at one point we noticed that the way we did it was a publishing-driven perspective, whereas we wanted a journalism-driven perspective. I suspect the shape/tone of the focus question is partially responsible for this. It also made me wonder if there are assumptions or principles worth stating before starting to help frame this.
  • Throughout this exercise we repeatedly asked “are we trying to illustrate what is or what should we be?”, which was revealing. The point of the Concept Model is to make the complex clear, not simpler. At the same time, the process of understanding concepts, their relationships and disambiguating things forces you to create new language and normalizing existing language, so in a sense it can express a viewpoint that some may not see as “current state”. This simply shows that there is NOT a current shared mental model of that domain.

Thank you Veronica and Dan for your patience going along with my crazy ambition to map all the things (and Kate for stopping by and answering tons of questions!). Special shout-out to Paul Rissen for being so generous with his time and expertise.

I’ll likely write another post with more details as this work progresses.

Getting Organized To Get Things Done

As I begin my 10-month adventure as a Knight-Mozilla Fellow, this seems like a good moment to re-evaluate how I’m managing my time, commitments and workflow.

I expect I’ll have to make a lot of changes in terms of tools and approaches as I shift from spending most of my time on managerial and high-level design activities to hands-on coding and collaboration on journalistic projects.

Still, there are some basic things that I need simply to maintain an organized life regardless of what I’m doing, the main one being how I manage my daily activities and commitments.

I set up and plan to maintain the following:

  • One calendar tool with multiple calendars (Google Calendar)
  • One task management tool (Todoist)
  • One email address for all correspondence (Gmail)
  • One tool to aggregate URLs to read/view (Pocket)
  • One code repo/version control tool (Github)
  • Two tools for note-taking (analog + digital)
  • Two methods for sharing reflections (twitter + blog)

Tools Set-up

Calendar (Google)

For managing commitments and events, I have the following calendars:

  • Family calendar – for all my family-related events and activities (shared with my wife)
  • Fellowship calendar – all my professional obligations and commitments
  • Personal calendar – a mix of all my other commitments (from doctor appointments to coffee with friends and larger professional development commitments outside of fellowship-related areas)

I also subscribe to my wife’s two calendars and the official calendar from the fellowship so I know what’s going on there and how all those align with my schedule.

Task Management (Todoist)

I’m a GTD (Getting Things Done) follower so as long as I have a way to capture ideas/commitments easily and am able to keep track of what I’m working on next, what other people owe me and the overall sense of what needs to happen, I’m golden.

I’ve used a variety of methods for this over the years and have been very happy with Todoist because it accommodates whatever crazy taxonomy you come up with and has amazing breadth of cross-platform implementations so it can really be ubiquitous in your life.

My particular taxonomy flavor is as follows:

I have 4 main modes I like to segregate what I’m thinking about:

  • NPR

While I had not broken things down like this at all in the past, I find that it helps me to have things organized this way so I’m not distracted by personal stuff when I’m in “work mode” and vice-versa.

I also find it helpful to break down the last two instead of keeping everything under professional so that I am able to keep good track of them independently so that I am able to keep a good balance of what work I’m doing for what (which is one of the anticipated challenges of the fellowship experience).

For each of these buckets of activities I have the expected GTD lists:

  • Waiting for…
  • Next Actions
  • Agendas
  • Projects
  • Someday/Maybe

I also have a single INBOX in Todoist which is the dumping ground for any and all things that come up during the day and I just need a place for them to go into instead of retaining them in my brain. Sometimes things go directly into the appropriate Next Actions list if it’s super well defined but most of the time they are not so it’s safer to go into Inbox so I can reflect and properly decide how to handle it later.

In short, it looks like this:

Todoist taxonomy

Because of how ToDoist is set up, this taxonomy allows me to view all lists at a glance simply by clicking the big buckets I defined, which is perfect when you are doing a daily check or weekly review. Example:

Todoist list view

If a task is directly related to a coding project, the assumption is that the project is in Github and therefore tasks are managed as Issues there.

Once I really start doing work at NPR I’ll add whatever particular approach the Visual Team uses to keep track of to-dos (probably Github issues and/or Slack).

Email (Gmail)

I take full advantage of Gmail’s inbox tabs as well as tags to manage and organize how I process incoming messages.

Gmail Tabs

I find that regardless of how well it categorizes things (which it does well and you can keep teaching it to improve matching), it helps me to chunk out the burden of going through messages (because the volume is always greater than you have the time for). If I’m really tired I know I can tackle ‘Promotions’ more easily first and feel a sense of accomplishment that makes going through ‘Primary’ less painful.

It took me a long time to really adopt tags but I now love them, specially in combination with filters so that certain things are shown pre-tagged with their relevant project name or activity which aids my scanning of the inbox and helps me get a sense of what I need to tackle.


(I tried Google’s new Inbox product and it’s not for me.)

URL Aggregator (Pocket)

Pocket is the solution to ‘tabitis‘. You know, that condition that ails all modern web denizens where you have 47 tabs open on your browser with things you loaded but aren’t really ready to read but you *really really* want to or believe will read at some point.

Tabitis sucks as keeping those open tabs is a performance hog on you machine, increases chances of crashes and, come on, you’re really just kidding yourself. Pocket has saved me from this. I see something that looks interesting, I add to Pocket (from an open tab, from a tweet, from anything really) and I can even tag to organize it and further share with others.

Basically they took what Delicious used to do, made is cross-platform and useful by focusing on the main task of “I don’t want to deal with this now but think I will later” without going overkill in the organizing aspect of the service.

Just do it, it will save your sanity. Also, it has a search so you can find anything you considered interesting at one point or another. Enough said.

Code Repo/Version Control (Github)

I haven’t really started new projects yet, but needing to have code publicly accessible and licensed, this is a really great option. I have used Github for a long time, specially issue management and so I know I’ll be setting up some crazy tagging to help with workflow, but it’s too soon to tell what/how I’ll be using it.

Note-taking (analog + digital)

For the most basic of things I have the poorest answer to. I expect this is the one that will change the most.

I’m going in with the assumption I’ll always have a notebook with me to capture anything (thought I’ll try and use it mostly for doodling and sketching) and then some other method to capture more significant textual stuff, like notes from a talk, a list of questions, etc.

I am going to try Evernote for this purpose first as I tend to take photos of whiteboards like it’s my business and have been dissatisfied with keeping photos and written words separate in the past. This needs more exploration (I tend to capture things in 10 different ways then get completely scattered and lost about where things are).

Sharing Reflections (Blog + Twitter)

I know this seems like a weird thing to add to this list, but sharing the fellowship experience is central to the spirit of OpenNews so


There is a lot more to it, but in a nutshell:

  • I check Google Calendar for what’s on the daily schedule first thing in the morning and what’s planned for the next day before I’m headed to sleep in the evening.
  • I also use those two moments to review my Next Actions lists (add anything I want to do today) and check-off stuff I’ve done.
  • I do a quick scan of the Todoist Inbox list daily for anything I can take action on the next day (or that can be scheduled for later in the calendar or as a Next Action with a date)
  • I reserve time twice daily to process Gmail inbox and work on the items in my Next Actions lists.
  • I do a weekly review to empty out my Todoist inbox and Gmail inbox. I also take a quick glance at the Projects lists to see which projects didn’t get enough love and see if I need to create Next Actions for them. I should but never actually go through all my paper notes and physical inbox during this weekly review (need to create that habit going forward).
  • I read through things I’ve saved on Pocket any time I’m idle and this is how I get a lot of reading done (waiting for the bus, while the microwave is heating stuff, when my computer is booting up, etc).
  • I always aspire to inbox zero and only handling an email once. If I read a message and there is some action to take I try to do it right then or add a Next Action where appropriate (and archive the email). That’s why having dedicated email time works instead of constantly checking email.
  • I tweet constantly because it feels like a natural extension of everyday conversations I have and augments my ability to keep in touch with the broader community I am not physically close to. I only expect that to increase in frequency over the next year (if that’s even possible).
  • I will write on this blog to share things related to the process of learning, the actual projects I work on and anything else related to the fellowship experience. My goal is to have brief reflections that are frequent (every other week) instead of long pieces that are few and far in between. I’m not sure how I’ll continue to use Medium (which I started using for broader topics outside of my core work).

I’ll check back on this post by the end of the fellowship (and maybe at some point in the middle) and note what has worked and what’s needed to change.

2015 Knight-Mozilla Fellowship

Next year I will be a fellow in the Knight-Mozilla Fellowship program run by OpenNews, where I will work with the NPR Visuals team, making fantastic things that help empower people with tools and disseminate the spirit of open source journalism. I am very excited about this opportunity and have lots to say about why I decided to take this path and why it’s important. That deserves more writing so I’ll get to it later.

I plan to capture my journey to keep track of what I do and what I learn. I’m starting with a timeline visualization of the Fellowship milestones thus far, from first becoming aware of it through announcing my participation.

Check it out.