Top

Poetry Writing Tips Explained: Tip Seven

May 27, 2005 by John Hewitt · 1 Comment 

Untitled poems are lazy. They’re like unnamed children. Obviously their parent doesn’t care about them.

I’ve had my poetry tips published for over ten years now, and this, by far, is the most controversial tip. People get very upset when I tell them that untitled poems are lazy, and there is no doubt that I could have worded this tip in a kinder, gentler way. So be it.

My worry is that it isn’t really laziness that causes this, but some pretentious desire by poets not to label their “art”. Well, forget it. Untitled poems look BAD. I absolutely hate to see poems without a title. If I do like it, what can I tell other people? Here is my dramatic recreation of a conversation about an untitled poem. Feel free to picture it as an Abbot and Costello routine.

“You know, I read this great poem the other day!”
“Really, what was it called?”
“Um, nothing.”
“That’s the name?”
“No there is no name. It’s untitled.”
“How do I look it up?”
“The poem is listed by its first line.”
“So the first line is the title?”
“No, it’s untitled.”
“Why not just make the first line the title?”
“If I could explain that, I wouldn’t be in this mental institution.”

My point is that poems deserve names, if for no other reason than to help us look them up and discuss them. Name your poems. Consider it a necessary part of the process and take the time to think of a name or just use the first line. Please.

Poetry Writing Tips Explained: Tip Six

May 24, 2005 by John Hewitt · Leave a Comment 

Don’t explain everything.

One of the key differences between poetry and prose is exposition. The nature of prose is expository. The prose writer tells a story. Generally speaking, the story progresses along logical lines as the reader discovers more and more about the subject and the plot. In order for this to happen, the writer must explain elements of the story so that the reader can follow the action and make sense of it all.

Poetry does not have to be expository. A poet can explain, but it isn’t necessary to the form and in many cases explanation can be a detriment. One of the beauties of poetry is that a poet can and should cut out everything that isn’t essential. The reader should bring their own experiences into a poem, and the more a poet tries to explain, the less the reader can decide for themselves.

There is also a danger in saying too little. What starts as concise can become vague. There is a path that each poet must navigate between what should be cut and what must remain. It is a path that each poet must determine on their own. Some poets write as if they are telling stories, and others write as if they are painting an image. Neither is wrong.

When you edit your poetry, go through each line and ask yourself if it is both necessary and interesting. Is it a line that the reader will remember, or does it merely serve to move the reader into the next moment? If the line is not necessary or interesting, it should either be cut or rewritten.

Don’t waste the time and effort of your reader and don’t try to control their experience. Say what you want to say, but don’t tell your reader what to think about your poem. Allow them to think what they want, even though their interpretation may differ from your intention. The poem is not the poet. Once created and brought into the world, the poem stands only on its own. Unlike a college text or a how-to article, a poem is not created to explain. It is created to involve. Allow the reader to determine their own involvement.

Poetry Writing Tips Explained: Tip Five

May 3, 2005 by John Hewitt · 1 Comment 

Develop your voice. Get comfortable with how you write.

Over the years, I have found many poets and writers I wanted to incorporate into my writing. Early on, I was a big fan of Lawrence Ferlinghetti.In college, I grew to admire Ai. I have been a big fan of Charles Bukowskifor years and more recently I have been reading Tony Hoagland.On the fiction side, I have moved through the influences of John Irving, Bret Easton Ellis, Anne Tyler, Walker Percy, Jim Thompson and W. Somerset Maugham to name a few.

As much as these people influence my writing, however, I don’t write like any of them. I can see some elements of each in my writing, a Ferlinghetti-like flight of fancy or a Percy-influenced malaise for example. Still, as my voice has developed (and it is still developing) I have learned to incorporate rather than emulate. While pieces of my writing may echo that of other writers, I have my own system of expression and my own style.

There is no quick route to developing your own writing style. The key is to keep writing. Write your way through the bad moments and the cheap emulations. Don’t make a conscious effort to write like someone else, no matter how much you admire their writing. Be honest with yourself. Whatever else you do, keep writing, and then write some more.

As you keep writing, you will grow more confident in your style. This isn’t a process that takes a day or a week; it is the work of a lifetime of writing. Your voice will evolve long after you have stopped worrying about developing your voice — if you keep writing.

Once you become comfortable with your voice, you won’t be as susceptible to outside influences. You can learn from a poet without copying that poet. You can add the best of other people’s influences to your style. There is value in reading and learning from great poets and great writers. Just as musicians incorporate new sounds and styles, so can poets and writers. Just remember that your voice is the influence that matters most.

Document Hack (A Technical Writer’s Journal): Quick Review of the Quick Start Guide

May 3, 2005 by John Hewitt · 1 Comment 

People who write user’s manuals for a living learn to accept the fact that most people, even people who use the product they are documenting, won’t spend a lot of time reading their work. For many users, the manual is something you consult only in an emergency, and only if you can remember where you put it. Technical writers write manuals that go mostly unread. It can be frustrating.

The quick start guide, however, is far more likely to get a user’s attention. It contains the information they truly want, how to get up and running as quickly and painlessly as possible. The customers want to start using the product without reading a whole manual of information they don’t know if they will ever need. Quick start guides get read.

The easiest way to learn to write a quick start guide is to find one and read it, then copy what they did. If you want some examples try these:

download.macromedia.com/pub/contribute/pdf/con_quick_start_6pg.pdf
lib.teiher.gr/downloads/quickstartguide.pdf
tools4ever.com/resources/pdf/MonitorMagicQuickStart.pdf
americasarmy.com/downloads/files/AmericasArmyQuickstartGuide.pdf

The basics are easy to describe. Most quick start guides have the following elements:

Introduction
An introduction may or may not be labeled. Sometimes it is just a single sentence that tells what the product is. At most it should be a few paragraphs giving the general description of the product. The purpose of this is to give the user some insight into what the product does.

Requirements
This is a list of what is needed in order to use the product. In the case of software, it is generally the minimum specifications of the computer on which you will install the software. For a physical product like a desk, it may detail what the user needs in order to put the desk together, such as a hammer and screwdriver.

Installation or assembly instructions
This is the step-by-step process for making the product operational. This is by far the most important section of a quick start guide and quite possibly the only section that will be read by the users. It must explain clearly and briefly each step in the process of installation or assembly. While there may be separate instructions for separate platforms (such as Mac OS, Linux or Windows), there is generally only one simple method of installation or assembly given. If the customer needs more options, they should consult the user’s manual.

Starting
This is where you tell the user how to start using the product. This is a quick start guide after all. The instruction may be simple such as “click on X to start application”. You may need to be more detailed if there are steps the user must take in order to begin using the product after installation or assembly.

Where to find more information
This is the section in which you tell the user where they need to go if the quick start isn’t enough. You may direct them to a user’s guide, reference chart, web site or to a phone number. Include any source that the user may need.

For the most part, a quick start guide is just that simple. Some companies may include extra information, but you must be careful not to overload the quick-start with things that rightfully belong in the user’s manual. A quick start is simply for getting the customer up and running as quickly as possible. The exception to this rule is if the company chooses not to include a full user’s manual. In that case, you may need to give more information in the quick start guide so that users have what they need.

Bottom