post

JotSpot Born Again as Google Sites, the Wiki-less Wiki.

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 3smile_tongue)

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. smile_sad

Summary: Nice to have Jot back (even if we did not get GSpot.smile_embaressed ) 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.

post

EchoSign 3.0 Released – the Complexity Dilemma

Echosign, the leading Web-based document e-signature / distribution / management provider has just released version 3.0, with major updates.

The UI got significantly revamped, there are new subscription levels to manage up to thousands of documents, new forms were introduced, but the most important change per CEO Jason Lemkin is the introduction of complex workflows – a definite need for large corporations:

Hundreds of new workflow options have been added to EchoSign. The first group has been automatically added to the Account tab for Team and Enterprise customers. Want to sign ‘packs’ of documents? No problem. Routed signed copies of every contract in your company to a global e-mail address? Just tell us where. Collect title, company name? Whatever you want. Select who can — and cannot — sign in your company? Done, with one click.

And for the most complex workflows, EchoSign now offers a novel “Signature Workflow Language” where Enterprise customers can craft their own custom document worfklows. Want (A) your customer to fax sign your contract, (B) auto cc your sales rep, (C) autoroute to legal for electronic counter-signing, (D) but only by certain authorized signers, and then (E) have signed copies automatically sent back to the (F) customer, (G) legal, (H) sales ops, (I) accounting and (J) the sales rep? Now, no problem. Contact your account manager for access here and configuring workflow options beyond those you can set yourself on the Account tab.”

Let’s stop for a minute here: complexity is typically the last thing a software CEO would point out in his announcement, but Jason handles it with class and humor, for good reason. The illustration he picked (how did he find this gem?) shows a decidedly simple “process” made awfully complex by introducing far too many steps and “technology” prone to failure. EchoSign, on the other hand has earned a reputation of simplifying processes originally made complex by people, rules and lack of technology. I trust Jason and team – they will likely manage to reduce complexity, even while embracing it.

By the way, EchoSign is not only for large corporations, it’s for businesses of any size. I’m a one-person shop, and used it a few times. Even now as I type this post in Zoho Writer, I could just click on DigiSign (see highlight below) and have it routed to Jason to sign off. Not that I need to, after all, that would be …complexity. smile_eyeroll

post

JotSpot…Gspot … Google Wiki

So they figured Gspot would be too risky a name for Google’s JotSpotTongue out, 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? Thinking

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

post

Koral Acquired by Salesforce.com

Wow, this was fast. I met Koral CEO Mark Suster some time in November, when he gave me a demo of his then pre-beta Content Collaboration system. I instantly liked it, largely for it’s simplicity – hence the title of my review: Koral – Collaborative Content Management without the Hassle of “Management”.

Apparently I was not the only one who liked the productsmile_regular. Koral is no more. Salesforce.com has acquired it, launching its new service … hm, SalesforceContent, or Apex Content, or Salesforce ContentExchange – apparently there is a bit confusion over the name, but we’ll know it tomorrow for sure. The logo is from the (former) Koral site:

Update: Clarification from CEO Mark Suster:

“The overall initiative is called Salesforce Content. That consists of the Apex Content platform where developers will be able to build their own content based applications and Salesforce ContentExchange, which is a Web 2.0 application for managing corporate content that sits on top of this platform.
Basically, we took an integrated product, Koral, and split it out into a platform piece for developers and an application piece ready to sell to customers.

TechCrunch, Read/WriteWeb and ZDNet has all the details. Congratulations, Mark, Tim and the rest of the team!

post

Socialtext 2.0: Usability vs. Usefulness

Socialtext recently announced version 2.0 of it’s enterprise wiki. The two big news are a completely revamped user interface, aiming to make Socialtext a lot easier to use, and the publication of the REST APIs to support integration and mashup development. For more information watch this screencast by CEO Ross Mayfield, and see this review at TechCrunch.

The revamped UI is a huge deal, and it’s been long overdue. For some background check out Jeff Nolan on the “UI sucks” issue. One may agree or disagree, but as long as there are reviews like this:

I have tried on at least four separate occasions to use and like Socialtext but I can’t…I just can’t use this application.” – well, you definitely know you have a problem.

Interestingly enough Socialtext, the company realizes how important ease of use is, and they are contributing resources to bringing WYSIWYG Wikiwyg editing to Wikipedia. But let’s focus on Socialtext, the product for now.

The new UI is aesthetically pleasing, has nice colors (somewhat reminds me of JotSpot’s blue), but most importantly it’s clean, simple, in short it passes the “blink test“.

thumbs_up The Home Page is of key importance in the new release: a Dashboard gives users a quick glance of a shared whiteboard, personal notepad, customizable watchlist, a listing of what’s new (i.e. recently changed pages) as well as the users active workspaces (i.e. wikis). The Home page has become the central place where you can access all extended features, like a listing of all pages, files, tags, or change settings. You can start adding information using the New Page button, which, just like the Edit and Comment buttons on all subsequent pages clearly stands out, again, passing the “blink test”. I love the new colored side-boxes for tags, inbound links and attachments.

I can’t emphasize enough how important inbound links (backlinks in the previous releases) are – a wiki is all about associating pieces of information with each other, and the inbound link shows you where the information on the current page is used elsewhere. In wiki systems without this feature on would manually have to create them, a task most often forgotten (as it does not fit the natural flow of creating new pages), thus those systems don’t offer the full potential of a wiki. I can’t for the life of me understand why inbound links haven’t yet made it into the standard feature-set in JotSpot 2.0, when it’s been long (for more than a year) available as a downloadable plugin on the Jot Development wiki – but how many users search the development wiki? In contrast, Atlassian’s Confluence has long supported incoming links.

We know from Ross and others that in creating the new design the primary objective was to increase ease of use, and in doing so Socialtext conducted customer usability studies. The number one customer request was to reduce clutter, which was quite abundant in Socialtext 1.x. They certainly achieved this objective – perhaps too much. Playing around with the beta I run into trouble trying to create a page from an already existing page – I simply did not find the New Page button. “This is something too obvious to be a bug”, I thought, and Ross proved me right: It’s all part of “getting rid of the clutter” and doing what customers had requested.

Socialtext believes this helps eliminate a frequent problem: the existence of orphan pages in wikis. (Orphan pages are valid, existing pages that no inbound hyperlinks point to; thus it’s difficult to find them, other than by searching or listing all pages).

I am not sure binding users to the Home page is a good idea (it’s not just the “new page”button, all other extended features/tools are anchored here). To me the natural flow is typically top-down: one would create a subpage from the parent where the summary level thought flows, thus creating a parent-child relationship. In a business wiki, where after a while you’ll end up having a large number of pages, the further away you are from the right place (the parent), the more likely you will forget to create a link to the new page, thus may end up with a proliferation of orphan pages.

Interestingly enough, the most elegant solution to the orphan problem comes from two products at the opposite end of the spectrum: Wetpaint, the friendliest consumer/community focused wiki (actually a blend of wiki-forum-blog features) and Atlassian’s Confluence, the market-leading enterprise wiki. Other than the standard user-created links within the flow of text, these products also offer an automatic index of subpages along with each page. JotSpot‘s 2.0 release offers a less foolproof but reasonable solution: when you create a page by using the “new page” button, technically it becomes an orphan, however when you hit “save”, you’ll find yourself at the parent level where a quick alert pops up proposing to create a link to the child page you just set up.

There’s a fool-proof way of creating new pages that can’t become orphans: create a link before the page, and forget the “new page” button. While typing, wherever you want to branch out to a new page, insert a link to the page about to be created, typically by highlighting text and using the “link” icon, or in JotSpot you have the option of simply typing a WikiWord (also referred to as CamelCase), it becomes a link automatically. This “trick” creates a shell, essentially a placeholder for your new page: you can add content later, but since it’s already linked to, it can’t become orphan. All the wikis I’ve talked about allow this method, but Wetpaint and Confluence don’t really need it, since they provide navigation based on the auto-index of child pages. (Update [2/17/07]: I’ve just discivered a perfect existing term for what I am trying to epxlain here: LinkAsYouThink.)

Back to Socialtext, perhaps there is more to the new design than the desire to create a very simple, clutter-free user experience: the underlying philosophical difference between hierarchical structures, parent-child data relationship vs. everything being flat (created at the home page ) and only associated through links embedded in page text. But hierarchy, structure are not necessarily evil; only pre-existing ones are.

smile_wink We tend to think in structures, need organizing principles – there is a reason why books have a table of contents. Wikis, as unstructured as they are in “virgin state” are a good tool to create structure – our own one. The assumption of a parent-child relationship mimics our usual workflow, and it does not impose a rigid structure, since through through cross-linking we can still have alternate structures, no matter where we create a page.

Perhaps that’s the fundamental difference between Socialtext and the other wikis I’ve mentioned – which would explain why it doesn’t have breadcrumbs (navigational line at the top): this standard feature of all the other three products (Confluence, Wetpaint, Jot) does not really fit in Socialtext’s flat world.

My other issue about with Socialtext 2.0: I really would have expected to see document versioning by now: when you upload an attachment (typically doc, ppt or xls file), Jot and Confluence shows the current version, indicating the most recent version number and the user who changed the document last. Click for details, and you get all previous versions and details. Confluence even allows you to label every instance of the attachment with a comment. Socialtext simply lists all documents with the same title (or not), not recognizing them as version of the same file.

smile_sad

Finally, a minor gripe: it would be nice to see threaded commenting, like Wetpaint and Confluence does, allowing users to enter comments to a page itself or to a previous comment. Socialtext, just like Jot, only has a flat list of comments.

Summing up, the new Socialtext 2.0 Beta is really good-looking, but in my view limits functionality for (perceived) ease of use. That said, it’s a beta, and Ross conformed repeatedly that they are seriously evaluating test user comments and it’s possible that the final 2.0 release will have a better solution for the edit/navigation/orphan problem.

fingerscrossed

Last, but not least, let’s revisit document versioning. It’s very-very important. In my “prior life” where as corporate VP I introduced a wiki-based intranet to the company, we used it for document management first, before exploring more of the native wiki functions. But here’s the catch: document versioning in wikis solves a very old problem, but solves it on the bases on yesterday’s (OK, today’s ) technology. Even with proper versioning one has to download documents, locally update them, then upload them back up to the wiki. The process is a lot easier using Office 2.0 applications, be it an editor, spreadsheet or presentation. There is no uploading/downloading, all updates happen online, if need be by multiple users at the same time, and instead of attaching them, one would simply link to, say a Zoho Sheet or Presentation from the wiki.

My ‘dream setup’ for corporate collaboration: a wiki with an integrated Office 2.0 Suite. The next step will be the wiki integration with ‘traditional’ , transactional enterprise systems – that’s a little further away (although … reading this, who knows?

smile_wink ) I hope to discuss many of these concepts with my readers next week in San Francisco, at the Office 2.0 Conference.

Update (9/5): For more insight read Socialtext 2 Design.

Update (11/1): Usability review on InfoSpaces.