My New Favorite COVID-19 Dashboard

Posted on Published by Eugene Eric Kim

TL;DR I’m now using this dashboard as a way to make sense of what’s happening with COVID-19. It’s still too soon to draw any conclusions about how well the U.S.’s interventions overall are working.

I started trying to make sense of the COVID-19 growth rate data myself on March 13, 16 days ago. I learned a lot along the way, and my daily ritual of looking up numbers and updating my spreadsheet has been strangely calming. Here’s my latest graph:

Three observations when comparing this to last week’s graph:

  1. Italy’s growth rate seems to be flattening, which is a positive sign
  2. U.S.’s growth curve continues to rise at a steady rate; more on this below
  3. Even though China and Korea’s growth rates have been steady for a while now, it’s not zero. They have this under control (for now), but it’s far from over, and it won’t be until we have a vaccine, which folks keep saying is at least 12-18 months away.

My friend, Scott Foehner, chided me last week for saying that the results are lagging by about a week. He’s right. Based on Tomas Pueyo’s analysis (which I cited in my original blog post), the lag is more like 12 days. This is why the Bay Area shelter-in-place ordinance was for three weeks — that’s how much time you need to see if you’re containing your growth rate.

Shelter-in-place in the Bay Area started on March 17, exactly 12 days ago and four days after I started tracking. California’s order started on March 20. Other states followed after that, but not all.

It’s hard to make sense of all this when aggregated as a country. I’ve been wanting regional data for a while now, but have felt too overwhelmed to parse it out myself. Fortunately, other people have been doing this.

One of the positive outcomes of me doing this for myself for the past few weeks is that it’s given me a better sense of how to interpret other people’s graphs, and it’s helped me separate the wheat from the chaff. It’s also made me realize how poor data literacy seems to be for many media outlets, including major ones. They’re contributing to the problem by overwhelming people with graphs that are either not relevant or are not contextualized.

One media outlet that’s been doing a great job, in my opinion, has been The Financial Times, thanks to John Burn-Murdoch. Inspired by John’s work, Wade Fagen-Ulmschneider has produced this excellent dashboard, which has provided me exactly what I’ve wanted. (Hat tip to Rashmi Sinha.) I may stop updating my spreadsheet as a result, although I might miss the ritual too much.

Wade’s dashboard is pretty configurable overall, although you have limited control over which region’s data you’re showing. Here’s the closest equivalent to what I’ve been tracking:

And here’s what I’ve really wanted to see: the state-by-state data:

What does this tell us about the interventions so far? Again, not much. It’s too soon. Check back in another week.

I’ve seen some articles floating around with graphs comparing California to New York, crowing that sheltering-in-place is already working here. That may be the case, but it’s still too early for us to know that, and it’s irresponsible to point to a chart and suggest that this is the case. There are lots of reasons why New York might be doing so poorly compared to California that have nothing to do with interventions, density being the obvious one. Regardless, history has proven that even a few days can make a huge difference when it comes to containing epidemics, and I feel incredibly grateful that our local leaders acted as quickly as they did.

I think there are two questions that are on people’s minds. One is about hospital capacity. I’ve seen various attempts to model this, including the Covid Act Now site I mentioned last week. The one I find easiest to browse is this dashboard from the Institute for Health Metrics and Evaluation. They publish their model, which I haven’t even attempted to parse yet. (I doubt that I have the expertise to evaluate it anyway.) It suggests that, even if our current measures have flattened the curve in California, we’ll still exceed our capacity of ICU beds needed in about two weeks, although we should be okay in terms of general hospital capacity.

The second question is how much longer we’ll need to shelter-in-place (or worse). Even if we flatten the curve, lifting shelter-in-place will just get that curve going again unless we have an alternative way of managing it (e.g. test-and-trace). I haven’t seen any indications of when that will happen, so we’ll just have to continue to be patient. I feel like every day is a grind, and I’m one of the lucky ones. I can’t imagine how folks on the frontlines and those far less fortunate than me are dealing right now.

Share Your Slides!

Posted on Published by Eugene Eric Kim

Congratulations to Rashmi Sinha and her partner-in-crime, Jonathan Boutelle, for the beta release of SlideShare. SlideShare allows you to publish your slides in You Tube-like fashion. It can read PowerPoint and OpenOffice (sorry Mac users, no Keynote yet).    (LA5)

Here are my long-promised-but-never-published slides from WikiSym 2006 this past August and the Internet Identity Workshop last May:    (LA6)

I’ve got a love-hate relationship with slides, and I try to avoid them when possible, but as Ross Mayfield noted, sometimes they’re useful. And when they are, SlideShare is a fantastic way to share them. I will most certainly be using this service.    (LA9)

This is a beta, and I suspect we’ll see Flickr-like Social Networking capabilities eventually. My only gripe: There should be Permalinks for each slide, not just for the entire deck.    (LAA)

I’ve got a few more invitations left, so if you’d like to play, drop me a line.    (LAB)

BAR Camp 2005 Redux

Posted on Published by Eugene Eric Kim

Thoughts on BAR Camp. Yeah, yeah, a little late, I know. Less late than the rest of my Wikimania notes, though.    (JQX)

Many Hats    (JQY)

The most bizarre experience for me at BAR Camp was the number of people I knew from different worlds. My brain was constantly context-switching. It made me painfully aware of the number of different hats I wear, all in the name of Blue Oxen Associates.    (JQZ)

  • Purple Numbers guy.    (JR0)
  • Wiki geek.    (JR1)
  • Identity Commons contributor.    (JR2)
  • Doug Engelbart translator.    (JR3)
  • Usability guy!!! Obviously because of the sprints I’ve organized, but awkward for me, since I have no actual background in usability.    (JR4)
  • Pattern Language hat. I’ve been doing the collaboration Pattern Language dog-and-pony show the past few months, and some folks who’ve heard me speak on the subject were there. I’ll be doing a lot more of it too, so stay tuned. Patterns are damn important, useful, and interesting.    (JR5)
  • Facilitation / event organizer hat.    (JR6)
  • Nonprofit hat. The lack of nonprofit contingent was disappointing, but I had a good conversation with Ho John Lee, who’s done some great work in that space. (We were also both wearing our Korean hats, along with Min Jung Kim, a rarity at events like these.) I also met Phil Klein, a nonprofit guy who also participated in our usability sprint the following week.    (JR7)
  • Ex-DDJ hat. Some fogies, young and old, remembered me from my magazine days.    (JR8)

All this was testament both to my ADD and to the job Chris Messina, Andy Smith, and the other organizers did in only one week. Three hundred people walked through the doors over the weekend. Amazing.    (JR9)

Talks    (JRA)

The best part of the event was strengthening familiar ties and building new ones. I met lots of great people, including folks I’d only known on the ‘net. I wasn’t blown away by the talks for the most part, but some stood out.    (JRB)

  • Ka-Ping Yee did two talks, one on voting methods and another on phishing. Sadly, I only caught the tail end of the latter, but the Wiki page is fairly complete. I’ve never seen Ping do anything that I didn’t find interesting or, in many cases, profound, and these talks were no exception. (I’ll have more to say on Ping’s latest work in a later blog post.)    (JRC)
  • Xiong Changnian presented some interesting quantitative analysis of the Wikipedia community. I didn’t have as much of an opportunity to talk with Xiong as I’d like, but for those of you who have interacted with him, try not to be turned off by his bluster. He’s doing some good work, and he seems to mean well.    (JRD)
  • Rashmi Sinha and I did a roundtable on Open Source usability on the first night. Afterwards, we both agreed that we didn’t learn much new, but simply having the conversation and especially listening to a new audience was valuable. One unintended outcome: A participant (who shall remain nameless, but not unlinked!) complained about Socialtext‘s usability, which I dutifully reported on the Wiki. Adina Levin and Ross Mayfield quickly responded, saying they’re looking to hire a usability person. If you’re in the market, let them know.    (JRE)

I was so busy chatting with people, I also ended up missing a bunch of good talks: Rashmi’s tagging session, Rowan Nairn on structured data for the masses, and Tom Conrad‘s Pandora talk, which seemed to generate the most buzz at the camp.    (JRF)

Throwing Great Events    (JRG)

I toyed with the idea of doing a techie session, but in the end, the talk I should have done was one on patterns and throwing great events. BAR Camp was great, and as with all great collaborative events, there were some common patterns:    (JRH)

  • Food. One of the most critical and, amazingly, most overlooked element in an event. Lots of credit goes to Kitt Hodsden, who made sure there were enough snacks to feed a small country, and the sponsors, who kept the beer flowing and underwrote the party on Saturday night.    (JRI)
  • Introduce Yourself. The organizers borrowed the FOO Camp tradition of saying your name and three words to describe yourself, and they did it each day.    (JRJ)
  • Shared Display and Report Out. Folks did a great job of documenting on the Wiki and on their blogs and Flickr. BAR Camp owned the foobar Flickr fight.    (JRK)
  • Backchannel. I’m not a big fan of IRC at face-to-face events, and there were definitely times when I thought it detracted from the face-to-face interactions. But, it was there, and it was useful. It wasn’t logged, though.    (JRL)
  • Permission To Participate. Lots of Open Space techniques were present — again, borrowed from FOO Camp — like the butcher paper for scheduling sessions. Lots of this was also cultural, though. I think this is the hardest thing for folks who do not live in the Silicon Valley to get — the spirit of sharing that comes so naturally to folks here.    (JRM)

I’d do two things differently at the next event:    (JRN)

  • Incorporate a ritual for new attendees to make them feel welcome and to avoid clique-formation.    (JRO)
  • Add slightly more structure. Now that the organizers have done it once, they can use it as a template for the next event — for example, publishing the time slots ahead of time, and actually enforcing them, at least as far as room usage is concerned. Also, I like scheduled Report Out sessions.    (JRP)

In the postmortem, we talked a bit about what BAR Camp is supposed to be, and I really liked how Chris positioned it: As a model for organizing grassroots, free (or very cheap) alternatives to more expensive gatherings. I’m toying with the idea of incorporating BAR Camp-style alternatives to complement some non-free events I’m organizing.    (JRQ)

Extreme Usability Redux

Posted on Published by Eugene Eric Kim

Another great FLOSS Usability Sprint is in the books. As usual, great people make for great gatherings, and this event was no exception. But we did have a new goal for this event, and it resulted in some different outcomes, many of which were related to this new notion of Extreme Usability.    (JOS)

I have three overarching goals with all of these sprints:    (JOT)

  1. Improve the usability of the participating projects.    (JOU)
  2. Build greater Shared Understanding between the usability and Open Source communities.    (JOV)
  3. Catalyze community collaboration.    (JOW)

Additionally, as an organizer, you also want to “hit a home run,” as Jeff Shults likes to say. You want people to walk away feeling wonderful about themselves and about the group at large. As with baseball, you’re not going to hit a home run with every event, but you’re constantly hoping for it.    (JOX)

I think we hit a triple with our first sprint. We had great camaraderie and positive energy, everyone learned tons, and all of the participating projects made tangible progress. In fact, in the past few weeks, I learned that we made even greater progress with “catalyzing community collaboration” than even I had realized. Kieran Lal, Jan Muehlig, and Rashmi Sinha have all been developing tools for remote usability testing, a critical prerequisite for Open Source usability, where projects are usually distributed. (Our next sprint will most likely be a Remote Usability Sprint, tentatively scheduled for late Fall.) Mimi Yin‘s experiences at the first sprint helped form the seed for her most recent thinking for Chandler. Mimi’s informal discussions with Dave Greenberg at the first sprint influenced the most recent release of CiviCRM, and they worked together more closely this week. Most importantly, the many report-backs generated buzz in the community and helped bring in new talent, like Tony Chang and Jing Wu. There was also room to improve, though, and we incorporated some of that learning into this past sprint. All in all, people walked away feeling good.    (JOY)

This week’s sprint felt like a double. Once again, our projects made progress, people were buzzing and learning, and I think people had fun overall. Nevertheless, there was a cloud hanging over everybody’s head, one that made folks a bit more uncomfortable and the process as a whole more challenging. The cloud was the result of a special goal for this particular event — defining Extreme Usability.    (JOZ)

An Aside on Event Design    (JP0)

We did not define Extreme Usability prior to the event, largely because none of us knew exactly what it was. I had opinions, based on feedback from the first sprint and my own personal experiences, but I didn’t want to dictate the design of the event based on my own biases. One reason for this stemmed from my growing faith in the power of collective wisdom. Another reason was that I didn’t want people worrying too much about whether they were “doing it right.” My main concern was for the projects to get better.    (JP1)

Gathering a large group of folks with diverse backgrounds isn’t the most efficient way to develop a methodology. The vast majority of developers knew very little about usability, and only a handful had ever practiced Extreme Programming. We had 25 people attend, including users. In contrast, two people — Kent Beck and Ward Cunningham — co-conceived Extreme Programming, and they had many years of software development experience between them.    (JP2)

The other complication, which we downplayed, was that this was not simply an experiment in software development methodology. It was an experiment in Open Source software development methodology, which introduced its own constraints. Extreme Programming isn’t rampant in the Open Source community, primarily because its tenets are difficult to practice in this environment. Who is the customer? How do you pair program? What does a 40-hour work week mean, when you’re writing code on the side?    (JP3)

Given all of these factors, it seems unrealistic to have expected our participants to have contributed consciously to the creation of a new methodology. Why, then, did we try? Why this format?    (JP4)

My framing of Extreme Usability to the participants provides some insight as to why we chose this event format:    (JP5)

  • Agile Programming is an acknowledgement that software development is a collaborative process, and collaboration is hard. Agile methodologies offer a framework for alleviating these difficulties. Iteration and validation, for example, is a way to build Shared Understanding.    (JP6)
  • Methodologies like Extreme Programming lack an explicit role for usability practitioners. Extreme Programming provides rudimentary methods for developers to collaborate directly with customers, emphasizing “soft” forms of communication rather than requiring rigorous structure. User-Centered Design, on the other hand, incorporates into the process a usability specialist who has a range of methods for understanding user behavior.    (JP7)
  • The theory behind Extreme Usability is that usability practitioners should be co-collaborators with programmers for the entire lifecycle of the development process.    (JP8)
  • The biggest roadblocks for developers in this process would be to open up their minds, willingly and sincerely embracing the usability practitioners as codesigners, and accepting the possibility that their assumptions about the users and the design might be wrong.    (JP9)

The challenge is developing the framework in which usability practitioners and developers collaborate. This sprint was a laboratory in which we could experiment with this framework.    (JPA)

Rather than impose a more rigid process up-front, I wanted to test a general premise about collaboration: Eliminating barriers is generally more empowering than problematic. Pair Programming is a perfect example of this. A lot of programmers (and managers) react negatively to Pair Programming the first time they hear about it, because they assume that programmers need to be isolated to work effectively, and that they will be unable to collaborate effectively without this separate space. Experience has raised serious doubts about that assumption. We see a similar phenomenon with Wikis. Most people still assume that we have to impose structure and authority or our information spaces will devolve into chaos. Wikis obviously challenge this premise.    (JPB)

I wanted to watch how developers would work with usability practitioners with no preimposed constraints, hoping that our collective observations and experiences would result in a more useful framework than I could have come up with on my own.    (JPC)

The event was successful in this regard, but it came at a cost. We placed a heavy burden on our participants by making this goal collective and explicit. It’s hard, even debilitating, to be self-reflexive about process while you’re working. This was most evident on our second day. Frustration was palpable among our participants, as they struggled to both work on their projects and think about process. That everybody stayed positive and productive was a testament to everybody’s great attitudes, and for that I am grateful.    (JPD)

What Is Extreme Usability?    (JPE)

The conclusion among most of our participants, in the end, was that what most of us practiced was not Extreme Usability. I concur. Nevertheless, it offered some clues as to what Extreme Usability might be.    (JPF)

It may be a misnomer, for one. Rashmi Sinha suggested that what we were aiming for was actually “Collaborative Usability.” I would go further and say that it was “Extreme Design,” centering attention on the design rather than the overall development methodology.    (JPG)

Other thoughts:    (JPH)

  • “Customers” are not “users.” Once a customer becomes a codesigner, he or she loses value as a user, because he or she becomes subject to major bias from the design process itself. We attempted to include “users” as codesigners, which was wrong. You’re either one or the other (and it’s okay for a “customer” to be a codesigner), but you can’t be both.    (JPI)
  • Pairing is good. We required each project to bring two developers, and we assigned two usability specialists to each projects. However, we did not mandate pairing, and there were also other people working with each project. By the middle of the second day, each of the projects had figured this out on their own. If we do a second Extreme Usability sprint, pairing will play a central role in the process.    (JPJ)
  • Extreme Usability is not about taking shortcuts. Sprints are. The two should not be conflated. Many participants from our first sprint said that their biggest takeaway was that informal usability was valuable. You don’t need to have a high-overhead (i.e. expensive) usability process to develop usable software. I think this week’s sprint reinforced that. At the same time, I think it’s important not to conflate the sprint format with Extreme Usability.    (JPK)

Usability-Driven Projects    (JPL)

We intentionally chose early stage Open Source projects to participate in this sprint, but in doing so, we were still propagating what seems to be a given with all Open Source projects: they are started by developers. That naturally tips the power balance towards developers. I would love to do a sprint where the roles were reversed. Usability practitioners could bring project ideas — perhaps with wireframes or workflows — and developers would come to help with the design and implementation.    (JPM)

In a similar vein, Mimi Yin had a great idea. There should be an “inverted Sourceforge,” a place where usability practitioners — not developers — could start Open Source projects.    (JPN)

More Usability Sprint Fallout

Posted on Published by Eugene Eric Kim

More fallout from the FLOSS Usability Sprint. A number of participants, spearheaded by Joel Aufrecht, have launched the Open Web GUI project. The idea is simple: Create highly usable web pages for common administrative CMS tasks and distribute them under an Open Source license. The motivation is simple. The administrative function of most Open Source CMSes are largely the same. One way they could help each other is to collaborate on developing a highly usable UI (including menu layout, workflow, etc.) for common tasks that any project can use. They’re looking for visual designers and usability folks to help out; check out the web site for more information.    (IG9)

I spoke at Bay CH I on March 8. We had a great turnout, including many of the participants from the sprint. It was great to see those familiar faces. (Has it really been only a month?) Richard Anderson blogged about my talk and contributed some anecdotes of his own. Tony Chang also blogged the talk, and reiterated a problem that Rashmi Sinha had made:    (IGA)

What are the incentives for usability analysts to help open source projects? Eugene mentioned having public work that one can cite in a resume, but there must be more than that…    (IGB)

Marketing isn’t the only incentive. There are folks who pay for Open Source work, but most of these folks aren’t hiring usability practitioners. One reason for doing this sprint was to make these people realize that they should. The money is there; it’s a matter of making the case that the money would be well spent by investing it in usability.    (IGC)

Finally, Mary Hodder has been taking the notion of Extreme Usability, which emerged from the sprint, and has been running like crazy with it. Her anecdotes are great, and I have a feeling that where she’s taking the notion will be even better.    (IGD)