|
|
|
|
|
by rjknight
4771 days ago
|
|
I disagree. There is a set of great storytellers, and a set of great developers, but these rarely overlap; an individual who embodies both attributes is vanishingly rare, and only elite organisations (e.g. the NYT) can afford to employ teams containing a critical mass of both talents. As a result, there are going to be lots of great storytellers out there who are "technologically constrained"; the one thing preventing them from creating the next Snow Fall is the fact that they simply don't know how to work with the technology necessary to do so, and nor does anyone they work with. You might argue that these great storytellers could tell their stories without recourse to new technology, and you'd be right. But the same would apply to any new technology at any point in time. What Scrollkit is doing is what software developers have always done: made it possible for non-developers to do stuff that, previously, only those with direct access to talented developers could do. |
|
That said, here is the key problem that scrollkit runs into: Content management. I never saw the Snow-Fall-reproduction video, but I'm assuming it involved cutting-pasting wide swaths of the final product into its editor. For the sake of argument, let's pretend that scrollkit's replica was pixel perfect.
OK, but here's the part that scrollkit does not solve at all: how does their tool manage the actual story-creation-editing process? Most writers do their writing in a text editor (Microsoft Word), then paste it into their CMS (Wordpress for example). Multimedia developers, ultimately, do kind of the same thing...build their thing (video, JS graphic, whatever) in their dev environment, and place its representation into the CMS.
OK, that's easy enough...until the writer decides that they want to remove a paragraph, switch others around, etc. etc...In a system like scrollkit's, which as far as I can tell, is a single page template editor...the writer cannot simply just select-all-delete-copy-paste because, well, that would delete the multimedia artist's work.
That's just one logistical hurdle, and probably the most minor one. But when you try to edit this piece with several people, you are going to run into major, show-stopping, hair pulling issues. This is hard to explain to developers, because we have such things as Git, automated testing, IDE's etc....imagine working on a codebase without any of those things. That is the world of virtually most content producers...which is why we have CMS and templates in the first place.
This is all descending into pedantics...but that's precisely the issue. Content producers, if you give them a bespoke tool to create something "beautiful", will happily work 24/7 doing such things as manually kerning text, fixing paragraph widows, hand inserting links over and over, etc. etc....because they don't know of any better way to do things. They don't realize how much time of their time they're wasting into reinventing the wheel. And when a production involves multiple people with varying objectives, you will have a serious clusterfuck.
And we haven't even gotten to the part of how these bespoke feature creations are linked (not just hyperlinked) into the creator's site.
So that's my issue. scrollkit solves (if it works completely as advertised) one of the least important problems in the online publishing workflow. Which is not to say that it's useless, but the problem is that it, IMHO, is doing a massive disservice by telling people that this, the problem they focus on, is the real barrier to creating compelling journalistic features.