Deep Dive: Zoho Office Suite

Zoho has been on my favourite companies list for a while now. This is a long promised deep dive into its popular online productivity tool set, called Zoho Office Suite.

Zoho is a product from a Chennai-based company, AdventNet, whose other LoB is software services. The Zoho Office Suite has a range of products, from an online document creator (Zoho Writer) to a CRM Solution (Zoho CRM).
The products are targeted towards small businesses and individual users - a segment thats rising in number. Zoho now has over 300,000 registered users, (Compare: Twitter has 200,000 registered users) and this number is increasing at a tremendous rate (Twitter's growing faster, of course).

Whats really commendable is that Zoho's got there frugally.They operate with a "We do not want any Venture Capital" mentality - which translates thus

1. All the development happens out of Chennai (quite expected)
2. Most of the Marketing happens out of Chennai (really cool, when your primary market is the US)
3. Very focused Promotions (Ads on some A-list bloggers, sponsoring key conferences, blogger evangelism)
4. Virtually no sales organization

This is why they can give away some products for free :), for individuals.

I Like
I've used Zoho Writer (the word processor), Show (online presentation tool), Sheet (online spreadsheet) quite extensively. Featurewise, they do pack a lot of punch into the tools, and you can see some really smart AJAX at work. Like the drawing tools, for instance. Drag and Drop, Rotate, selecting a region full of drawing - all these are very neatly done. Not as full featured as MS Word or Open Office, but it is quite enough for "normal" usage. The fact that you can share & collaborate on the documents more than makes up for it. The right comparison to make is between Zoho and Google Docs and Spreadsheets. Featurewise they are neck to neck, but the Google brand drives more users its way.

You must try out Zoho Creator. Its an online application creator. Means, you can have a simple UI+DB kind of application created within minutes (Did someone say MS Access? Nyaah!). Say you want your own expense tracker or maintain a record of who's borrowed your books, Zoho Creator is the thing for you. It also has a built in workflow engine. Thats a power pack!

Zoho Notebook will remind you of MS One Note. Doesn't matter. Few people know about OneNote. Notebook is a great freeform scrapbook tool that helps you collect your pieces of research, take notes in a meeting, doodle -- do whatever you do with a physical notebook. Whats more, there's a Firefox plugin for Notebook. Lovely. Now you can take notes as you browse -- copy paste from a website and it will paste the URL too. How many of us need that? (I do, for sure.)

Zoho was the first Office 2.0 vendor to open up its APIs to its users. The way they categorized their APIs makes complete business sense, and I think is a lesson for us Software Architects & Designers: They have one API set to access the Data alone, and one set to access the editor services. Neat.

Zoho was also one of the first apps to integrate with Facebook, and was recently in TechCrunch's list of 10 Favourite Facebook Apps. I like these guys. They really have their eyes and ears open. Imagine the 20-somethings collaborating on their term papers within FaceBook.

I Want

• I wish they were more keyboard shortcuts. These aren't tough to do. Users are used to Ctrl+C, Ctrl+V and other common shortcuts. It makes adoption so much easier.
• There are other features that require some loose ends to be tied up. (Why can't I change font size if I have clicked on a text area? Why do I have to explicitly select some text? Why can't I share my Slide Notes as well?)
• Zoho should market Show (the presentation tool) more agressively. There isnt a similar offering from Google, nor is there any clear leader in that space. Show could use better drawing capabilities, more slide layouts or templates. More third-party integration, in true Web 2.0 style. For example, I would like to share my Zoho presentations on SlideShare. Co-brand if you will, but allow the cross-pollination.
• Talking of integration, I'd like to see some amongst the different tools. For example: Zoho Chat integrated with Writer, Show and Sheet. That would be one productivity boost to people collaborating on a document. Another would be to integrate Notebook into Writer. You would imagine that the pieces of collected information within a notebook do get into more formal & structured documents. The users should be able to drag n drop or cut n paste from Notebook into Writer.
• Better graphics. Really. Most icons and images look old fashioned. For a consumer toolset like Zoho, the snazziness of the user interface is critical (Only SysAdmins don't care what the icons look like). Specially if you are going to compete with Google, 37Signals and the like, you have to provide a sleek looking user interface.
• Be a Salesforce + Google for SMBs. I mean, Zoho could create smart stacks of tools (packages, if you like) for business users - Office + Wiki + IM + CRM. Thats a very compelling offering, and no one in the market has it yet.

Zoho also has a Chat tool, Wiki, Meeting Organizer, Project Management and CRM tool, but I really haven't used those enough to talk about them in detail. Overall, a great product suite, something I would recommend you go play around with. Most of these are free for individual use. I'd love to know what you think.

At Code Camp, San Diego

Got bitten by the BarCamp bug again. I spent the last weekend at the Rock and Roll Code Camp at San Diego. This was one unconference that covered a lot of MS technologies. I got my fill of Silverlight, CardSpace, and some refresher/updates on WCF and WPF. I also saw an good demo of TeamCity. This is a build management tool (quite comprehensive) from Jetbrains, the same guys who make Idea, my favorite Java IDE.

My presentation on "The Ten Commandments for an Agile Developer", was based on a post I wrote earlier. My slides:





This was one unconference that made the speakers feel extra special. A speakers' room, bags and t-shirts as audience giveways, and even a speakers badge! I'm saving mine :), I've never seen it in an unconference before.

At WikiCamp

Unconferences are bad for my body clock. I woke up early - on a Sunday, that too - to catch a flight to Chennai for the WikiCamp. When I reached Tidel Park (the venue), Jimmy Wales had started his talk on wikipedia, wikia. He clarified to all of us that Wikipedia was not running out of money as was reported. He'd meant that they had 4 months of money in the bank, and only if they didn't receive a cent in donations for 4 months running (which is highly unlikely) they would be in a crisis.

I met with some of the key Indian contributors to Wikipedia

• Bhadani, the Grand Old Indian of Wikipedia, is No. 45 in the list of worldwide contributors. This banker from Pondicherry humbles all of us.
• Ganesh K (is ganesh a bot or a human?),
• Sundar, the guy behind the Tamil wikipedia, and an admin on Wikipedia.
• Arun R and Atul Chitnis, contributors .

I spoke in the afternoon. My slides:



Atul Chitnis spoke about how to use a wiki as a website, using http://foss.in as an example. Very cool. Until then I didn't know that foss.in was a wiki site. Some clever scripting done.

In the afternoon, I moderated a BoF (Birds of a Feather) session that was hitherto unplanned. Hey, its an unconference, so all this works. We went through multiple rounds of reorganizing sessions till we had something that was agreeable to all. While we were doing it, we were the fancy of many a photographer.

Photo courtesy: Siddhi

So, back to the BoF. We got all the guys I mentioned above plus Jimmy Wales on a panel, and shot questions at them.

Photo Courtesy: Arvind

Ashwin was liveblogging the BoF until (he and) his laptop ran out of battery. There were some guys who were doing a documentary on wikis, and they captured the whole discussion. I'll link to them as soon as I can get their info.

Moot points

1. Kiruba was formally dressed (he had to, he was the organizer)
2. Someone actually asked Jimmy Wales "So, when is Wikipedia going to list on NASDAQ?". Jimmy had the patience and grace to answer it. (No, I'm not going into the lengthy explanation here.)
3. Atul Chitnis got pelted with squeeze balls for exceeding his talk-time to provide the media a "story" (read his comment below). Geeks have bad aim -- only 2 of them hit their target, and Atul is hard to miss. No wonder software projects have so many bugs.
4. Red Bull was one of the sponsors, so we all had wings in the afternoon
5. Chennai was cooler than Bangalore that day.
   

More photos from Arun and Vinod. Search flickr for "wikicamp" to get the whole lot.

More coverage on this event in the Blogosphere (comment or contact me to add your link here)
Arvind
Ashwin
Prathul
Himanshu

Veni, Vedi, Wiki(Camp)

The first-of-its-kind-in-India gathering of Wiki-people is happening in Tidel Park, Chennai on 25th February. If you like/use/want to know about Wikis, then be sure to attend WikiCamp. From the list of topics I see, its all about the guts, the gashes, the gore and glory of using Wikis.

Jimmy Wales, the founder of Wikipedia, is going to be there. It is an unconference, so speak up and participate. Let me know if anyone of you reading this is also going to be there, will be glad to catch up. See you on Sunday.

If you cannot make it for some reason, you can come back here and read about it for sure.

How-to: Create a dual boot laptop with Ubuntu and Windows XP

A few months ago, I configured my laptop to dual boot into Windows and Ubuntu. This post is dedicated to spreading the Ubuntu love :), and comes at the advice of a friend.

System Configuration
My laptop is a Dell Latitude D620, and came pre-installed with Windows XP Professional (+SP2). I also had a Ubuntu 6.10 CD (Edgy Eft) (I'd previously ordered it). You can alternately download it and burn an ISO. Note: Ubuntu comes with GNOME desktop, if you want KDE, you should download kubuntu.

Create the partitions
Mine was a fresh Windows install (the laptop was new), but if your's isn't, you should run defrag to free up any disk space before creating any partitions.

Using the Windows XP administration tool, I created 4 (roughly equal) partitions on my 80GB HDD: 1 for the Windows OS install, 2 NTFS partitions for my data and Windows programs, and 1 "blank" (unallocated) partition, for Ubuntu.

Install Ubuntu
First, I changed my BIOS boot sequence to boot from the CD drive before the HDD. Then inserted the Ubuntu CD, and booted into Ubuntu. I chose the Install Ubuntu option, and followed the steps in the wizard. At some point, the installation prompted me to create my partitions. I chose to "Manually edit partition table" and found my 4 partitions listed there.
I left the windows partitions as is - they show up as as sda* (*=1,2,3 depending on how many Windows partitions are there). Of the unallocated space, I created two partitions.
1. Linux swap, of 2GB (rule of thumb says that your swap partition should be about twice your RAM)
2. Linux (OS) partition, of all the remaining space.

Note: A lot of people forget to create the swap partition.

Almost done, just Reboot
I just continued and completed the installation process, removed the CD and rebooted, and I was ready-to-go. GRUB installed automatically, and figured out its config based on the partitions. It made Linux the default boot partition, which suited me fine. You can always change the GRUB configuration if you want to change the order.

I configured my network connections, including wireless connections using the network configuration utility, and it all worked fine. Amen.

Troubleshooting
If what I described doesn't happen to you :), this is a good place to look for help. In fact, I read the whole article before I dual boot-ed my laptop just for some perspective.

An Ode to Extreme Programming (XP)

For those who admire XP (eXtreme Programming) or are intrigued by it, here's a music video from a team who seems to have done it - and lived to tell the tale. Its a wonderful way to drive messaging within a group or company.

If you sift out the grammatical disruptiveness of the translation, you will realize that the latter part of the song is quite profound. Life is all about improving yourself, breaking out of self-imposed barriers for a better tomorrow.




Simple and inspiring. This song's been playing in my head all day long.

At Bangalore Barcamp

I spent the better part of my weekend at the barcamp in Bangalore, held at the ThoughtWorks office. Day 1 had about 200 people. I haven't woken up this early on a Saturday morning in a long time, but I had to get there to book my speaker slot. Mine was the first presentation for the morning, on Web 2.0 Business models (or, where's the money, honey?). I was flattered when I saw the room full of people, and even more so when the organizers decided to move me (and my audience) into a bigger room to make place for everyone who wanted to attend. I had a great audience, so there was some discussion around whether online advertising is a really sustainable revenue model, what value propositions would really work, and whether we are looking at a Bubble 2.0 in the making.

My slideshow




Me presenting (Photo Courtesy: Arun)



Day 2 had lesser people, the "more serious crowd", according to someone. There were more informal gatherings, people hacking at something, blogging, podcasting, everyone airing their opinions. This is what you get if you get some geeks together on a weekend and give them enough food to eat.

Some interesting sessions I attended

• Jon Boutelle's talk on building scalable web applications with ruby and s3
• Marco's talk on Agile Software Project Management
• Kiruba's talk on Proto.in
• Card walls and Dancing by Deven Tolia
• Building Ajax web applications using GWT
• YourTube: Create your own video sharing site using OSS by Pradeep (motu)

More shared media:

Slides for (some) sessions here and here.

The flickr photo pool here.

One problem I commonly face at events is getting oversized T-shirts. I have a size L. Anyone who wants to trade a size M for a size L please let me know :)

A couple of sessions I attended deserve separate posts, those are coming up in a bit.

Busy Weekends Ahead: Foss.in and Bangalore Barcamp

Two very interesting events coming up in the next two weeks (weekends, really). Foss.in and Bangalore Barcamp.

For the uninitiated, Foss.in is a gathering (literally - there are scores of people) of people interested and/or associated with Free and Open Source Software in India. It is happening this week: 24-26 November. I went there last year - thats where I got hooked onto Ruby on Rails. Let me see what bites me this year. There's an Andrew Cowie session, that I will attend for sure. Be sure to register if you are interested.

The Barcamp is happening on 2-3 Dec, look here for more details. Barcamp is strictly for noisy, opinionated geeks. All participants, no attendees, they say. Piece of trivia: The name Barcamp came up as a response to O' Reilly's annual, by invitation meet called FooCamp. The House of Lords and the House of Commons, if you will. Pass the word around for the commoners to meet, and ask them to register here.

Another piece of trivia: foobar, acme corp are called Metasyntactic Variables. Wow, I didnt know it had a name. Think of all the people I could have confused via my design document or spec.

@ 95th percentile of Nerdiness

I just took this fun test that calculates how nerdy I am, compared to the others who took the test. Well, turns out that I hit 95th percentile. Just because I know my computer's IP address, know some chemistry, have a messy room and can recognize Isaac Newton. I admit I am a bit of a geek, but 95th percentile is a little unbelieveable. I've deduced that not enough people are taking this test (for the statistics buffs: sample size not large enough), so a little propaganda wouldn't hurt. I'll re-take the test 3 months later and see if I get the same scores. I got a cute little badge to show off, though. Here it is.

I'm going to put it up as part of my profile and see if that scares people away ;). Thanks to ashwin for pointing me to this one.

The Ten commandments for an Agile Developer

I'm not playing God, just being Moses.

I'm putting down things that I feel are important for any developer in an Agile project. For me, any project that involves iterative planning and continuous integration is agile enough to begin with. One can see enormous benefits just by following principles like feature-driven development (FDD) and test- driven development (TDD). You dont have to go from zero to XP or Scrum to be agile. In fact, I think agility is a continuum and each project needs to find its sweet spot on it.

A lot is said and written about the need for self-managed development teams in an agile project. I interpret "self-managed" in a psychological way - I think it is a frame of mind that you need to be in, day in and day out, throughout the project. It requires rigour and a sense of self discipline. This may raise the hackles of developers who think discipline chokes innovation, and it takes out the "cool"-ness out of programming; I'll turn the argument on its head and say that to be truly innovative, you have to be disciplined about your fundamentals.

The rest of this article is about those ground rules. I'm not advocating any Agile process over another - follow whatever processes your project has decided to. This list is a daily to-do list. Over time, these things will be next to breathing for you as a developer (Do you realize how many times you hit Ctrl-S in 5 minutes?). They're really so simple, I should have called this the Zen way of agile development. I've seen its benefits, and more importantly, seen the mayhem caused when these rules arent strictly followed.

Write tests before code. Use a testing framework - there's one available for your language. Writing tests first ensures that you write just enough for the functionality of your program to work, nothing more. We often spend a lot of time writing that one extra method with that one extra parameter just in case you need to use it tomorrow. None of this happens if you first write a unit test before actually writing the code. How many tests should you write? The minimum required to make the code feature complete and secure. Use test suites liberally to create user scenarios involving a set of features. Execute these in your coffee break (Heck, why does the computer need a break?!).

Build from source on your local machine. Every day, before you start work, take the build from the build server (you should have one, btw). Treat every checkin as sacred, especially when fixing a bug. Gone is the era when you could say "it works on my machine". They dont even joke about it these days. Before you checkin, make sure you run the build scripts locally. If it takes too long to make a build, it is the build process that needs fixing (good ruse to ask your manager for a better machine ;) ).

Be lazy (automate everything you can). I mean, thats what the computer is supposed to do, right? Take the repetitiveness out of a job. So, please put the computer to work at the True Purpose for which it was invented. You can build, deploy, test, report bugs, clean-up just by pressing some shortcut key combination. There are plenty of tools available to do this - lots of them are open source too, so there's no limit to how lazy you can afford to get. I'm not going to go into details of how to automate a project (too long, and out of scope for this article), but here's an excellent book that tells you how to: Pragmatic Project Automation.

A feature in the (daily) build is worth two on the (drawing) board. This is about planning how to write your code. Rather than having "database days", where you do all your table design and "UI days" to layout all your screens, have "Create User days" where you write just that one feature - end to end. At the end of the "Create User days", someone who installs the build should be able to actually, create a user in the way your product spec says it should.
Not only is this more gratifying for you as a developer, the whole product starts taking shape much earlier, allowing for mid course changes that may come along because of end user requests, market changes, and... innovation.

Write meaningful comments. If your product is worth something, there'll be modifications to the codebase for years to come. Be polite, and write a line or two about how your method implements the feature. Rather than say /* this method authenticates the user */ (that should be clear from the way you name the method), say /* this method checks the user credentials against the LDAP server. It assumes that the LDAP connection properties are specified in a file called LDAPProperties.xml*/ It takes less than a minute to type that out, and everyone who reads your code - whether to enhance it or to use an API will bless you for it.

Honour change. Change == Good for the product. I deliberately didnt say "accept change". I think we all are mature enough not to crib when requirements change, but we still think of change as something that throws our well made plans awry. In an agile process, assume that change will happen no matter what you do. Plans will change with each iteration, features will change as users start using them, code will change as you refactor and/or integrate. In fact, it is this ability to respond to change that is one of the core tenet in the Agile Manifesto.

Love thy neighbour's code. Code reviews are one of the best software development practices I've seen. A code review can catch a lot of "thingies" early that would otherwise grow up to be "bugs". Especially in a time crunch, we tend to make some easily catchable and fixable errors (we're all so human). Loving your neighbour's code also means understanding it enough to be able to fix a bug in it. Get yourself into the habit of doing code reviews and getting code reviews done. Like debugging, it is a skill that is constantly honed with experience.

Communicate, mate! Key sucess mantra for many things in life - whether it is marriage, a football match or an agile project. If you changed a piece of code in the build, tell the rest. If you are stuck with an algorithm, ask for help. If you think you arent going to meet your deadline, say so upfront. If you found a tool that would save everyone's time, communicate. If you have the next big feature idea for the product, communicate. I think the first thing a project manager should do in an agile project is to setup a communication platform. This could be a wiki, a mailing list, a list of phone numbers, a notice board - or all of them. It is super important that everyone (including the customer) is aware of the status of the project on a daily basis. Use all the
tools you can to make communication better.

Refactor...when you need to. Developers love to refactor - there's always a better way to write that class. Refactoring code should be a part of every project because of the iterative nature in which the code was developed in the first place. Your only objective in the first iteration is to get the feature to work. In the next, you can revisit the same code (or identify common pieces of code) and refactor it into a design pattern, optimize the resources it
uses and so on. (A good refactoring catalog is available online, most of it is from Martin Fowler's book.)How much to refactor really depends on your priorities at a given time. I think it must be done once, and once is good enough.

Stay with the standards. Use standard ways of doing things wherever possible - tools, coding conventions, patterns. Remember, innovation comes at the next level - the level of your product. Follow a coding convention in the project. I dont care about line breaks and where you place your curly braces and whether it is iCount or i or count, but I do care about what you name your class, what package structure you use and where you place your resource files. Dont re-invent the wheel. Scout the open source world for solutions to some common problems, implementation of design patterns (warning: check the licensing model of any external software you use before you use it). Its okay to make an exception if you are consciously doing so.

Well, this is it, my torchlight on the path of coding Nirvana. I told you it would be simple. Amen.