|
|
Wanted: UML for fiction
I'm trying to write a synopsis of the revised second half of Sargasso, the YA-ish nanotech novel I'm writing with Paul Melko.
I hate writing synopses because it's very hard for me to think about plot in advance. Very much as Delany writes, I feel that fiction is accretive: every word changes the context, and thus the meaning, of all the words that have come before. All the best things-that-happen in my stories are suggested by words I wrote while writing the story, not by some plan I had, of which the story is the implementation. I don't really get -- other than intellectually -- the distinction between "plot", "character", and "style".
In the programmer world, this is what the XP folk call "listening to the code" -- instead of imposing the will of your conscious plan on your creation, you always take the next local step, and then periodically refine the whole to all make sense together. You allow yourself to be surprised.
By the same token, though, while you don't need to have a high-level plan that you stick to rigidly, you want to have the ability to visualize and manipulate things at a high level of abstraction.
While you're making incremental steps, line-by-line -- inch ahead, tidy the whole, inch ahead, tidy the whole --you need to see what the whole thing looks like from a birds'-eye view, and what you are doing to it. XP talks about "emergent design" (a very intelligent kind of design, by the way). But design can't emerge unless you can see it.
So this morning I realized that what I really want for novels is something like UML --a visual modelling language for fiction.
The things I've seen that try to go in this direction are more like formulas -- the Seven Plots, the Three-Acts, the Twelve-Point Program. They are a predefined structure you build your story around. That's not what I'm talking about. They are, at best, a design pattern -- something like Model-View-Controller. But not every application needs to be an MVC instance, and saying something is MVC tells you a few things about it, but only certain specific things.
What I'm looking for is not such a formula, but the minimally complex, maximally expressive notation you would use to draw such a formula.
I was trying to create something like this this morning, and trying to puzzle out what the primitives would be. I have a few scribbles, with primitives (conflict, resolution, set piece, character, character action, obstacle, macguffin, thematic element) and relationships (causes, influences, expresses). Needs work though.
Anyone else ever tried to do anything like this? What do you scribble, when you plot?
Posted by benrosen at May 23, 2007 03:43 PM | Up to blog"But design can't emerge unless you can see it."? Okay, this sentence might be true in a narrow technical sense, but in context it reads a lot like "design hasn't emerged until you've drawn a formal diagram of it", which is completely and utterly false.
UML evolved from several progressively more formal lineages of informal diagrams. Why don't you try just drawing some boxes of your actually existing MS on whiteboards for a while instead of trying to BDUF the meta-process?
Posted by: David Moles at May 31, 2007 07:29 AMYou seem to think my day-job practices are a lot more formal than they are. :-) No, I'm talking about an agile use of UML. I've never been in a software process where we diagrammed everything and then programmed it. The two ways I've used UML are as an alternative visualization of code (like Together's class diagram, which is round-trip engineered from the code, so designing and coding are inseparable activities), or as an irregular punctuation of the normal, iterative story/code/refactor cycle -- those moments when you say "OK, hold on, let's visualize what we've got here at a higher level", and draw on the whiteboard. For a few minutes. Or at most, for a class library likely to be used a lot by a distributed team, I might whip up a GIF of UML for a few key relationships and stick it on the project wiki.
It's the whiteboard situation I'm talking about -- I feel like I'm at a point in my novel which is analogous to the point in software development where you say, "hmm, let me sketch this out for you," and am missing my usual tools. Never mind the entire robust vocabularies of UML and Design Patterns -- I feel like I'm missing primitive notions on the order of "class". (As Delany observes in About Writing, the vocabulary of "character, plot, theme, setting" is a vocabulary (emergently) designed for literary criticism, and is not well-adapted to actually writing.)
So I actually am saying "until you can see it", with a visual modelling language being one of the ways I am used to (only at certain moments) being able to see, rather than "until you have a formal diagram" (which would imply that 99.9% of my software has no design :-> ).
The idea that because a good way to make software is a series of small iterations, therefore a good way to design a modelling language is a similar series of small iterations, is appealing but I have no idea if it's true or not, and I'm wary of cross-domain analogies. The false analogy between software development and civil engineering which dominated process thinking for decades cost untold billions of dollars, after all.
Is it true that "UML evolved from several progressively more formal lineages of informal diagrams"? I'd say UML itself was committee-wrangled from a bunch of formal lineages of formal diagrams, which had been born as formal diagrams.
We're not anywhere near the point in the process where the committees of modelling consultancies (Booch, Jacobson, Rumbaugh et al), smelling the extinction of their way of life, band together to hash out a unified approach. At that point in time their various methodologies were indeed arguably results of an evolutionary process, having been tweaked and tweaked over the years to accomodate various clients.
But I think the idea that they grew up from boxlike sketches with no formal system, gradually formalizing decade by decade, is probably false (though I'd be interested in historical evidence). My sense is there was an informal practice called "here's some stuff", in which boxes represented anything -- actors, modules, features, physical boxes, whatever -- and arrows or lines represented anything -- inheritance, messages sent, things being vaguely similar -- and that was pretty much it until someone came along and, applying totally separate techniques borrowed from other domains, invented flowcharts, or the Booch Method, or any other formalization.
I don't think you get naturally from the naive sketch to, say, the 1982 Booch Method cloud class diagram by iteration, any more than a successful open source project starts with a few lines of code shared between many coders. I suspect that a visual language -- like an open source project, and unlike software development projects in other contexts -- requires a critical mass to start with.
Someone sitting down and creating sendmail or HTML or flow charts and making them good enough to be actually useful to a number of people is a prerequisite for, not a result of, an evolutionary process.
I am drawing boxes of my existing MS. Obviously I wouldnt start writing a novel with a modelling language! (That would be even dumber than starting a software project by drawing a class diagram. At least for the kind of writer I am. I can't even write an outline).
The problem is that all the boxes look the same, and all the lines look the same, and after having drawn the sketch I don't know any more than I did before -- which is precisely my experience of that kind of naive s/w diagram where you draw a box for the server, a box for the user, a box for the message, a box for the data, and a box for the program, and then draw lines between them and stare at it, numbly, wondering what it's trying to tell you.
Posted by: Benjamin Rosenbaum at May 31, 2007 09:10 AM
I'm wary of cross-domain analogies
Okay, take a step back and see if you can see how funny this is in this context.
Posted by: David Moles at May 31, 2007 09:42 AMwell, can you tolerate cross-discipline cross-language analogies?! in fact it is very likely i will soon shift dramatically into italian while i am trying to give you the dime of my experience. What happens when I draw something and then looking back am confortable with it (bird eye watching? time shaping? like "ok I've tried enough, that's it, i am moving on")? Basically I grasp an image in my head, as accurate as it can be (it is always in my head even if it is in front of me - that's how it works for me at least) then i take un lapis duro e comincio a disegnare una serie di linee very much like clouds on the sheet of paper. How does the lapis move? I guess following a cannovaccio of basic known shapes, actions and effects (nose, foot, hills, walk, lay, gravity, pull, midday, mist...). The faster the numb cloud is there in front of me e migliori sono gli auspici per il risultato finale. Then i change my pencil into a HB or B or even B2 and start working on the nuvola to look for, hopefully find and then make emerge the details. And that is accomplished in single squares of the lightdrawncloud. This is a back and forth process where what emerges has to be consistent with the lightdrawncloud. What happens a lot is that the single portions take over the cloud and tell a different story and if they are abbastanza convincenti make me come back on the cloud with a vengeance and the hard lapis. Time is the key for me. I know that if it takes more than X minutes (depends on the "thing") to scribble the cloud something is wrong. That is 1) i have no clear idea of what i want to do, 2) my idea sorpassa my skills. When the cloud is there I feel the job is done even if it might take hours or days to finish it. And yet as I said the process can bring on severe reform to the cloud. The cloud itself is a magical thing that (i wish) it contains the "right line" in the middle of a mess of lines. Also these mess is crucial because it often (always) contains the dynamics (both movement and or emotion) that cannot be lost in the end. So the process is take out the "right line" while take care of the messo'lines. The result wants to be a significant thing with life in it. How fast can you cloud a novel?
Posted by: mau at May 31, 2007 11:20 AMWhile we're making cross-domain analogies, it seems to me that your problem isn't with design so much as it's with requirements analysis.
Posted by: David Moles at June 1, 2007 04:36 AMHmmm, interesting idea and I've got some thoughts. As if I needed another cat to wax.
Posted by: Scott Janssens at June 3, 2007 04:05 PMCiao! Maurizio! Bello! Come stai! Dai un bacio a Ilaria da me!
Ben,
I've been working on a modified meta model for describing the information reality of large complex enterprises accross diverse domains. Its something we need for soa integration at my work and its based on the Zachman framework.
Its absurdly general, so much so as to make it almost useless for anything other than insight when stuck, but I think it could be adapted to fiction with a few deft ben twists.
shall we make an afternoon of it?
Posted by: Jamey at June 7, 2007 10:34 PMciao jamey, lo farò! )
wtf is a Zachman framework?!!
anyway useless models are cool
