OK so after having gone through a good chunk of this book I think I'm ready to start thinking about how this visualization shit might work out.
So first of all, though the data is largely the same, there are two scopes that we're interested in visualizing and I think it's important to think about the two data displays separately. We've sort of been doing that, but just to put a line under it. The first one is in-story scope....
Wait, no. There are three scopes. I think. From broadest, to most narrow:
- The epic scope; the story of the data represented by all the stories together.
- The story scope; understanding what that particular day contains.
- The feedback scope; understanding what data points you are looking at at any particular moment.
I think it's helpful to separate out the feedback scope, even though it's going to work directly in tandem with the story scope most of the time, because it's going to need to be treated differently in terms of UI, and also because the user can completely alter it based on what they are looking at, unlike the broader scopes that can inherently only change incrementally as the database changes.
The datums are the same, though:
- Documents (social media posts, notes, minutes, video and audio)
- Things documented (the contents of those posts)
- arrests
- statements
- ideas
- 'memes'
- topics
- (people, i guess)
- causal relationships
And the dominant co-variable -- at least at first, as far as we now know -- is temporal. The timeline is the right idiom. But our visualization has a scale problem: tweets in a tweetline don't visually scale to time. On the right, we've got this linear timeline, but on the left, we have something completely different. Problems with this:
- there's much more content on the left side than the right side, so we really don't want to space it out like we'd need to;
- there's also the problem of concurrency, that it's probably often just infeasible to visually space them according to the timeline (the document datums, the tweets, would often overlap.)
- the "wave" visual that we've discussed several times doesn't map. you can't scroll down the TL along the wave, that's totally incoherent.
So I think what we need is a bridging device: a custom scrollbar with a variable-height grabber that will scale as it slides to fit the viewport. This solves the problem, allowing the 'wave' to expand and contract along with the viewer, while the viewer always knows how the contents of the viewport actually relate to the bigger story without having to think.
There would need to be an expanding and contracting at the top and bottom of the scroll gripper, so that you'd easily be able to see the shape of what you could scroll up or down to, while the datums in the timeline would space themselves out according to what's actually in the viewport, letting you focus on whatever datums are direcly relevant to what is in front of you.
And, a document and its representative datums in the scrollbar grip could be hovered over to highlight the pair, again providing a near-mindless source of orientation within the data.
Because we skipped a problem we already had, which was how to visually map the document datums themselves. Mapping related datums without solving that problem doesn't actually tell us much about the usefulness of any particular configuration.
Once we get the timeline combined with the scrollbar, we'll also have opened up spaces to place additional datums and observations about the datums. We'll need to figure out the best way to map these connecting datums still, but we can come back to some of the ideas we've already had, and at least we will be placing them within a visually more well-conceived UI. By squaring away this one core component, we'll get a better sense of all the different ways the rest of the visual elements can and/or should be situated.
This was like the entire problem with Occupy -- the constant struggle to understand the entire distribution of what the hell was going on. There was no fuckin' hope of that, honestly, with the tools we had. And it was never good enough just to understand one particular piece of the distribution, because there were no real separable chunks isolated from the whole; there was no representative sample. I think a lot of the urge to have more centralized control, which was constantly at tension with the distributed nature of the thing, boiled down to the fact that people couldn't act without feeling like they knew where they stood, and they couldn't know where they stood without drawing lines around what they were doing and who they were doing it with.
So making small groups and keeping them out of the fray was a way to avoid paralysis, perhaps, more than a way to take control... hmm. Of course, this is usually how these moves are explained -- by an urgent desire to somehow act. It's always sounded suspiciously impatient to me, in that way that radicals can sometimes be reckless in their pursuit of root solutions without proper self-checking, but perhaps there is more to this than I had considered. Perhaps my comrades have been looking down a road I hadn't appreciated and are turning away early not because it's too challenging but because the road is under construction...
Build the road, tho, and such! That's hopefully what I'm moving towards here.