I got the idea after seeing alot of prodigous authors, explain how they write. Commonly they start with a story board, which they fill in as they go. Imagine a whole wall, sectioned off into chapters, in each chapter section are the names of the characters in the chapter, and their words. Then a bunch of feedback and feedforward lines, interconnecting the chapters, where scenes from one chapter affect another.

So my idea is, using Tk's HList and Tabbed Notebook, is to have a list of Chapters in the leftframe, and when you select one, a tabbed notebook appears in right with all the characters and scenes of that chapter in separate tabs. Then if you click on a tab, it will display the writings. This is where I'm stuck. For instance if I click on "some scene1", I want all the character's text, from that scene, to be displayed in proper order. Or if I click on a character, I want all text displayed by which scene it comes from. Furthermore, if I right click, I want to have displayed all "connecting feedback scenes and characters" related to that text. I know it can be done, I'm thinking with Tk::Text tags, but maybe something else would be better?

This method would make editing a breeze, because you could pull up one character and change something in all scenes where he/she appears with just a few keystrokes. It would also make it easy to write screenplays, because you could selectively pull out 1 character's lines for separate printing.

Anyways, that is the direction I'm thinking. I hope it gives you something to think about.

You mind making that available? I'm working on a novel right now and I'd love to have that kind of software available ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Working on a poker game first...priorities. :-)

---

I'm not really a human, but I play one on earth. flash japh

Wow, this really does sound like neat software. I know how pet projects can fall by the wayside. How far have you gotten on it?

Tii

How far have I gotten? Well, it's about half-way done. :-)

Actually I have the basic framework laid out in ztkdb. Go there and look at the screenshot. You can see the leftframe, the tabbed notebook, and the db access already to go. You could use that right now, by setting up a graphic thumbnail for each chapter, and assigning more tabs in the configuration file. You would have a chapter-scene layout.

But I havn't yet worked out the best way to store things in a db for a novel yet, so they can be retreived either by character, chapter or scene. But it will come to me. That ztkdb program is a graphical frontend to dbm, and if you play with it's configuration file, you can set it up for just about anything you want. But of course, it could be "optimized" to handle novel text entries. Feel free to take it and run with it. Here is a sample of what the configuration file might look like ( you can probably remove the sql search fields, but experiment first):

..snip.....
######################################################################
$user = 'zentara';                     #database user name for Pg or M
+ySql
$password = 'foobar';                        #db user password
$db = 'SQLite'; #or 'Pg' or 'mysql'    #select db
#$db = 'Pg';
###################################################################
####these are the catagories for your text tabs#### 8 allowed
$texttab1='Intro';
$texttab2='First Act';
$texttab3='Second Act';
$texttab4='Third Act';
$texttab5='Fourth Act';
$texttab6='Fifth Act';
$texttab7='Sixth Act';
$texttab8='Finish';

## run the color script for names of colors

### colors for the text tabs, do not choose
### dark colors or it will mask text
### these defaults are nice
$tabcolor1='bisque';
$tabcolor2='lightyellow';
$tabcolor3='azure';
$tabcolor4='PeachPuff';
$tabcolor5='pink';
$tabcolor6='OldLace';
$tabcolor7='wheat1';
$tabcolor8='khaki';
#################################################################
...snip....
[download]

---

I'm not really a human, but I play one on earth. flash japh

Wonderful! Please, keep me updated on the details of this project's progress. I'm sure you'd find a lot of enthusiasm when you have a production-ready version of it at NaNoWriMo.

I doubt I'm up to the challenge of adding to the project, especially since I've never used Tk in my life, but if I get around to eye-parsing the code at some point and have any ideas or suggestions to offer, I'll let you know.

Thanks for mentioning this.

- apotheon
CopyWrite Chad Perrin

But are they really such disparate, seperate skills?

In both, you start with an idea, and flesh it out. In most cases, you first come up with the premise (50_000m view), then develop the sequence of events that will occur (50m view), then work out such things as mood and dialogue (5m view), then such things as punctuation, spelling, and such as you actually compose the text (the "dirt flowing over the nose" view). You then take it through the process of editing (think debugging and testing) until you have a version ready to be released.

In addition, there are many skills involved in design and planning for any kind of a project (software, literary, or otherwise) that are not specific to the realm of a particular project (such as time estimation and management, or the development and tracking of project milestones and schedules).

So, as I said before, are they really such disparate, seperate skills?

There are great differences between the two in the actual writing, though as you indicate the planning stages are nearly identical, at least in concept.

I'm actually finding that writing a lengthy work of fiction is far easier for me than writing a substantially large piece of software. Novels, in other words, are easier for me to write than major software projects. I seem, at the moment, to have quite a bit more skill for writing fiction than for programming. The outlining of the novel and software design process for the program, however, are (again) very similar, and I seem about as good at both activities.

That's my take, anyway.

- apotheon
CopyWrite Chad Perrin

Sequence diagram <--> Outline of book/article/etc

Object diagram <--> Character/Event diagram

With sequence diagrams, one can represent possible variations in flow. Object diagrams are a good way to represent characters, their relationships, and effects of events between them. Perhaps schema would be a better term for this instead of object diagram.

Thanks, Apotheon!

Is this not the same in everything you do, as long as you are not in a crisis mode?

Even in a crisis mode, you still have to plan, the difference is that:

• The time you have is limited, and other resources might also be limited;
• The choices in front of you are limited.

For example when you are trying to resolve an emergency prodoction problem, or when you have to come up with a precidential race analysis right this moment.

So, coding skills translate into writing skills. Maybe it goes the other way too, as in using "narrative" to assist in software design? This article (which I just happened to come across yesterday) purports that idea.

..not only does it go the other way around, but (and many computer-scientist-types take umbrage at this sort of claim) being a good writer is almost more important than being a good 'coder' (unless you are the only one who will ever see your code, which rarely happens in most environments)

When you consider that even a simple "hello world" program can be intentionally coded as an "obfu" its easy to envision larger scale code becoming easily unmanagable because it doesn't have a clear beginning, middle and an end.

What's worse, a novelist doesn't have to worry about characters that misbehave (library modules with bugs) phrases that dont work on particular types of paper (platform-specific dependencies) or chapters that unexpectedly go on forever (runaway loops). A 'coder' has to worry about all of these, and thus has an even greater responsibility to 'weave these contingencies' into the overall 'story' to prevent it from becoming 'unreadable'.

I meant to convey an understanding of it being a two-way street. I certainly didn't mean that the translation only went one way.

In other words, I agree with you. That looks like a good article, too, and I'll give it a read.

- apotheon
CopyWrite Chad Perrin

Novelists try to convey information to their reader. In order to be successful, they need to approximately model, if only unconciously, on how the receiving system (their intended audience) will respond to the data, and craft their work according to their expectations.

Programmers usually try to convey information in two ways simultaneously. First, they try to convey configuration information to the mechanical systems (computers and associated hardware) that will receive the data, and craft the work so that the hardware responds as expected. Secondly, and simultaneously, they try to communicate the salient points required to understand their design to other programmers, and again craft this communication in a way that will be well received.

In perl, I find that making the code work is usually the easy part. Making the code understandable to my intended audience is hard, especially since I don't always know who that audience will be.

I try to target my code and documentation at a junior level maintainance programmer who doesn't know perl well, and may not be very familiar with my project or it's design goals. That means, I tend to trade performance considerations and development time for (hopefully) ease of understanding and maintainance.

Writing a line of code, like writing a sentence, is easy. Writing the right line of code, or the right sentence, is a difficult artform. Or at least, that's what I like to tell myself, on days when I don't feel like I've accomplished much. :-)

--
Ytrew

However, mechanic work is typically 'debugging'. Some good mechanics do improvise and even design new systems to improve or just fix vehicle problems.

Would most mechanics make good software developers? Even if they would, would they like it? Would a mechanic would be happy sitting in front of a computer all day.

Well, now you know what I was thinking about yesterday trying to figure out why my car wouldn't start. :)

I don't think there's so much of a parallel between software design and working as an automotive mechanic. The analogous profession would an automotive engineer. The auto mechanic is more like someone who specializes in debugging and never writes code from scratch, in a way, but at the same time the analogy is even then a bit too flimsy and seems to break down.

Then again, I know only very basic rudiments of automotive mechanics, so I may not be the best judge in the world of such an analogy's validity.

- apotheon
CopyWrite Chad Perrin