Google Docs for Xanukah חנוכה

I am reading that Dave Girouard, the president of Google’s enterprise division, besides admitting that Google Docs is not mature enough to completely replace Microsoft Office, (and therefore, in my presumption, Open Office also) he says that within a year, we won't need Microsoft Office anymore if we used Google Docs.

I would like to believe that will come true. All I want for Xmas/Xanukah is my Google Docs, my Google Docs.

I am writing Xanukah חנוכה instead of the accepted Chanukah to emphasize that ח is pronounced Xa, rather than Cha, like you were swallowing while pronouncing the Spanish X in Mexico (mehiko). Like the artist's surname van Gogh, where most pronounce it van goe/gog/gof, though varn xox should be closer to what he had preferred.

I had been writing web applications to broadcast enterprise information through tables and charts for many years.

I have an empathic ear to Girouard because I have seen the cost of Office licensing being over-frequently wasted by managers, clerks, secretaries and even fellow-programmers who would use Excel merely for writing notes. Worse scenarios are when they ask for web apps to create Excel versions of the dynamically generated web pages, not because they could or would write VB script to further enhance the charts but because they had been too used to looking at reports through Excel. The exception to my amazement at this phenomenon, are the few who actually used Excel or Presentation for the purpose of creating management presentations or for arithmetic/mathematical purposes.

But then, I want to be cautious with my enthusiasm because currently using Google Docs is a rather inconvenient affair.

Google has a love affair with tags and uses tags to replace folders. Google seems to project a very strong opinion about their opinionated opinion about the advantage of tags over folders and seems to work silently and saliently to educate users to transform our folder-based perspective to a tag-based life-style.

I love folders and I just don't know how to further let Google know it so that they would stop shoving their taginization down my folderated throat. As evidenced by gmail. I am telling myself that if I find the time, I would write Java GAE interface to gmail that transforms the tags in my email to folders. Instead of counting sheep to sleep, I am thinking of the proper tag convention that would register a hierarchical folder tree for that yet-to-be-written application.

According to my topological perception, a folder structure is a subset of tag structure. Depending on implementation preference, one could be the topological inversion of the other. Google's current single dimensional tag architecture means that they could only properly simulate one level of folders.

In Google Docs, my feeling is that they are using tags to masquerade as folders. Using tags to masquerade as folders has the advantage of placing an item in more than one folder simply because you could apply multiple tags to an item. But, if I designed a way to tag a tag, that is placing a tag as a member of another tag, I could have a hierarchy of tags/folders.

So, my wish for Xanukah 2010 is Google Docs with proper folder behaviour, since currently, when you attempt to create a new document at the current folder, the new document gets created at the root. Then you would have to move the document back to where you actually wanted it created.

Next, the current GData API for a Java application to access documents in Google Docs should be made less clunky. Using GData API, you could create tables in a spreadsheet. The incovenience I face is that I am unable (either due to my stupidity or GData short-comings) to create tables that expand dynamically. Once created, it seems that I cannot change the sizes of the tables except by deleting the table. Or if I did try to respecify the size of the table, I get thrown a horrigible exception. On the whole, GData API's approach to Google Docs needs to be more programmer friendly. Without supporting web programmers like me, who could automate manipulation of Excel tables, who now need a friendlier API to manipulate Google Docs, Google is overlooking the influence of web programmers who helped sustain popularity of Microsoft Office.

Last but not the exhaustive last of the list, I have a lofty perception that there are no organisational silos in Google and yet Google Sites refuse to work properly with Google Docs. Google Sites pages allow me to embed Google Docs documents. If I had ten worksheets in a spreadsheet, frequently I only wish to publish just, perhaps, six of them because the other four are unintelligible mess of intermediate references I do not wish the reader of a report to see. But, Google Sites would not allow me to publish the worksheets selectively.

Therefore, another of my 2010 Xanukah wish is that the Google Sites team stop barricading themselves but work closely with the Google Docs team.

Mr Girouard should take note that, not only does Google Docs need to mature, the relationship between his Google Docs team and his Google Sites team and his Google App Engine team needs to mature and be strengthened. Otherwise, he would scantly find the invaluable support from web programmers to make his vision come true.