Zoho in the Entertainment Business?

You read it here first: Zoho must be planning to take over the entertainment business. Need proof? Just watch the promo video for Zoho Creator Mobile version. Gone are the screenshots, canned demos… it’s all Life 2.0 smile_shades

Hm… I hope his sweethearts’s phone number is not real … otherwise he’s got competition for that movie.smile_tongue

On a more serious note: Zoho is mostly known for their Office Suite and are often compared to Google and Microsoft, when talking about documents, spreadsheets and presentations. Database management and application generation are often overlooked, probably since Google does not have anything to offer in these areas. But Zoho does, and in fact that’s the application that attracts the largest active user base. Creator allows non-tech-types (like yours truly) to easily create fairly sophisticated applications, which are often shared by dozens or hundreds of users. There are about 60K (!)applications developed in Creator, used by over half a million people. (Side note: there must be a fair amount of redundancy among 60 thousand applicationss, and while you can share them publicly today, I’d like to see Zoho develop the search / categorization tools to easily locate them; a sort of “marketplace” even if there’s no actual money flow.)

We can’t really talk about Creator without mentioning a related product: Zoho DB. While Creator is an application generator, DB is primarily for data manipulation, analysis and reporting. Zoho CEO Sridhar Vembu explains the differences here.

Computerworld recently listed Zoho Creator amongst the Five free Web apps we can’t live without. There is also a blog started started by users, entirely dedicated to Zoho Creator, with special focus on using it as a small business software platform: Land of Zoho Creator.

(Disclaimer: I’m an Advisor to Zoho.)


Flow vs. Structure: Escaping From the Document & Directory Jungle

I do not think/work/create like a machine.

My thoughts flow freely and I tend to discover relationships between events (hence “Connecting the Dots” above in the Blog Header), so I like linking things – at least mentally. Why would I confine myself to the rigid directory & file structure that computers have forced on us for decades? There are better ways… let’s look at some.

A while ago Atlassian CEO Mike Cannon-Brookes wrote and excellent piece on how Enterprise Wikis Replace Shared Drives. Shared drives as collective document depositories are a disaster, we typically can’t determine where, to put things, and certainly don’t know where to find them. And if we do find a document, how do we know whether we have the latest version? How do we know who changed what in the dozen other copies with similar but cryptic filenames spread around the shared drive?

Wouldn’t it be easier to use the equivalent of a directory structure with meaningful names, the ability to attach longer narratives to our documents and find them easily via search and tags? That’s essentially what you get when you use an enterprise wiki as your “shared drive”. Think of not documents/files only, but the very reason they exist: in business we typically work on a few “projects” at any one time. If we create wikis / wiki pages for each project / function, the page content becomes the “narrative” that describes what we do, why and how, and further supporting details are in the document attachments. There really is no reason to bury documents (doc, xls, ppt) in some central dumping place (document depository) anymore – they belong to the wiki page (project description) where by definition they are in context. Of course they can be used in several other places, in different context, which is where linking comes handy – linking to wiki pages as well as other content (documents, web sites, etc).

Now that we established the wiki as the “glue” to tie all our documents together, let’s take a step further. As we get comfortable with the wiki, we’ll often wonder when to create a separate document and when to use native wiki pages. If your wiki supports a rich word processor, textual content can easily move in the wiki pages themselves. (Interestingly, Blogtronix, the Enterprise 2.0 platform vendor uses the “document” metaphor for what others call a wiki-page.) Of course whether we call them pages or documents, they should still be easy to share with “outsiders”, by using workspace or page-level permissions, or exporting to PDF and other file formats should you need to “detach” content and email it.
This works well for text, while for other needs we shoot out to the point applications and attach the resulting files (ppt, xls… etc.)

However, like I stated before, I do see the irony of working in an online collaboration platform (the wiki) yet having to upload/download attachments. Atlassian’s Webdav plugin for Confluence is an elegant solution (edit offline, save directly to the wiki), but for most other wikis the process involves far too many steps. Why not directly edit all these documents online? This of course takes us to the old debate whether the wiki should become the new office, or just the “integrator” holding the many pieces together. As a user, I don’t see why I should care: I just want seamless workflow between my wiki, spreadsheet, presentation manager, project management tool …etc. Such integration is easier when all applications/documents are online, and there are excellent applications from Zoho, ThinkFree, Editgrid, Google, to do just that.

Working directly on the Web is not just a matter of convenience. Zoho’s Raju Vegesna points to mobility, sharing & collaboration, presence & communication, auto-Versioning, auto-save, access & edit history as native benefits of web-documents.

As we link web documents to each other, and smoothly transition between applications, a paradigm shift occurs: the definition of what we call a “document” expands. Offline, a document equals a file, defined by application constraints. Spreadsheets, presentations need to be saved in their own specific format, and they become “black boxes”: there’s not much we know about them, other than a short title. There is an overhead in opening every one of them, they need to be virus-checked, then “stitched” together to support the “flow-thinking” I was referring to earlier.
Those boundaries are stretched on the web: a document is no longer a file of a specific type, generated by a specific application: it’s a logical unit, defined by context, which weaves together content created by several applications.

Zoho’s Notebook is an experimental application that allows us to create, merge and store information the way we think, no matter whether it involves writing text, drawing charts, shapes, crunching numbers or recording/playing videos. Experimental in the sense that we don’t know how it will be used. In fact I don’t know what the future web worker productivity / collaboration tools will look like, but I suspect they will have elements of Notebook – multi-format, multi-media – and wikis – user-created structure, everything linked to everything – merged together.

Files, formats become irrelevant: there is only one format, and it’s the Web, defined by URL’s.

Additional reading:

Update (11/13/07): Read I Hate Files on Collaboration Loop. (via Stewart Mader)