Three weeks ago I speculated that JotSpot, the user-friendly wiki swallowed by Google a year and a half ago would soon come out of hibernation, and Voila! here it is, rebranded as Google Sites. It is the first service only available as part of Google Apps (including the free version), although I had some difficulty accessing it. Under “Manage this Domain” I could add “Sites” as a new service, but it did not show up on my account as an accessible application. When I typed sites.google.com it wanted me to sign up for Google Apps even though I was already logged in to my account. Of course trying to do so resulted in the error message:

Google Apps for zoliblog.com has already been registered by your domain administrator. Please contact your admin directly to get access to Google Apps services.

Catch 22. But there’s a solution: just type the direct URL (sites.google.com/a/yourdomain.com as default, or customize it to your liking) and you can get into Sites. I’m sure Google will soon add it to the Apps menu. (Sidenote: my old JotSpot account is still alive at name.jot.com).

Google no longer calls this a wiki, which I think is a good move. I previously wrote:

Wikis have arrived when …you don’t even have to know what they are to use one. You don’t have to know you’re using a wiki, just happily type away, creating shareable content on the Web.

I was discussing Wetpaint, the user friendly, wiki-less wiki there, and I think it’s smart of Google to follow that pattern… more later, but first, under the hood it is still a wiki, so let’s examine some of the wiki basics.

The interface is familiar from good old JotSpot (as a sidenote, the old JotSpot accounts are still alive at name.jot.com). There’s a basic wysiwyg editor, the Edit button is large and visible, and so is the New Page button. Good old JotSpot had several more ways of creating new pages, which are gone - perhaps for the best:

• WikiWords or CamelCase: in old JotSpot anything you typed with embedded capitalization became a link to a page. As a relatively early wiki-user I liked it, as the easiest way to LinkAsYouThink. But in the Web 2.0 age we keep on bastardizing grammar writing EveryThingLikeThis, so more and more WikiWords had to be “unlinked”… too much confusion, especially for the new generation of mainstream users.
• Linking to a shell-page before it’s created. This was a useful feature, even if we eliminate camelcase, I could use the “Link” icon, and mark up text as a link to a new sub-page, to be filled with content later. Again, this supports flow-thinking, or LinkAsYouThink, which I regret is gone.
• The “New Page” button. This is the only remaining option in Google Sites, and I think the fact that it offers to pick a parent page (enforced hierarchy) is an improvement. No more orphan pages, yet relatively flexible hierarchy.

For those not too familiar with wiki terms, I discuss some of these concepts in more detail here: technically an article on SocialText 2.0, but I often make comparisons to JotSpot and Atlassian’s Confluence.

I’m glad to see Sites retained breadcrumbs for easier navigation, and they added sitemaps, a tree-style view of all your pages. This could be improved to allow for drag-and-drop style moving of the pages (changing the hierarchy), like Zoho Wiki does.

I’m surprised Sites still does not have inbound links: this is a critical feature for all wikis, whatever we call them. A wiki is all about associating pieces of information with each other, and the inbound link, also referred to as backlink shows you where the information on the current page is used elsewhere. The JotSpot tea half-recognized the importance of backlinks, as they were available as as a downloadable plugin on the Jot Development wiki, but never made it to the standard feature-set, and are apparently lost in the Google reincarnation, at least for now.

Attachment handling is as good as it was in the original JotSpot: it maintains previous versions, allows users to revert to earlier ones…etc. However, Google missed a huge chance here to by not offering to convert the attached documents to its own Google Docs style. This point takes us to the next level: stepping outside the boundaries of a standalone wiki and using it as a facility to pull together data created by other applications.

Last year I said after burying JotSpot for a year, Google can’t just release it as a wiki, instead:

…I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

• It could provide for much better document management than the current Docs &­ Spreadsheets UI.
• It overlaps with Page Creator, also with the simplified version found in Google Groups - in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
• Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

Well, what’s the score on that prediction? Google Sites is a better replacement for Page Creator, Google ditched the JotSpot “apps”, replacing them with their own ones - so far 2 scores out of 3. As for document management.. well, I’d say half a score, or less. (Hey, that’s 2.5 out of 3)

You can somewhat integrate Google Docs (which includes documents, spreadsheets and presentations) by embedding them into any Google Sites page. You have to enter the specific URL though - why not just select from a list? Furthermore, your Google docs or spreadsheets have to be first made public and you have to use the public URL to embed them into Sites. Here’s my test site, showing first an error message, then the actual embedded spreadsheet, after I made it public.

The embedded docs appear properly in the saved page, but I can’t click on it, not even in Edit mode to get to the source. In fact in Edit mode all I see is a graphical placeholder for the embedded doc.

How about sharing / collaboration? As expected, your Sites can be:

• private
• public
• shared with individual email id’s
• shared with everyone within your domain

…and you can set view or edit options for all those levels. However, Google missed a big chance again. As a complete coincidence, it’s only yesterday that I raved about Zoho’s Group level sharing, half-announced in a fairly understated manner - hidden in a list of Zoho Writer enhancements. Well, Google already has a very good group facility: Google Groups, which started it’s life as a group discussion / forum system, but it gradually evolved into a decent collaboration platform. Once I have a “group” defined (i.e. the list of members), why doesn’t it become an entity I can share my wiki (sites) or docs with? When I invite users to share the wiki with, there’s an option to save the list as group, but I don’t know where it disappears, can not pull it up either within the wiki or gmail, or docs.

Finally there are gadgets, but if you read Dennis Howlett at ZDNet, gadgets might the feature you don’t want to touch with a ten-foot pole.

Summary: Nice to have Jot back (even if we did not get GSpot. ) Google now has a pretty good and easy web-page creator with some wiki features made user-friendly, and a half-hearted attempt at integrating the rest of the Apps empire using Sites. Perhaps they get it right in the next release.

Related posts: TechCrunch, eWeek, Ross Mayfield’s Weblog, Irregular Enterprise, Mashable!, InfoWorld, Between the Lines, Portals and KM, CNet, Webware, GigaOM, Web Worker Daily, Venture Chronicles, Insider Chatter, Learning and Technology, Solo Technology.

Tags: Collaboration, document management, flow, Google, google apps, google Groups, google sites, google wiki, gspot, Integration, Jotspot, Web Applications, wiki, zoho wiki

So they figured Gspot would be too risky a name for Google’s JotSpot, it’s now (almost) official: the new name will be Google Wiki.

JotSpot was (I assume still is) a good, user-friendly wiki, and if it comes back now, it took Google almost an entire year to release it after the acquisition. I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

• It could provide for much better document management than the current Docs &­ Spreadsheets UI.
• It overlaps with Page Creator, also with the simplified version found in Google Groups - in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
• Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

In fact there are so many opportunities to waive the wiki into Google’s current offerings, I can’t even imagine what it would look like… or, perhaps, are we going to see a standalone wiki?

Related posts: Google Operating System, Google Blogoscoped, Read/WriteWeb, TechCrunch, Download Squad , Mashable!, Insider Chatter, Ben Barren, Squash, Parislemon.

Tags: Collaboration, document management, flow, Google, google wiki, gspot, Integration, Jotspot, Web Applications, wiki

(Update)
I have to take issue with Paul Gillin’s approach as he discusses whether SMB’s are better off with SaaS or Open Source Applications. If we equate Open Source to downloadable, on-premise installed software, I have no doubt, and have stated it before that the only good answer is SaaS. But, hold on, a few minutes later we’ll see these two options may not be mutually exclusive for long.

Paul analyzes several criteria:

• cost
• speed of deployment
• customization
• reliability
• data ownership
• vendor viability

These are all issues well-discussed on the web, and although Paul does not explicitly say, my reading is that he also leans towards the SaaS conclusion. The problem is that this criteria-by-criteria approach works well with a typical (mid-size) company where some level of IT expertise is present. Small Business America is very different from the web-savy geeky software startups; the majority are more traditional businesses with no CIO, IT department, in fact often without any IT support whatsoever. While the two main obstacles SMB’s face with any on-premise implementation are cost and (lack of) IT expertise, you can’t just translate the latter into cost – i.e. the cost of hiring full-time IT support. The opportunity cost of Management venturing into IT hiring and project decisions instead of focusing on their primary business makes this an impractical approach, leaving us with only one choice: SaaS.

Another issue not discussed in the article is integration. Open Source or SaaS, getting several packages work together requires IT and business process expertise, which typically means hiring expensive consultants. Therefore, I would go one step further: not only SaaS is the best choice for most SMB’s but they should seek to minimize the number of providers, i.e. the best choice is to use integrated All-In-One solutions.

The current undisputed leader in this field is NetSuite, but as they follow Salesforce.com’s footsteps and move upstream chasing midsize businesses, they leave an opening for up-and-coming challenger 24SevenOffice, which focuses solely on SMB’s, and covers a wider range of business functionality than the incumbent.

This is the situation today. Now, let’s revisit the original question: SaaS or Open Source? A tiny startup named SQLFusion is working on making that question obsolete. The dilemma with Open Source: a lot of good applications are available, but they are written by geeks for geeks… you really have to be quite knowledgeable to download and implement them. Example: at one of the startups I am advising I use SugarCRM over the internet. Starting to use it was a no-brainer, but when I looked at the prerequisites and the process of installing it myself, my head started spinning. No way, this is not for me! Open Source Fusion, which I hear is within days of opening for a limited beta will bridge the gap between availability and usability of Open Source Programs, by offering such apps to be used over the Internet. In true On-Demand fashion, maintenance, upgrades all happen in the background, one can start using the programs without implementing them. So it will no longer be SaaS or Open Source, but SaaS and Open Source.

The first incarnation of Open Source Fusion will provide access to individual applications, still leaving the integration dilemma for SMB’s, but the technology under the hood enables the company to later offer an integration layer between the key applications it serves up.

So the future is Open Source Software as a Service. Hm, here’s an ugly acronym: OSSaaS (?)

Update (3/6). Releated posts:

• SaaSsy
• SaaS for SMBs

Update (5/23): Stefan over at The Small Business Blog discusses the issue; his company, WinWeb is expected to offer Open Source apps as a service soon.

Tags: 24sevenoffice, all-in-one, Consulting, Integration, netsuite, On-Demand, Open Source, Open Source Fusion, OSSaaS, SaaS, smb, sme, SQLFusion, SugarCRM