So ladies and gentlemen, presenting Twexicon.

TWEXICON

1. Twitter (N): Online Micro blogging service to send and view second-by-second status updates, almost instantaneous updates from the entire Connected World.
2. Tweet [pronounced Tw-E-t] (N): A Twitter Message; (v) to send a Twitter message
3. Tweeter (N): A person who tweets, a Twitter user.
4. Tweeting (N): The act of sending a Tweet or Twitter message
5. Tweeple (N): People on Twitter
6. Follow (V): To follow someone’s updates on Twitter
7. Unfollow (V): To stop following someone’s updates on Twitter
8. Twiddle (V): To fiddle with Twitter; no SOP exists but activities range from banging your head trying to think of an intelligent message to Tweet (as opposed to “Gawd, I’m late to work!” or “My cat is puking”), or trying to decide whether to delete your Twitter account or no. Twiddling is limited only by your imagination.
9. Twiverse/Twpoem (N, V): Verses limited to 140 characters or less, the act of writing such verses.
10. Twoiletry (N): Your Twitter-enabled device that lets you Tweet from the loo.
11. Twral (V): To bait someone on Twitter.
12. Twralling (N): The act of baiting someone on Twitter.
13. Tweetus Interruptus (N): Act of interrupting somebody when he/she is in the middle of typing a Tweet.
14. Premature Twijaculation (N): Tweet incomplete because the Tweeter ran out of the alloted 140 characters.
15. Twit (N): Witty Tweet

Leave a comment and I’ll update Twexicon.

Tags: Blogging, Blogs, Microblogging, Microblogs, Technology, Tweet, Twexicon, Twitter, Twitter Dictionary

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

And don’t miss Benjamin Franklin’s diary.

I’m going to bookmark this blog and add it to my blog roll.

Tags: Artists, Blog roll, Diary, Journal, Routine of Creative People, Writers

1. Stephen King. In his book On Writing, King says that he writes 10 pages a day without fail, even on holidays. That’s a lot of writing each day, and it has led to some incredible results: King is one of the most prolific writers of our time.

2. Ernest Hemingway. By contrast with King, “Papa” Hemingway wrote 500 words a day. That’s not bad, though. Hemingway, like me, woke early to write to avoid the heat and to write in peace and quiet. Interestingly, though Hemingway is famous for his alcoholism, he said he never wrote while drunk.

Contented.

Tags: Great Writers, Habits of Great Writers, Hemingway, Stephen King, Writers, Writing

The hard in "hard work" refers not to writing but to choice. Choice, in writing as in life, is hard because it exposes you to uncertainty. I originally started this post with "I am a technical writer," and then, I deliberately chose practicing. I like to think of practicing my profession as a judge practices jurisprudence. The choice of discarding one word in favour of its equivalent might alter the course of your piece for the better. Or worse.

I like words. More personally, I like how words sound when they are strung together. The title of this blog is my dedication to the book of the same name that awakened me to the sonority of words. William Zinsser has my eternal gratitude for saying in so many few words that when people read, they actually hear. Listen…err…read this aloud.

Was this the face that launched a thousand ships?
And burnt the topless towers of Ilium?
Sweet Helen, make me immortal with a kiss:

And tell me if it’s possible to resist the sheer seductive power of this appeal, which led Thomas Nashe to say this about Marlowe: No leaf he wrote on but was like a burning glass to set on fire all his readers. Or this, which, Zinsser says quoting E.B White, has survived for more than a century: these are the times that try men’s souls. I’m not Thomas Paine to get anywhere close to crafting such immutable lines but attempting doesn’t hurt. Exquisite writing flows from simplicity. Which in turn flows from a cultivated negligence about grammatical nuances.

This blog will showcase such brilliant written gems starting with some personal favourites. Cutting across genres. That includes finely-crafted items from the world of technical writing. In some circles, The C Programming Language is regarded as a classic, a model for technical writing. No genre is taboo or out of bounds for this blog. Elegance and clarity of expression are values I hold dear. The medium is the message. Yet, because I have been a technical writer for a long time, this blog will appear partial to technology-related writing and will focus on such things as user experience and design and take you on a tour of the landscape of the information technology complete with panoramic visuals as also the rugged edges and deceptive cliffs.

You write best when you write for yourself. And so I throw this blog open to all addicts of the written word. Join me, comment, share what you’ve discovered or written, discuss, diss, and in general, have a good time.

Technorati Profile

More later.