In my dreams you traverse like a caress that I can see, alas cannot feel

And when I’m awake you taunt me with the distance that separates us

My dreams are then to me more dearer.

Tags: Original Poetry, Poem, Poetry, Verse

Our lips part to talk but stop and tremble;
Like baiting, half-blossomed flower-petals,
Speaking the tongue of the tender night-breeze–
Only we know what we entreat each other
In this everlasting silent night.

Tags: Original Poetry, Poem, Poetry, Writing

Oh yeah! Here goes.

Before we begin, the previous para is a very substandard illustration of a fancy technique of writing fiction: stream of consciousness, where you write down your thoughts as they occur. Now why am I saying this? In my rude guide, I wrote

…you primarily write to achieve technical and subject-matter accuracy and clarity. Your readers and/or reviewers’ primarily concern is whether you’ve achieved that and not so much for that wicked turn of phrase that you’ve introduced in the second para in the Overview of the Megaphone Connector for JDBC (Heading 1)…in other words, writing in this case, is subservient to technology/subject matter.

And now, back to the “much water has flowed” bit I just mentioned. Over the past month, I was witness to a fascinating discussion the details of which I shall spare you. It was a discussion centered around the (lack of) very basics of writing. Which is why I thought it’s time to re-examine the “writing in this case, is subservient to technology/subject matter” statement.

Problems in most human endeavours–I love it when I sound lofty–can be overcome if you abide by three factors:

1. Solid grounding in the fundamentals
2. Common sense
3. A penchant for not taking things literally

I know I’m sounding like I’m on a high horse talking down to ordinary mortals but indulge me, please. There! I said please. In all sincerity, let’s see how these factors apply in our context:

1. Solid grounding in the fundamentals of language/writing: I never tire of saying this: Technical Writing = Technical + Writing, where writing should be second nature to you. At the very least, writing mustn’t be an effort for you. If you plan to learn the parts of speech, articles, elementary sentence construction, and voices on the job, you’re probably considering a wrong career choice. Like I said, technical writing is not for everyone. Writing is not an optional skill for a technical writer.
2. Common sense: Cannot be defined although the dictionary says it is “exhibiting native good judgment (adj)” and “sound practical judgment (n).” Quite good but nobody can ever say what the judgment in question really is–it is entirely situational. Which is why the world abounds with helpful examples of what common sense is. I hate to do this to you but if you were given a lemon and presented with some choices would you rather squeeze it on your neighbour’s open wound or make lemonade or use it with Tequila (ha!)? Answer carefully. In much the same way, common sense dictates that if it takes you 37 steps to document a feature, you’d rather talk to your project team and simplify the interface. And because we’re talking about writing, common sense tells you that it’s a mistake to use figures of speech in a technical document: You cannot retrieve your files if you permanently empty the Recycle Bin just like trash once taken away by the garbage van cannot be recovered.
3. A penchant for not taking things literally: This is really a variation of #2 above. So when I say “much water has flowed,” you must not conjure mental images of water flowing underneath a bridge or something. The same thing applies for “I’m on on a high horse.” I’m a technical writer, not a jockey, for God’s sake. And so, when I say “writing in this case, is subservient to technology/subject matter” it doesn’t mean you take it literally: it just means that I assume that you possess above-average writing skills (ref:#1 above) when you call yourself a technical writer. If you call yourself a surgeon, remember that at the least I don’t expect you to use a butcher’s knife for performing surgery on me.

Actually this entire post is an exercise in stating the obvious but I suppose I haven’t stated it in vain.

Tags: Advice, Basics, Commonsense, Documentation, Language, Random Stuff, Tech Writing, Technical Writing, Writers, Writing

Rebirth

Inside, the swirling wind swishes continuously
swooshing over my shut stony tomb
not powerful to slide its slab though
stiff enough to arouse the stirrings
of disturbance inside the confined hole.
Dark and bottomless, but I can’t see–
I’m stirring and trying to turn,
I wind my neck tight and kick,
a whiff unbeknown escapes in a gush,
a sudden dazzle greets the eyes I open and quickly close,
a rumble that begins in my belly becomes
a wail, and a shrill shriek—
multiple, painful simultaneous experiences like
gigantic waves that lash helpless pebbles who
gladly die this second in secure knowledge of
their rebirth in the next.

Tags: Original Poetry, Poem, Poetry, Rebirth

Tags: Death of a Friend, In Memoriam, Original Poetry, Poem, Poetry, Sonnet in Memoriam, Writing

In my experience, Agile worked great for the developers and QA/testing folks but not as well for the UX and documentation folks. The primary reason was the constant flux in what emerged when an iteration ended. For example, if feature A was completed at the end of iteration 3, I’d document it the way it was looked (the user interface) and worked. However, in the planning meeting for iteration 4, somebody would point out that some UI element for feature A needed to change. Now I had to redo the documentation for the same feature in iteration 4. Additionally, in the same planning meeting, somebody else realized that a feature already completed in iteration 2 needed an enhancement. They’d put that as a task in iteration 4. I now had two repeat tasks. Add to this, every iteration typically had documentation reviews by these cross functional teams. Now, because each iteration typically lasted for 3 weeks at the maximum, the review task would be deferred to the next iteration. This meant I couldn’t mark my writing task as complete for the iteration although from a purely writing/authoring perspective, it was, indeed, complete. The resultant confusion for the writers bordered on chaos simply because it was too hard to keep track of what was going where. Kris explains this quite nicely:

I think when it comes to restructuring the workflow of a product to make it significantly better, executives need to understand there is a time for Agile, and a time to redesign, and redesign efforts take more in the range of 2-6 months to complete, in my experience. It all depends on how much is “surface” redesign, such as moving things around on the pages and creating a nicer look and feel vs. how much the deeper code has to be modified because features need to work completely differently than the developers designed them.

And nails it accurately here:

Do we need the internal motivation of a release every 4-6 weeks to make things happen? Customers don’t necessarily demand a release once a month, they just need bugs fixed and problematic features redesigned so they can perform their tasks better…Why do we have to release something once a month?

In other words, efforts to “quicken” the time to market shouldn’t compromise the “big picture” of the product. Ultimately, any product is the sum of its parts. The efforts should, really stay focussed on incrementally improving the product–in an Agile mode or no–than on making newer releases purely for its own sake, or worse, by a fear of the imaginary market monster.

In the end, the documentation folks were nicely frustrated. You can begin documenting a product if these conditions are met at the minimum:

• A reasonably stable feature set
• An interface that’s at least 80% frozen

Writing in our industry typically involves explaining things to other people. The better the writer understands what he is writing about, the less he has to rely on other folks for technical/product inputs. And to better understand, the writer needs to work real-time with the product that doesn’t change with every iteration. Ultimately, we solved the problem by beginning the actual writing work quite late in the game–that is, when we were reasonably sure that everything was pretty stable and changes would be minimal but we were present in the daily scrum, planning, and iteration-end meetings.

The biggest takeaway personally from Agile was how it offers a ruthlessly-close project tracking mechanism, and the scope it provides to build great professional relationships because you’re a small but tightly-knit team working really closely.

Tags: Agile, Agile in UX, Kris on Agile, Software Development, Technical Documentation, Technical Writing & Agile, Technology, Writing in an Agile Setup

Meanwhile, the BBC plans to do a documentary on Eliot’s private correspondence, which his widow Valerie has recently made public. A fascinating item therein is Eliot’s rejection of George Orwell’s classic, Animal Farm. This article calls it the “literary snub of the 20th century.” Eliot’s reasons for rejecting Animal Farm are equally fascinating.

When Orwell submitted his novel, an allegory on Stalin’s dictatorship, Eliot praised its “good writing” and “fundamental integrity”.

However, the book’s politics, at a time when Britain was allied with the Soviet Union against Hitler, were another matter.

“We have no conviction that this is the right point of view from which to criticise the political situation at the current time,” wrote Eliot, adding that he thought its “view, which I take to be generally Trotskyite, is not convincing”.

Eliot wrote: “After all, your pigs are far more intelligent than the other animals, and therefore the best qualified to run the farm – in fact there couldn’t have been an Animal Farm at all without them: so that what was needed (someone might argue) was not more communism but more public-spirited pigs.”

The original rejection letter discloses that Eliot was more concerned about Britain’s friendly relations with the USSR in the time of war. Here’s the revealing portion:

On the other hand, we have no conviction…that this is the right point of view from which to criticise the political situation at the present time. It is certainly the duty of any publishing firm, which pretends to other interests…than mere commerical prosperity, to publish books which go against the current of the moment. [Ed: Underlined]

Quite a giveaway, isn’t it? Thank God for Secker & Warburg, who ultimately published Animal Farm. We saw the truth fenced behind the real Animal Farm post Perestroika and Glasnost. Recall the Chief Pig who finally stands up and exercises his totalitarianism at the end of the novel?

Tags: Animal Farm, Eliot Rejected Animal Farm, English Novels, Fiction, George Orwell, Poets, T.S Eliot, Writers, Writing

Noises on my way to work–
Opposite me, on the outside,
From the side hurtling forth with unexpected rush,
Overtaking me from directions real and imaginary.

Loud sounds around the window or
When I open my door, I welcome more noise to trespass;
Walks all around inside my house,
Its power empowers but itself.

Cymbals bearing the non-Lawerence din
Ring in my head, shiver my being with
Uninvited, violent vibrations, I wonder
What vestige remains of me that I have wasted so much
Of irretrievable Solitude.

Tags: Original Poetry, Poem, Poetry

I quite like the way you clarify
With words repeated and repetitive wordplay
With conjoined alphabets and letters– or is that
Alphabetter, the way you invent your own
Spellings, assign old sounds to your
Evernew matings of the letters–
In your confusion lies clarity.

Tags: Original Poetry, Poem, Poetry, Word Play, Wordplay, Words

The first post deals with the direct impact headlines have on revenue. It measures the number of signups Highrise attracted with each headline.

Here’s how the test works. We used Google Website Optimizer to randomly rotate five different headline and subhead combinations on the signup page. We’re measuring the number of clicks on any green “Sign Up” button. We’re not measuring any specific plan, just that “someone picked a paying plan.” We ran the test for 4000 page views. Why 4000? The numbers didn’t change much after about 3000 page views, so we stopped at 4000.

Jason then gives a detailed analysis of the winning headline, which is what the Highrise product home page currently shows. The reason why this headline worked was because it

… put the emphasis on the 30-day free trial by making that the headline. The subhead let people know that signup was quick (less than 60 seconds). The second part of the subhead asked someone to “pick a plan.” This was also the only combo to feature an exclamation mark. Would be interesting to run this headline against itself — one with a period and one with an exclamation mark.

This maybe a stupid question but what the hell, I need to know it. In all the tests 37Signals ran, they don’t reveal the duration of running each headline. For example, did the winning headline run for 14 days while other headlines ran for less than 14 days? I’m assuming they all ran for equal duration but I’m not sure. I think the impact could vary if this parameter was also introduced.

I think what really made it the winning headline a hit owes a lot to the subhead. The subhead is a strong “call to positive action.” While the losing-subheads do start with action verbs, this one is compelling because everything there just drips with positivity. Compare:

• Worst Loser: Pay as you go..No Hidden fees (pretty weak)
• Worse: No long term contracts, no hidden fees, no suprises (count the number of Nos)
• Better than Worse: Ditto as “worse” but it came second because this time, the headline was stronger.

The winner combines the best of these worlds: a strong headline plus a subhead that calls for action using positive terminology.

The other post on witing decisions is an excellent demonstration of both the process and the art of effective Web writing. Jason approaches the topic primarily from a space-constraint perspective–how to convey the entire message accurately using less words. But I think it equally applies to any Web-writing scenario.

Think about what you really need to say, write it in place, figure remove what’s non-essential, pare it down, make sure you’re getting to the point without using terms that require additional explanation…

Oh but do read how he arrived at this. I seriously think if we all analyzed, in hindsight, how we wrote something that works (or sucks), our next bout of writing something will be all the better for it.

Tags: 37Signals, Effective Web Writing, Signal Vs Noise Blog, Technology, Web Writing, Writing