Most Popular


Book Reviews

The Ultimate Guide to Electronic Marketing for Small Business
The Daily Drucker
Copy This! The Story of Kinko's
Presence: An Exploration of Profound Change in People, Organizations, and Society
How To Read A Book
Contempt: How the Right is Wronging American Justice
Classical Education at Home
Copy Fights: The Future of Intellectual Property In The Information Age
Flawless Consulting: How to Get Your Expertise Used

Recently


Theme Design
IT Support
Hosting

Wednesday, November 17, 2004

WebDrive

While I'm thinking about tools... I've been meaning to blog this for a while. WebDrive is the most kickass FTP client for Windoze I've ever used. I've used a number of FTP clients (WS FTP, CuteFTP, CoffeeCup FTP, etc.) I've also done the manly-geek thing of logging in via SSH and executing some robust remove -r and .htaccess commands.

But WebDrive lets me treat an FTP volume just like a local drive, with all the access that entails. I can add/remove folders (including all contents), drag-n-drop files, etc. Very nice. And worth paying for. $59.95 from South River Technologies.

Posted by: Send an e-mail to Terry Frazier Terry Frazier at 5:18 PM  | Permanent Link  | Trackback URL | 
Categories: Productivity, Technology

Tools to Get Things Done

If you're a fan of David Allen's "Getting Things Done" (GTD) methodology for personal productivity management, Trader Mike has found a nice set of notes on David's latest seminar in Bah-stun:

Getting Things Done Seminar Blogged

You 'Getting Things Done' fans may want to check out the notes from David Allen's recent seminar posted at Buzznovation. (They start at that post and continue on for several more pages.) [via Trader Mike's Move the Crowd]

GTD is a little metaphysical - too much so for some people - but it's gaining a tremendous following. It's not your father's Todo list. I've seen GTD described thusly, "It's not time management, but rather managing yourself in time." That's a good summary. I have both the book and the Audible audio version. (Oddly, it seems impossible to link directly to the summary page for an Audible title if you aren't a member. Hmmm.)

And there is A wealth of tools is being developed to support GTD in your knowledge work environment. From Trader Mike again, here's some info on a promising PalmOS app called Life Balance. And if you're a Mind Mananger fan and Outlook user, Aussie David Buchan has good things to say about ResultManager by Gyronix.

Posted by: Send an e-mail to Terry Frazier Terry Frazier at 4:12 PM  | Permanent Link  | Trackback URL | 
Categories: Productivity


Thursday, November 4, 2004

BlogDoc 1.0 -- The Case for Iterative Blogging

In Iterative Blogging: BlogDoc 1.0 Stuart Henshall describes a collaborative scenario much like the one I began working on a little over a year ago -- a simple, structured way to support group iteration of documents, keeping all team members apprised of updates, new versions, and progress but without inundating them with mass, round-robin e-mail attachments. What I envisioned was some combination of the functions of forums, weblogs, doc mgmt, and possibly wikis. Here's the scenario Stuart described:

For the purposes of this example think business plan or a similar structured document with a fixed number of sections that will require a number of re-writes. At first glance this appeared to be a perfect application for a Wiki. I know others would even advocate forums for such development. In this case the organization had already experimented with wiki's and so far they have failed to become part of their collaborative landscape. So this small team was looking for a new vehicle from which they could update on iterations more effectively, provide a "living" state of the document now, enable both a comment format and enable version control and integrate it more effectively with e-mail and current work practices. Plus create learnings on blogs.

In the past year I've completed four document-centric projects with Fortune 100 companies. Circulating drafts and iterating documents was a key process in each, yet the experience was almost universally painful. I'm convinced there is a better, easier way that users will embrace. Weblogs and RSS with enclosures can play a role in this, but they are only part of the solution. I spent a good deal of mental energy thinking about the above scenario last year and came up with my own list of requirements, but it's longer, messier, and differs somewhat from Stuart's. So I'll quote his and then comment below:

Stuart's Key Iterative Blog Elements:

  • The latest version of the document (template retrieving the last post in each category)
  • Version Control by section (all the posts in that category and associated comments)
  • A lifestream of all updates. (the master blog, a time log of all changes and reissues)
  • Authoring Information (contribution by author and commenter)
  • Comments - Comments by version / section release and comments by time.
  • E-mail notification of updates and RSS / Newsreader integration.
  • Release Notes: Using the "Extract: function" a short release note can be captured and related to each "sectional reissue".

Extending Functionality with Additional Categories:

  • News: This is news on progress, particular data or investigative findings, thanks for inputs, recognition etc. These are primarily process and planning updates.
  • Scanning: Data that may affect the outcome or provide additional context for the document. This data can also be assigned and associated with the document to enable a live form of footnotes and substantiation.
  • Meetings or Forums. Specific dates and timing reminders.

This is a good list and I agree with most of the detail points, but in my experience the typical person in a knowledge job will not readily adopt either blogs or wikis for document creation, so the blog/wiki/forum is not the right tool in which to initiate the document. Also, when the content is complete it will likely go back into some formalized container -- a Word doc, spreadsheet, etc. -- and scattering content through a blog/wiki further inconveniences the user. Finally, not all the content is necessarily text -- it may be graphics, photos, animation, audio, or video -- and may not fit well into the text-centric nature of the blog/wiki.

So what is needed is some form of lightweight document mgmt function that can track native files and extract common types of text, combined with some automation that can post excerpts and updates to the blog/forum/wiki where users can edit and comment. RSS can be used for notifications and distribution of new versions and updates, and lightweight calendaring can send out reminders and due dates (which can also go out via RSS.) For best user uptake, everything that goes out via RSS should also be available via e-mail, at the user's option.

There are four goals for such a system:

  • Get the user to embrace its use, at least initially
  • Augment, rather than replace existing work processes and methods
  • Present a UI that is intuitive and easy for the user to understand
  • Reduce the overall time a user must spend on the iterative process.

Every other objective is subservient to these goals, because if the user doesn't embrace the system, feel immediately comfortable, find it convenient, and save time there is no way to gain any of the other advantages. The barriers to entry have to be low, and impact on users' time has to be positive, not negative. That means the system can't be radically different from what they use today, can't force them immediately into new habits, can't assault them with a lot of change. Rather, it must slip under their "resistance radar" with some immediate improvement to their lives before it earns the right to demonstrate the other value and benefits that management feels it's paying for:

  • Improved structure and accountability around the document
  • Improved "learning trail" that can be mined for additional value and insight
  • Explicit connections between subject matter experts
  • A "loosening" of the constraints around closely-held knowledge in the organization.

Ultimately, we would hope the benefits of simple group editing, bloggable updates, understandable audit trails, and automated distribution would spread like Kudzu (a prolific nuisance weed in the South) across the organization, leading to increased use of the tools for all manner of projects.

But it's the initial hurdle that stymies most efforts today, as the systems are too geeky, too complex, or just too "different" for people to get enthusiastic about them. So they continue to work in silos, e-mailing massive numbers of documents around the world with "Reply-to All" until eventually everyone has dozens of versions and most of them lose track. I cannot tell you the time I've wasted on conference calls in the past year as various team members tried to find the right version, discussed which e-mail contained the last version, or asked someone to "just shoot me another copy to be sure I have the right one." 

Last year I settled on Conversant, the platform upon which this weblog runs, as the most promising tool set to deliver this functionality. To the extent that future improvements in blog/wiki technology provide better connections to common document and presentation tools, or more structured formatting and output via PDF, some of my concerns with them may be alleviated. (I know of a couple of wiki-based solutions being developed around these premises.) But Conversant is the only tool I'm aware of today that even comes close to meeting the requirements (outside the major enterprise players.) 

Even Conversant doesn't have all the tools in its default configuration, but it does has a document management module that integrates with the blogging/messaging/event calendar structure to provide the majority of what's needed. Over the next few weeks I'll be looking at that document management function with Conversant's developer Seth Dillingham to see how well it handles the requirements and improves the iterative process.

Conversant also lacks any free-form text or wiki component, so I'll be looking to integrate a nice third-party package in some way. I really like Stuart's idea of migrating completed documents to a wiki, where they can not only be stored openly for reference but also improved over time. Integrating one into the system should be straightforward, but it can wait. Wikis are generally just too geeky to get traction in the corporate cube farms and can be introduced later, after the system has begun to show its value. More on this as I make progress.

Posted by: Send an e-mail to Terry Frazier Terry Frazier at 2:27 PM  | Permanent Link  | Trackback URL | 
Categories: Collaboration, Productivity, Technology


Monday, November 1, 2004

FeedDemon and RSS Enclosures

Nick Bradbury writes good software. I'm a longtime user of HomeSite, and a registered user of TopStyle. As I mentioned this morning, I'm playing with a trial copy of FeedDemon (in concert with BlogJet.) The combo is pretty nice, and I really like the idea of having a newsreader that syncs with Bloglines. But Bradbury made a design decision on FeedDemon that will need to change before I can commit to it as a full-time tool:

The RSS enclosure element is used to attach media (such as video) to a news item. The original design of enclosures was to enable downloading media attached to news feeds while the computer wasn't in use - for example, downloading MP3s while you sleep - so you wouldn't have to wait.

I have to confess, though, that I was never wild about this idea, at least not for FeedDemon's purposes. If you read a news item that was just retrieved by your aggregator, you probably want to see the enclosure right then and there rather than wait for it to be downloaded when the computer is idle.

More importantly, much (but admittedly not all) of the Web's media is designed to be streamed, so rather than download enclosures, why not simply link to the media object and let the system's default media application take care of it? For example, if a news item has a video enclosure, just link to it and let the media application stream it to you - no wait, and no wasted hard drive space.

So, this is how FeedDemon handles RSS enclosures. If FeedDemon encounters a news item with an enclosure, you'll see a paper clip ("attachment") icon in the newspaper. Just click this icon to view the media. [via Nick Bradbury's Blog]

So Nick concluded that the most viable use for enclosures was to stream audio/video files from web sites. I can understand this, but it's just not the case. Podcasting has shown one increasingly popular use for media files that aren't streamed. As for me, I'm interested in alternative ways of distributing strategic information. RSS enclosures seem like an efficient way to distribute a number of things that project or business teams might want to share. Some of it might be audio-video, but it might also be several other types of data. Aggregator support for enclosures has been really weak (except for Radio) until now. I'm hoping the growth of Podcasting will help change that.

I don't know how other newsreaders are handling enclosures. I may get around to trying a few more as I have time. And I plan to get Radio re-installed in a few weeks to see how it works as a client for my current blogging platform. If you have suggestions or ideas on other RSS readers feel free to leave me a comment.

Posted by: Send an e-mail to Terry Frazier Terry Frazier at 9:26 PM  | Permanent Link  | Trackback URL | 
Categories: Technology, Productivity
Terry W. Frazier
Search this site:
Advanced Search

Syndication

Add to any service
Get updates in your e-mail!

Contact

Click here to send an email to the editor of this weblog.
 
My PGP Key
My Linkedin Profile


Presence


 

 
 ICQ

 

 



 

www.flickr.com
GratefulZed's photos More of GratefulZed's photos