Actually we rediscovered it . I had looked at Liferay in August 2008, to establish a community for another company; however they decided, that they could not provide the resources to host an “active” community. Part of providing a community is the nurturing and feeding of the community by providing content on a “regular” basis and responding to comments.

From 100,000 feet, Liferay is essentially an open source version of SharePoint written in Java. Liferay embraces document collaboration, Web 2.0 and social collaboration. A Liferay portal provides one or more organizations with one or more communities. Each community and user has public and private pages. Users can be assigned roles within multiple organizations and communities. Liferay plugins, portlets, can be added to any page by any user based on their “scoped” role. Liferay themes and layouts can be established at the community level or applied to each page.

Liferay provides wiki and blogging editors that can be configured to support either the FCKeditor or TinyMCE. This allows users that are already familiar with other Social media tools to be immediately productive. One of our litmus tests for wiki and blog usability is: can a user “easily” learn to how create an attractive blog or wiki that is media and content rich without having to result to editing raw HTML? This should be possible without formal training. Yeah, I expect the user would read some documentation and view some training videos; however, since more and more users are using social media sites, they are looking for their corporate tools to resemble their other tools. The workflow in these tools should allow the user to work top-down as they are thinking. Although not perfect, we find that Liferay passes this test.

One of the disruptive behaviors of internet-based systems and web 2.0 is that corporate systems and vendor applications lag many internet applications in technological advances. This means that users are often waiting for the applications that they use at work to catch up with the ones they use personally.

Liferay allows the use of existing content or the dynamic upload of content while you are are writing. SharePoint 2007 only supports use of previously stored content while editing.

Okay, I know that you can open another browser window; upload some content; and then switch back to your wiki/blog window to complete the wiki or blog entry. However you cannot imagine how many users do not think of this or understand this. I been around long enough to realize that means that there is likely a disconnect between the user’s desired workflow and the product workflow.

The Liferay wiki and blog editors work equally as well with Internet Explorer,IE, and FireFox. SharePoint 2007 provides a more robust experience to IE users. With SharePoint, in my opinion, wiki and blog editing in FireFox feels like an “unwanted disease”. This is unfortunate. There are standard JavaScript libraries that abstract browser dependencies. There is simply no technical reason that SharePoint can’t provide a first class experience to most browsers. The Liferay content portlet can contain javascript, this allows easy integration with a plethora of other social media and web-based applications. Ironically, I placed my Windows Live status with a button into a Liferay content portlet and it behaves correctly. I could not do this with SharePoint. The SharePoint editors deleted the javascript code. The Liferay Wiki can be configured to support Creole or Camel-case wiki editing.

You know, SharePoint could learn a lot from Liferay.

• The WSS 3.0/SharePoint 2007 WYSIWYG editor can’t upload images, video, audio clips and can’t insert Flash files.
  The workaround requires so many mouse clicks and web page interactions, that users look at me like I have “3 heads” when I show it to them.
• Working with tables is difficult, at best
• Any customizations such as:
  • custom file browsers,
  • link management,
  • syntax aware code viewers,
  • and much more

  are difficult to implement

From a Wiki perspective

• Explicit syntax [[]]
• No free form image inserts
• No server side include of other topics.
  Need an easy way to include content from another site. In Foswiki/Twki the %{link} tag can be used
• No easy upload and insert of attachments
• No Easy way to insert links.
  Foswiki/TWiki support WikiWord/Camel Case.
• No tagging
• WYSIWYG support for tables is ugly. You must know the number of rows and columns in advance.
  Foswiki/TWiki support simple “|” character based table definitions and an editable table plugin
• No printable vew
• No export to PDF/Word
• Limited Alerts support.
  Email alerts say something changed and include the full text. However, this can not be customized to tell you what changed. You must login and see the history for that.
  Foswiki/Twiki support a highly customizable WebNotify
• No easy support for multiple top level webs.
  There is only one flat “Wiki Pages” page with list view, no hierarchical view or some sort of sitemap feature.Wikis are made up of Topics that are interlinked in the form of a graph. Hence a specific Tree or Hierarchy structure is not the right representation. However, there must be a way to find all top level topics, i.e. Topics that are not linked to by any other topics. These topics will include
  • the starting points
  • new topics that have been added but not yet organized.

  I could not find a way to do this with this with the SharePoint Wiki. Even a simple way to flag a page as “add this page” to “Quick Launch” would help.

• Not easy to provide a standard footer
  No apparent concept of templates

The “MS/SharePoint 2007″ update approach does not seem to fit into this “revolution”, either. The current approach requires direct access to the servers to install and activate extensions. With “Cloud Computing” and web hosting on the rise; the direct server access approach is not a good match. SharePoint needs something like a Plug-in central for SharePoint. Ideally, this could work on a site level and not require Central Administration be updated first. Another issue for remote management is that “by default” SharePoint Central Administration and SharePoint Sites must run on different tcp/ip ports. I’m sure that if I work real hard I can find a way to run them on the same port using “host-headers”. However, if I do, then will this really be supported or would the next next patch or upgrade break my sites?

So my wish list for SharePoint 2010 starts with:

• A site focused web based upload, install, and management capability similar to that found in WordPress and Plug-in central for WordPress
• A Rich-Text Editor that is rich in function, easily expandable and replaceable.
  Consider integrating a freely available javascript-based Rich-Text Editor for all browsers including IE. My primary choices would be FCKEditor and TinyMCE or TinyMCE Advanved.
• A competitive wiki and blog, without having to buying 3rd party add-ons.

Perhaps Microsoft only wants SharePoint to be a document sharing facility. Maybe I should not be trying to bend WSS and SharePoint into the social media and web 2.0 “arena”. Maybe that “arena” should just belong to Apache, Linux and Open Source.

One of the things people want to do is easily create inter-page navigation links like, top, bottom, etc. Although not the most user friendly approach, you can do this manually by entering anchors from the source view of the Wiki Editor. Here’s how I do it.

Manually add anchors using HTML code.

In the Wiki editor,click the source button to switch to HTML source view. Add your anchors wherever you need them in the source,  using the pattern:

<a id=anchor_name name=anchor_name></a>

You can have many anchors. You just give them different names and ids. For an anchor named top it would be

<a id=top name=top></a>

When done adding anchors, click OK to go back to the rich text view.

Create relative links to the Anchors

To create links to the anchors you just created, you will do this from the rich text tool-bar by clicking on the Hyperlink button.

In the Hyperlink dialog, for the Address, specify the root relative URL for the page by removing the site info and adding the #anchor_name

In General, you can get this URL by going out of edit mode on the page, and back to viewing the page in regular view mode.

1. Copy the URL from the address bar
2. Remove the site-name part of the URL (e.g. http://yoursitename)
3. Add the named anchor portion (e.g. #anchor_name) to the very end of the URL.

For a default Wiki Library in a HR sub-site in the default SharePoint SiteDirectory the relative URL will look something like

/SiteDirectory/HR/Wiki%20Pages/YourWikiPage.aspx#top

I hope to evaluate the Telerik RadControls soon, specifically the RadEditor control

I’m also following the status and features of the Community Kit for SharePoint for possible ways to improve the SharePoint Wiki editor.