Jorge Ferrer

New in 5.1: Much more flexible default configuration for personal user pages

2008-07-20T15:41:37Z

Many of you probably already know how it's possible to preconfigure the personal pages of users by using some properties of the portal.properties file:

default.user.private.layout.template.id=2_columns_ii default.user.private.layout.column-1=71_INSTANCE_OY0d,82,23,61 default.user.private.layout.column-2=11,29,8,19

Some versions ago Ray also added the possibility of specifying a LAR file, which increased the flexibility considerably as now you could create as many pages as desired and also include default contents.

But there was still a limitation, all users had the same default configuration. Not any more. In Liferay 5.1 it's possible to apply different page configurations to different types of users. Furthermore, such configurations can be applied dynamically during the life of the portal.

To learn more about this new functionality read the wiki article How to use User Group Page Templates.

Liferay eats its own dog food again! Now with a wiki taste

2008-07-16T07:46:46Z

Yes, we've finally done it!! Liferay's community wiki has been migrated from MediaWiki to Liferay's own wiki portlet.

We are pretty excited about this because it brings a lot of benefits. To name a few:

The wiki is now fully integrated in the liferay.com website, so it's easier for community members to navigate through all the sources of information. For example, visitors that are directed to the wiki from Google can also navigate easily to the official documentation, forums, etc.
The wiki now generates activities, which then show in the the profile page of each user. That way if you are an active contributor to the wiki you will receive the credit you deserve. It's also easier to keep track of the wiki contributions of your favorite developers and friends using the activies RSS feed.
There is no longer a need for a separate user account to edit the wiki. Use the same account that you already have for the forums.
Some nice new features: copy page, attachments per page, add several attachments at once, child pages, a syntax that is familiar but easier to remember ... and more to come.
We can much more easily add any new feature that the community finds helpful for the wiki.
By using the wiki portlet so extensively the developers and the user community will come up with great new ideas for improvements. This will help our end goal of making the wiki portlet the best wiki out there :)

This has been the result of a lot of work first on improving the wiki and next to prepare the migration. I'd like to thank the help from Alex, Brian, Alvaro, Rich, Jon, JR, Mike, Sam, ...

Now to be fully honest, this is also a little bit scary. While we've tried our best to make the migration as smooth as possible we know there'll be some glitches. For that reason I've created a JIRA issue as an umbrella for any problem that you may find. So if you hit some bug with either the wiki or the migration itself, please create a subtask of LEP-6726 and let us know.

So, what are you waiting for? Go ahead and enjoy the new Liferay Wiki! If you haven't done it yet, now there is no excuse for not participating ;)

PS: If there is interest I can write a second post about the details of the migration and how you can do the same.

Inter Portlet Communication: One size does not fit all

2008-07-03T09:24:22Z

Inter Portlet Communication (IPC) is a hot topic nowadays. This was probably the most missed feature of the first version of the portlet spec (JSR-168), but has made it to the second version (JSR-286, supported since Liferay 5.0). Maybe this is the reason why more and more people are becoming interestind in IPC, and even in portlets in General.

As I've mentioned in previous posts, JSR-286 provides two very good methods for communicating portlets: shared render parameters and events. But this post is not about them, it's about the fact that while having standards is very good, it should not inhibit us from using other solutions when they fit. In particular, I think IPC is a very broad topic. There are lots of different scenarios and communication needs for a single solution to be the best for all IPC problems.

If the solutions provided by JSR-286 fit your needs, by all means use them. But it's also good to know other alternatives. In particular I'd like to highlight today a method provided by Liferay to communication portlets using a super-lightweigth JavaScript events system that runs completely in the browser. This method has been available for some time, and it's now documented in Client-side Inter-Portlet Communication. Take a look and let us know how it works for you.

Yes, web applications can also have progress bars

2008-06-21T18:00:29Z

A progress bar is one of the most useful widgets for a user interface when the user can perform lengthy tasks. Unfortunately, while it's a widget very often found in desktop applications it's not so common in web applications. The reason for this is that it's not so obvious how to implement them.

In fact, not so many years ago I remember saying to a customer that it was not possible to show a bar to show the progress of a file upload, and shortly after that Brian added that functionality to the Liferay's Document Library. When I looked at the implementation I felt really dumb, because it's actually super simple.

So the answer is yes, web applications can have progress bars. Not only for file uploads but for any task that might take more than a few seconds. And if used in a smart way they can be a very important factor to improve the usability of a web application. As an example look at a screenshot of one of the tools I'm working on lately, an importer of a whole wiki from MediaWiki to Liferay's new wiki:

As you can see in this case I've chosen to have two different progress bar. One for the upload and one for the actual importing process. That way the user is always up to date on the status of this operation which might take a while to complete.

If you are interested in knowing how this works or would like to add it to your own portlets don't miss the wiki article How to add a progres bar to my portlet.

The JSR-286, Portlet 2.0 specification is Final!!

2008-06-16T08:32:18Z

Several weeks ago we announced the compatibility of Liferay 5 with the final draft of the spec. and now it's been declared officially final. Thanks go to Stefan, the spec lead, for all his hard work during the last weeks dealing with legal and administrative stuff to make this possible.

I recommend you all to download and read the spec, because it has many interesting additions: Inter-Portlet Communication, resouce serving (very useful for AJAX apps among other things), filters, and more.

Brian just passed the TCK once again and .... yes we are still 100% compliant :)

New in 5.0: Customized login pages... even per community

2008-05-23T17:46:49Z

Until now when the user was in any place of the portal clicked the "Sign in" link he was shown a default portal login page. Of course it was already possible to create your own customized login page using the available portlets, but the user was not redirected there when clicking the "Sign in" button.

After this improvement it is possible to let the portal know that a given page should act as the portal login page by setting a property in portal(-ext).properties. For example to set the home page of the guest community:

auth.login.url=/web/guest/home

But that's not all. It's also possible to have a customized login page per community. That will allow users that are navigating a give community site to log in without going to a portal wide page. The way to achieve it is super simple and doesn't even require modifying a properties file. The community administrator can do it himself by just creating a regular community page and giving it the /login friendly URL. That's it, the portal will automatically detect such a page and will make it the login page for that community. Of course, don't forget to put the actual login portlet there :)

I'm trying to keep my blog posts short, so I've created a wiki page with more details about this functionality. Also a wiki page is better to document this feature since it can grow if more features are added. You can find it here: Customizing the portal login page.

New in 5.0: Support for Archived Setups

2008-05-05T00:17:39Z

This is a new feature I've been wanting to blog about for a while. It was inspired by a request from a customer who wanted to be able to store the different configurations of web forms and be able to later reuse them. For example, at some point there could be a form for "Contact Us", another for "Request for detailed information", another for "Inscription for event X", etc. Not all of these forms would be active at all times so it was needed to be able to hide the portlet but keep the configuration available for future occasions. Also some form configuration

This was clearly a feature that many people could benefit from so it would fit into the product itself. Furthermore we realized that the idea could be useful to several other portlets such as navigation, asset publisher, etc. So welcome to "Archived Setups". This feature is available through a new tab called "Archived Setups" within the configuration UI as shown in the following screenshot:

Within that tab you can save the current setup by giving it a name or restore any of the previously archived setups:

The archived setups are community wide and are included in the LAR files when exporting or exporting either the whole community or the data of an specific portlet. Access to this functionality can be controlled through the permission system by giving or removing from users the "Manage Archived Setups" permission. By default only the community administrators have access to it.

Better integration of FCKEditor and themes

2008-03-07T18:40:28Z

Up until now the editor area of FCKEditor did not always correctly reflect the look&feel that the contents were going to have when published. The reason was that the theme CSS was not being applied within the editor area. With the help of Nate I've just fixed that so from now on, what you see will really be what you get.

But this is just the beginning of a better integration. The next step has been to make it possible to select styles within the editor (substituting the old and not so useful font select box). With the new select box it's possible to select different headers and other useful element types:

These are all HTML elements so it's very easy for a theme to define the desired look and feel for them. The content authors will be able to just select them and have that nice look be applied automatically.

But the fun just starts here. What is truly powerful is that FCKEditor allows defining custom styles. To test this out I've defined three styles that are mapped to the existing classes to show informative, alert and error messages. The look and feel of these messages is defined within the theme. The next screenshot shows 3 paragraphs each with one of these styles:

What is very cool is that the styles can be applied as a CSS class so all the power remains for the theme. For example the above screenshot has the following HTML source:

These 3 styles are just nice looking examples, but they are probably not so useful. What I'd like to do is define a few standard very useful styles, provide a default look & feel for them and, of course, let theme developers provide custom appearances. Which styles would you define? I can think of:

highlighted: to highlight text for example with a yellow background
javacode, htmlcode: to format the paragraph according to java or html code rules (with some javascript this could look very good, although probably we wouldn't add it by default to avoid having even more js libs).
other?? I'm not feeling that creative today so I'd appreciate your thoughts and suggestions here. You can win a default style available for you and your content authors in the next release of Liferay!! :)

For TinyMCE users: you are using TinyMCE instead of FCKEditor? Do you know how the same thing could be done? Let me know, or better, send me a patch and I'll happily apply it :)

The Portlet 2.0 spec has been approved!!... and Liferay is already 100% compliant with the final draft

2008-03-04T17:51:51Z

We've been waiting for this moment for a long time. I've received this question by email, in person and through the message boards, lots of times... when will the Portlet 2.0 spec be ready?.

Finally we have the good news, I just got an email from Stefan Hepper to the JSR-286 expert group mailing list announcing that the Portlet 2.0 specification has been approved (so it's very close to be final). First of all I'd like to congratulate Stefan for all his hard work to get this spec done. I'd like to thank also the work of the rest of the expert group members, it's been a pleasure to meet them all and be able to discuss with them about the new features of the spec.

What's new in portlet 2.0?

The new spec has a lot of new features, I won't make an attempt to list them all but will highlight those that I consider to be most important:

Inter-portlet communication (aka IPC): there are two new mechanisms to achieve this. The first is called shared render parameters and allows portlets to set params that can be read by other portlets. This rather simple mechanism will probably be enough for all but the most complex communication needs. For those complex ones there is a second method based on events. The main advantage of this second method is that it allows a fully uncoupled communication. A portlet issues an event and doesn't have to care if there is anyone listening for it.
Resource serving: this is very useful not only to serve binary content such as files but also to improve drastically the support for AJAX in portlets. Through the new serveResource() method it's possible to serve HTML fragments, XML, JSON, anything that your AJAX based app can consume in the client side.
Portlet filters: Add filters to execute code before or after a request to a portlet. While this was already possible by using a solution provided by Apache Portals it's now part of the standard. This makes it easier to use and will fortunately foster the development of reusable filters.
Better compatibility with existing frameworks: Several minor improvements to ease the usage of regular web app frameworks to develop portlets.
Other: Easier development by using annotations, setting and reading of HTTP headers, access to the portlet window id, setting markup HEAD elements (specially useful when producing HTML, which is the most common output), etc.

And all of this while maintaining backwards binary compatibility!

Does Liferay support it? Already?

Yes! Last week Brian announced that with his last commits to subversion Liferay now passes all of the TCK tests for the final draft submitted to the JCP. Here is the image to prove it:

[Edit (March 6th): Image removed since we should not show TCK results until the final spec and TCK are publicly available (which should happen in the following days). Sorry for the inconveniences]
The next major release, 5.0 will include this support and is planned to be released in the following weeks. We'll try to get a release candidate ready ASAP for those that can't wait to test it.

Note (March 11th): I received a clarification from Stefan saying that even though the final draft is approved it's not published yet and thus it cannot be considered final. For that reason I've moderated the language to make that clear. I would expect the publication of the spec to happen in the following next days.

I want to learn more. What do I do?

There are already several introductory articles published and a quick google search will show them. But we've thought that it's not enough, so we are preparing several sample portlets to showcase the new functionalities.

Furthermore I plan to be adding a blog entry for each of the main new features as we prepare the sample portlets.

So stay tunned to Liferay's blogs.

Easy and robust Drag & Drop with jQuery UI

2008-03-02T18:01:38Z

I just came across a blog post with an example on how to create a drag & drop effect using jQuery UI.

Looking at the code it surprises how easy it is. The whole JavaScript is around 17 lines of code, but but only around 9-10 of them are directly related to the drag functionality.

But after hearing Paul talk about all the casuistics he was considering when implementing this functionality I would say that the most important characteristic is not simplicity but robustness.

Ever build a drag & drop effect but fails when the user moves the mouse out of the browser window? what happens if the mouse button is released in another app? etc, etc. That's the real hard part of drag & drop and is great to see Paul and the jQuery UI guys pay so much attention to these details.

Introducing the amazing new Liferay wiki (part 2)

2008-02-24T20:14:49Z

As promised, I want to finish the review of the new features of the wiki portlet. This time I'm not going to write much and will let the screenshots speak for themselves:

Diff view of changes betweeen versions.

Here goes a feature that we've waited for for a long time:

Click the button and you get:

Nice, right? You have to thank Bruno for it.

Subscriptions to changes

It's now very easy to keep up to date of changes made to the wiki either by subscribing to a single page or to a all the pages of a wiki (aka node). You can subscribe to a page from the pages Properties table and to the node from the Recent Changes page:

Showing images

You can include images published anywhere in the Internet by using the URL. Note how simple and easy to remember is Creole's syntax specially when compared to WikiPedia's syntax:

And here is the result:

Attachments

Some times you want to include an image that is not yet published somewhere else. Or you may want to attach some other type of file to the wiki page. Welcome attachments!

No images yet. Let's upload some:

There you go:

When editing a page you get a list of all files attached to the page (with links to preview the image if desired), so showing an image is as easy as copying the image name between {{ and }} signs.

Table of contents, inclusion of pages and other JSPWiki plugins

One of the nice characteristics of JSPWiki is that it has lots of plugins. While I haven't tested them all and can't ensure they work, I've tested two of the most useful ones, including pages and table of contents. Note that Creole has a defined syntax to include plugins which is quite easy to type and does not conflict with other constructs. For example:

<<TableOfContents>>

Here is the result:

To include a page, it's necessary to use JSPWiki's InsertPage plugin (although I plan to support an easier syntax in the future):

<<InsertPage page='IncludedPage'>>

Regarding plugins, if you test a JSPWiki and it fails, please let me know.

Optimistic locking

Have you ever spent some time writing some text and for some reason lost it? Isn't very very annoying?. How about if you don't notice and someone overwrites your wiki changes. That can't happen anymore in Liferay's wiki:

Children pages

This is one of the last features added and is one of my favorites. In wiki.liferay.com we often have to create related content that spans several pages. Wouldn't it be nice for the wiki itself to handle these relationships? Here you go:

A nice detail is that when visiting a children page you get a breadcrumb showing its parents above the title:

Tag based navigation

The last feature is very simple, but nevertheless very useful. Whenever a page has several tags, these tags are shown as links that can be clicked to see a list of all pages with the same tag:

And when clicking, for example, the "creole" tag you get:

Future

My plans for the future of the wiki are to make it as robust and easy to use as possible. I'm sure there are lots of features that could be added (I have lots of ideas myself), but sometimes adding more features makes an application harder to use in general. So I want to be cautious and spend the time doing little improvements to make sure it's a pleasure to use the current functionalities rather than making it become a fat bag of features :)

Having said so, keep the suggestions coming :)

Introducing the amazing new Liferay Wiki

2008-02-17T12:22:12Z

Ok, maybe the title is a bit pretentious but I have to say that I'm really excited with the results. I'm surprised myself with how much we've been able to do in so little time. IMHO after these improvements Liferay Wiki can be compared to the most known wiki products out there (proprietary or Open Source). Not only it's comparable to them in terms of wiki related functionalities but it also inherits the great features of Liferay Portal such as user managment, permissions, the ability to have several different wikis in one single installation (several per community) and of course the ability to mix and match with all the other Liferay tools such as blogs, forums, content managment, etc.

Let's get to the new features. But first, for those that can't wait here is a screenshot that shows several of the new features:

Nice UI with emphasis in usability

A wiki is a tool used to publish information and often becomes part of public websites, so it has to look good. This includes having a clear visual hierarchy that highlights the title of the page among everything else and makes it easy to read the page text.

One of the nice things of Liferay's wiki is that it lives inside a portal. That is, it doesn't have to care about navigation or look & feel issues. Those features come for granted and the wiki just has to care about it's own content and the portal will give its users great flexibility through all other CMS portlets.

The most important peace of information in a wiki page is its title. In order to make it clearly visible it's bean put the first visible thing in the upper left corner. For those using the wiki in 4.4 note how the tabs that used to be there have been removed. Also the search box have been aligned to the right so that it doesn't interfere with the visual hierarchy. Here is the result comparing what it used to be and what it's now:

(Before)

(After)

If you've noticed an icon in the upper left corner, note that it only appears for administrators and allows them to create several wikis within the same community. They used to be called nodes (and still are called nodes in the code), but the UI have been renamed to match what most people would expect.

When there is more than one wiki in a single community they show as links that allow navigation in a typical way that people would expect:

Also, as the wiki kept increasing in number of functionalities we've had to deal with how to keep it easy to use. In fact, with how to make it easier to use than it was with less functionalities. We wanted to make the "Edit" option clearly visible and not hidden among lots of options. The new "Print" functionality also had to be in every page. All other functionalities were moved to a second screen to keep the the page's screen clean. That second screen is called "Properties" and not only provides useful information about the page but also offers advanced operations to the user. Here is a screenshot of it:

You may have already noticed some new cool functionalities in these images, but be patient I'll get to them.

Print, Preview, Delete and Move

The first new feature added was the ability to cleanly print wiki pages. This has been added as an new icon next to the edit icon and when clicked opens a pop-up which only shows the current page, excluding any other portlet as well as buttons and controls that should not appear in the printed version. Following is a screenshot which shows the original page, the pop-up that appears as a preview of what will be printed and a printer dialog that is automatically open for the user.

Another very useful functionality that was added is the ability to preview changes when editing an article or even before creating it in the first place. To that end a new button has been added next to save and when clicked the current content in the textarea is submitted to the server to generate a preview. The returned page contains the preview in an area with a light yellow background (as shown in the screenshot) to prevent the user from thinking that the page has been saved. Below the preview is a textarea so that the user can continue the edition. Related to this, a new button called "Save and continue" has been added so that editors can save the content from time to time while writing long pages but maintain the edit screen to keep writing.

The delete page functionality is a quite simple operation that wasn't available before. It allows editors to completely delete a page. This option is also available through the Actions menu.

Finally the most advanced functionality added in this group is "Move". This functionality allows changing the title of a page without breaking existing links to that page. To that end, when the page is moved, a "reminder page" is left with the new title that redirects the user to the new one. Note that this redirection is logical, inspired by the way WikiPedia works, which means that the user is informed that he's been redirected so that any potential confusion is prevented. It's also worth noting that when a page is moved all of its history is moved with it and that when a page is deleted any "reminder pages" that it may have left behind after renamings are also deleted.

And here is the result when a link to the old page is used. Note the message under the title:

Call for comments: I called this operation 'move' because it's how MediaWiki calls it. But now I'm thinking of calling it "Rename" which is what it really does, and leave the word 'move' for future operations such as moving across wikis. Thoughts?

Creole syntax support

One of the drawbacks of the world of wiki products is that each have an slightly (or completely) different syntax. To solve this problem a group of smart people, including the inventor of the original Wiki, Ward Cunningham, have sat together and designed the Wiki Creole syntax. The goals were to create a syntax that was as similar as possible to the ones already in use, consistent and easy to type and remember. And after implementing it for Liferay and using it for some weeks I have to say that they've done a very good job. For those fans of WikiPedia's syntax, a quote that I read recently is that "Creole is like WikiPedia's syntax but without its inconsistencies".

It's worth noting that the support for Creole in Liferay has been possible thanks to the integration of JSPWiki and specifically using the CreoleFilter developed by the i3G institute. Thanks a lot to all of them.

Here is a cheatsheat of the main syntax elements of creole:

Note for current users of JSPWiki: you can also use JSPWiki's native syntax if you want.
Note for developers: you can also add support for any desired syntax or your favorite wiki engine by implementing an interface is for some reason you don't like Creole or JSPWiki.

More

Wow. I've only started and this blog entry is already quite long. In next posts I'll describe some other features that have been added such as watches (by email and RSS), images, attachments, table of contents, inclusion of pages (using JSPWiki's syntax), optimistic locking, diff view of changes betweeen versions.

And don't be shy, keep the comments coming!

--
Jorge Ferrer
Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

My first book bought at Lulu.com .... and it was a great experience!

2008-02-13T17:09:27Z

Yesterday I received my first book bought at Lulu.com and I have to say that the whole process has been great. The price has been lower than the usual technical books I buy and I've had to wait much less than I usually wait when buying a book in on-line shops. Note that I have no relationship with Lulu.com at all, but I think when people do a good job they deserve being recognized for it.

For those that don't know about it, Lulu.com is the new project of Bob Young, the Redhat co-founder and has as its vision allowing everybody to become a writer and a publisher of their own works. The book that I wanted to buy is "Getting Real" by 37 Signals. I had already read some chapters of it and wanted to read the whole book. Actually it's available for reading online, but as I know it's a good book I prefer to have a nicely printed copy (specially since the price is quite good). So I went ahead to lulu.com (following the link from 37 Signals' site) and added the book to my Shopping Cart. The first doubt that comes at this point is, how much is the delivery going to cost? how long does it take? The guys at Lulu.com have done a good job identifying the questions that people have and my view of a shopping cart had an easy to find link to a page that gave me the answers I was looking for.

But what is even nicer is that they actually delivered in the time they promised (actually very early within that range).

So here I am right now with my nicely printed book:

Wiki overhaul ... continues

2008-01-19T14:28:41Z

Happy new year everybody!!

It's been a while since my last post and this will be a very short one. All I wanted to do is let everyone interested know that I'm working on improving the wiki again. After the latest changes there is been a renewed interest in Liferay's wiki and a company has agreed to sponsor some further improvements (let's give them a big thank you).

After several conversations we've decided that their requirements will be best met by integrating JSPwiki's engine so that'll be the topic of my first tasks. But I'm doing it in a way that allows preserving the existing formats and to add new formats in the future by creating a pluggable wiki engines infrastructure. So I'll be refactoring the current formats (classic, plain text and HTML) as 3 engines and will be developing a new one for JSPwiki. I think this is a very flexible solution that will keep everybody happy.

The sponsorship also includes some other improvements to versioning, locking, etc. I'll also try to implement some other features in the wish list in my spare time. Also if you want to send me patches for features that you are interested in adding this is a perfect time to do it.

All of this new functionality is scheduled for Liferay 5.1, although will be available in trunk soon.

Making it easier to contribute to Liferay

2007-12-14T02:31:59Z

One of the toughest parts of contributing to Liferay is that we are very strict with the coding and design style. We do this because we believe that keeping a very high level of consistency is what allows the product to keep evolving at maximum speed.

Fortunately there are very smart people in the community that have been able to learn this rules just by looking at the code and they keep sending patches of awesome quality. But we often receive patches that have to be completely refactored or rewritten because they don't satisfy our guidelines. The thing is that our guidelines are not documented anywere so it was not easy to learn them. Or at least not until now...

The good news is that we've just started an effort to fix that. In the wiki you can now find the Liferay Core Development Guidelines. It is divided in 3 different documents:

Liferay Core Technologies: The main technologies used in Liferay Portal and how to use them to extend it's funcionalities and add new ones
Liferay Development Style: Coding and Design style
Liferay UI Guidelines: How to create usable and consistent interfaces in Liferay.

It's only the beginning but we believe that it already contains a lot of useful information. Including source code formatting rules!

I hope you like it, and please keep the feedback coming.

We want the best release process possible

2007-12-06T06:09:46Z

Determining the best strategy for doing releases is one of the hardest challenges of developing a software product. We get lot's of feedback related to it, although it's usually in the form of indirect comments or questions. Some very common examples are:

"When are you going to release the next version? I really need feature X"

"Another release? I just finished migrating to the previous one"

"Is it safe to upgrade to release x.x.x?"

"Is the release x.x.x production ready?"

"This release should have been named y.y instead of x.x"

"Don't use version x.x.0 in production. Wait for x.x.1 or x.x.2"

We pay a lot of attention to this type of comments because they guide us to choose the best possible strategy for our releases. The basic compromises are:

Delivering new functionality as soon as possible
Keeping releases very stable and backport fixes to them for as long as possible

In the 4.3.x set of releases we tried a new approach to make new features available faster. Every feature that was added to the product and had initially been planned for 4.4 was reviewed and if it didn't seem to cause migration issues, it was added also to the 4.3.x line. That way each of the versions from 4.3.0 to 4.3.5 has, not only bug fixes but also some of the new features. This is the same model that the Linux kernel used until recently or the Gnome project still uses, although with a different version scheme. This way of doing releases has the huge benefit of rolling new features out very fast. But we've also found that it has drawbacks for people looking for a very stable platform but also want bugs fixed.

The reason why I'm blogging about this is because we just had a meeting yesterday to talk about all of these ideas to improve Liferay's release process. Mike has already blogged about our conclusions. The most important is that we will be going back to the traditional way of doing micro-releases that only contain bug fixes and no new functionality at all. But at the same time we want people to be able to use the newest functionalities as fast as possible, how can we do that? We've decided that we are going to try to make frequent and periodic releases with a known and predictable release cycles. This is the same idea that is working very well for Ubuntu. We don't know for sure which period will be the best. We'll start with two months but may adjust later based on your feedback.

In order to be able to release so often, we will probably need some help from the community. Specially for testing. We are already contacting the most active and trusted community members to start a beta testing program. We'll ask them to test a new version of Liferay in their environment and will give them full attention during the period of time prior to releasing to fix very quickly any issue that they may find. We've just started, but we already have the first committed beta testers (thanks a lot guys!). We'll add a list of all the beta testers to the site so that they can get the respect that they deserve. We also want them to benefit from being part of the beta testing program by getting our help to make sure that the new version will work well for their environment.

There are some other details of the improved release strategy, including creating Long Term Releases (LTS). Those are releases that will be supported longer and fixes will be backported to it for a longer period. So if you want the greatest stability possible and don't care about waiting a little bit more for the newest functionality you should always pick an LTS release (4.4 will be one of those). Also we'll create a wiki page at the beginning of each release cycle with the planned features for the next release. Liferay Portal is known to be very fast at incorporating new technologies and features and we don't want to loose that, so we will still add features even if they were not originally planned. What we want to do is to have a list of what we absolutely want to have in the next release, so it'll get higher priority than anything else. Any other feature may get in if it doesn't delay the date or cause any of the high priority ones to be dropped.

I think I've covered all the important decisions we made. Now it's your turn to give your opinion and let us know what you think.

Latest improvements to the message boards portlet

2007-11-27T21:55:42Z

It's been a while since my last post, but here I'm at it again. This will be the first of a series of posts where I plan to write about the latest improvements to Liferay as we develope them. I will not only talk about those that I develop myself but also about those done by others if I see that they do not do it themselves. The end purpose is to keep everyone interested more aware of our progress and the cool features that they'll find in future releases.

I'll start with the message boards. This is in my opinion one of the best Liferay portlets. It's being used for Liferay's own community forums which already has more than 40k posts and gets lots of new ones every day. And it's thanks to this usage that we get the best ideas of how we should improve the application. Here is a list of improvements that were just done last week and you should be able to see live in a few days and in the next releases of Liferay:

Show the number of messages in a thread in the search results

Quoting Tobias Amon who gave the idea for this feature: "when i try to find a solution for a problem it would be very usefull if in the result list the number of answers to a topic have been posted. As only answered posts are helpfull this would help to find usefull posts."

This is a great example of one of those little improvements that make a difference. And for Brian it was very easy to add it.

Show the full message in the RSS

This is incredibly helpful for those of us that are subscribed to the message boards using RSS readers (I do it for certain categories). Brian again was able to implement this change at lightning speed after it was requested.

More robust reply to a notification by email

Liferay has a pretty unique (and not so much known) feature that allows it to receive email message directly. The message boards portlet uses this to allow users to reply to posts directly by answering to the notifications that they received from their subscriptions.

Unfortunately since we moved liferay.com to a new colo this functionality wasn't working properly on for the community forums, causing replies to be treated as new threads. This was probably caused because some of the standard SMTP headers used to implement this feature were not being propertly handled by some intermediary process. Anyhow, we decided to make the feature more robust to avoid depending on intermediary systems. Now the reply-to email address has the original message id, so we can be sure that the reply is properly nested.

Include a URL to the thread in the notification

Some people don't like to reply by email or want to see the message in the context of the full thread. For those, now the URL of the thread is included in the notifications.

Separate "Move Thread" permission to allow for delegation of moderation

We want to start giving out moderation roles to some of the most active members of the community. One of the most common moderation tasks is to move threads to the appropriate categories if the original poster didn't pick the right ones. Previously that required the administrator to delegate the permission to edit ANY post. That's a very powerful permission and involves too much responsability, so it cannot be given away so easily.

To make moderation delegation more fine grained we've created a new permission called "Move Thread", and a new associated UI that allows moving a thread without editing any actual message. Note that the moderator should have permission in both the source category and the target category in order to be allowed to do the move.

Inherited permissions on categories

To make the above permission easier to manage we've improved the permission checker for categories so that permissions given in a category are inherited through all of the subcategories (not only first level subcategories, but all). That way it's possible to give the "Move Threads" permission (or any other permission) in a top level category to allow moderators to move posts around any of the subcategories.

The message boards can now be exported and imported

As part of the great work that Bruno has been doing lately to develop DataHandler's for Liferay's main portlets he also developed one for the Message Boards. This allows exporting the posts and categories of a message boards portlet into a LAR file and then use that as a backup or to move it to another community, another machine, or any other use that we may not have thought about.

This is also part of the very large improvements that we've been making to the export, import and staging functionality lately. I plan to dedicate a whole new blog entry to that subject.

That's all for this post, since I've been adviced to keep my blog entries shorter (thanks Dani!) and this is already quite long. Thanks to all of you that gave the ideas for these improvements! BTW, for the most techie readers that want to know more about these improvements take a look at: LEP-4245, LEP-4240, LEP-4221, LEP-4326, LEP-4320, LEP-4282,

Introducing OpenSocial and how Liferay can benefit from it

2007-11-11T11:40:39Z

Last week Google announced OpenSocial with an impressive set of partners including Orkut (as expected), MySpace, iLike, Flixter, Oracle, .... There were companies that had their own social network, others that offered applications through the Internet and even companies that provide services and infrastructures. There's been a lot of blogging about whether this is Google's checkmate to Facebook platforms or it doesn't make such a difference, among other reasons because Facebook could actually jump in into OpenSocial too.

But I'm not that interested in politics. What I really care about is the technical side of OpenSocial and looking at that side there are a lot of things to be excited about.

Let's start from the beginning, what exactly is OpenSocial?

“OpenSocial is a set of APIs that an application can use to access social network related functionality. Including accessing information about the user and his/her network of friends, modifying this information or generating activities based on what the user does in the application that his/her friends will receive.”

This API is targeted to applications that run in social networks. Those applications do not usually run by themselves but are accessed through a social network container that executes it either locally (as it's done with portlets) or remotely (as happens with Google gadgets). The fact that the application runs in a web page that acts as a container is key to understand OpenSocial.

The key innovation of OpenSocial

OpenSocial provides both a web services API and a JavaScript API, but it's the latter the one that makes a difference. The reason for this is that it allows the paradigm of:

“Develop Once, Run Everywhere”

This is possible because JavaScript is a dynamic language and is executed in the browser. Let's see an example code:

var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
req.add(req.newFetchPersonRequest('OWNER'), 'owner');
req.add(req.newFetchPeopleRequest('OWNER_FRIENDS'), 'ownerFriends');
req.send(function(data) {
   viewer = dataResponse.get('viewer').getData();
   owner = dataResponse.get('owner').getData();
   ownerFriends = dataResponse.get('ownerFriends').getData().asArray() || [];
}

There are several things to note about this example:

The access to the API starts through an object called 'opensocial'. That object is not part of the application, it just assums that it's going to exist when it's executed within the social network container.
Each opensocial request contains several petitions for functionality. That allows reducing latency and network bandwith, because each application only needs to make one remote request.
The request is asynchronous (uses AJAX), so the user can interact with the parts of the site that do not need to wait for the response.

This application can be run in any web page that offers a JavaScript object called 'opensocial' that implements the functionality defined. So any current (social network) platform that already provides that functionality through it's own mechanisms and API can quite easily write a thin JavaScript and web services layer to support OpenSocial.

From an application developer perspective that really means that they can develop their social application once and deploy it in several distinct containers. The application will use the social network of the container where it's deployed.

But what if some social networks have some functionalities that others don't?

Standarization vs Innovation

OpenSocial defines three functional modules:

People Data API: access the owner of the page, the viewer and their friends
Persistence Data API: simple storage of information about the users.
Activities Data API: Like Facebook's mini-feed

While those modules cover much of the functionality needed in social networks, it doesn't cover all. Because the truth is no fixed standard will never be able to cover the functionality that is very specific for a given social network. So, faced with this situation what should an OpenSocial application developer do? I see two options:

In some cases it should be possible to leverage the dynamicity of JavaScript to check if a given functionality is available or not. And if not, just avoid using it.
In more complex cases, where using the functionality or not makes a bigger difference or when it has to be decided in the client side, there might be a need to create different versions of the application for each platform.

When the second option is chosen, the sentence “Develop once, run everywhere” is not true anymore. For this reason, some say that Google is not that ambitious and they are in fact promoting an slightly different motto:

“Learn Once, Use Everywhere”

Which is still quite useful. There is still one more technical aspect that may make the developer decide to have different versions per platform: the technology used to develop the OpenSocial application itself.

What technology can be used to build OpenSocial applications?

If you read the OpenSocial website, it clearly says that it's built on top of the Google Gadgets technology. One nice aspect about Gadgets is that the can run in one server (such as Google's servers) but can be shown in any website (for example in Liferay using the Gadget's portlet). Also Gadgets already make heavy use of JavaScript, and even have a mechanism to specify that a certain JavaScript functionality is required by the application. OpenSocial has reused that, so that if an Google Gadget wants to have the 'opensocial' object available it just needs to add the following in its XML definition:

<Require module=”opensocial-0.5”>

So using OpenSocial within Google Gadgets is easy. But Google Gadgets are not the best solution for any type of application. So the question is, would it be possible to use OpenSocial with other technologies such as portlets?

How does Liferay relate to OpenSocial?

Liferay already provides basic functionality that can be used (and has been used) to build social networks. To be fair, that requires some development. For this reason, we had talked lately about developing and adding more functionality tipicaly of social networks in the default distribution (or as an official plugin).

Open Social makes this idea even more attractive. First Liferay would become one of the first products for executing open social applications (right now there are platforms, but you cannot download and use them yourself). Second, Liferay's social features would be exposed through an standard well known API, which is very useful to promote the development of extra applications that leverage it. Third, as Liferay already supports Gadgets, any open social application developed with this technology may even run unmodified in Liferay.

So this is a case where reasonably little effort would yield a great amount of benefit to our users'

The dark side

Although OpenSocial is a very promising technology, and I think it is big step forward in interoperation of applications in different platforms, not everything is good news for it. Most complains come from the lack of documentation and because of some security deficiencies. In fact, very shortly after it was announced someone found a way to hack an OpenSocial application and very shortly after, the same guy hacked another one. There are other people complaining about general security issues regarding the usage of JavaScript and Iframes (specially when cookies are used). And some highlight the lack of user authentication in the standard.

Other complains, that I heard in last week's W-JAX have come from people that don't like the technologies chosen and in particular JavaScript. The good news for those is that other RIA technologies such as Flash or JavaFX can also be used, since they have (or will have) connectors to JavaScript.

To be fair, this is version 0.5 of OpenSocial and the engineers behind it are showing a lot of interest in hearing what the community has to say. I'm pretty sure these problems will be solved for version 1.0. Until then it should probably not be used in live environments, but this is a great time to start development around it. We will most probably do it :)

Liferay's wiki and why usability is so important

2007-10-30T11:39:10Z

My previous post had much more success that I had ever imagined, which is good because it means that there is a lot of interest in the community to have a better wiki portlet. Also one of my conclusions after reading the comments is that there is a renewed interest in Liferay's bundled wiki portlet.

This purpose of this second post is to explain, and show with screenshots, a set of changes that I made to such portlet to solve what I saw as it's weakest points. Also, I wanted to use this opportunity to show what a difference could be made by just making usability improvements. That's right there not a single new feature, it's just the same old wiki but the results speak for themselves. I must confess that I was myself surprised by them, and now I can't wait to start using the portlet in liferay.com ;)

Conquering the first impression

One of the problems of the wiki portlet is that it gives a quite bad first impression. And it does so because it looks nothing like a wiki and uses concepts (such as nodes) that make no sense to the average user. Here are two screenshots of the first impression that a user gets when using the portlet (before and after creating a node)

How could we solve this? Looking at other wikis they all have one thing in common: after installation the first page is a wiki page. In fact all most wikis have is wiki pages, even the administration screens are wiki pages. I didn't want to go that far, but it was clear that we needed the first screen to be a wiki page. Here are the steps I took in order to achieve that:

The initial view of the portlet should always be view of a page (the /wiki/view_page mapping of struts), so I renamed the current initial view as 'Administer Nodes' (/wiki/view_nodes in struts-config) and made the view of a page the initial view (renaming it as /wiki/view)
That leads to a problem when the portlet is first used: there is no page yet, neither a node to put it on (in Liferay's wiki all pages belong to nodes, more on that later). The solution is easy: if the number of nodes is zero, create a default one, with a default page inside.
If no node or page is specified the (as it happens when the user first goes to a page with the wiki portlet) portlet just shows the FrontPage of the first node

Here is the result:

That sure looks much more like a wiki. Some more changes that I did and can be seen in the screenshot are:

Make the title bigger, place it under the search box and remove the breadcrumb
Aggregate all of the actions that can be performed on the page in a single "actions" menu to reduce visual clutter and leave more space for what really matters: the page contents

I wasn't sure if I should have a template with default contents for that page. But thought that it would create all short of difficulties regarding internationalization (remember that my mother tongue is not English, so I actually think about this issues ;) ) so I decided to leave it simple for now, just showing a short message asking the user to edit this page.

Making wiki editing easier

So let's imagine that after these changes the user likes the wiki enough to go ahead and edits the page. Here is the screen provided to edit the page:

An empty textarea with no clue about the syntax to use. Even those that know what a wiki is and know some wiki syntax conventions are quite puzzled by this. When I first used it, I tried some conventions from MediaWiki and Zwiki (the two wikis I had used most) and only some of them worked, I tried again, and then again, and then... I become so frustrated that I didn't want to use the wiki again. Since then, Ray has done quite some improvements to the wiki syntax support, but unfortunately they have passed mostly unnoticed.

The solution is simple, just add some brief wiki help when editing the page with the most used conventions and a link to more detailed documentation (that opens in a new page, of course). Here is the result:

Now, some people won't ever want to use a weird syntax to input their contents. Fortunately Liferay also supports Rich (HTML) editing using an integrated editor (FCKEditor by default). I don't want to go over if that's better or worse becase often that discussion seems to me similar to discussing which is better Coke or Pepsi. I think both options have pros and cons and it's just up to the taste of each person.

But, until now choosing the HTML option had a very nasty side effect: you loose the ability to create pages. Since pages could only be created by writing a WikiLink (using Camel Case) and then clicking the link, when you choose HTML the link is not automatically generated and there is no way to create pages. This was very easy to fix. I just added a new action that allows creating a new page. When selected it shows a JavaScript prompt box asking for the name of the new page informing that it must follow the CamelCase wiki conventions:

After introducing the name the user is taken directly to the edition of the new page just as it happens in most wikis.

After these changes we have a wiki that behaves as people would expect, it's possible to show wiki pages, edit them, create new ones, link them. Now this is starting to look like a real wiki.

Leveraging the underlying power

So far we've only covered very basic features, but Liferay's wiki has some very nice advanced features such as as page history, page links, recent changes, orphan pages, permissions, ...

The feeling that I had about all these features previously were that they were in the way and didn't let me do what I really wanted to. But once you are able to do the basic tasks, the most advanced features start to be of interest. As I described in the previous section, I've aggregated all of these options in the 'Actions' menu:

But the feature that I'm most interested in explaining is the administration of nodes. That's exactly what used to be the first thing that was presented to the user after all these usability changes, and it hasn't been removed. It can be accessed by clicking the "Administer Nodes" option of the actions menu.

So, we come back to the question of what are nodes? Nodes are actually separated sets of pages. Some wikis call it spaces, namespaces, etc. In Liferay they are called nodes. I thought about changing the name, but decided that it wasn't that important for now.

One of the problems with Liferay's nodes is that its presentation does not reflect what they are. To fix that I used one of the most powerful UI widgets (if used the right way): tabs. Tabs are a perfect fit here, since they do the exact same job as tabs in real life physical folders in which each tab contains a group of sheets of paper. So I added tabs in the top part of the portlet and made them be available always. One important thing of tabs in UI design is that they have to work as people expect to be effective. That means that the tab representing the current node should always be selected when the user navigates through the pages of the node, or even when any of the options in the 'actions' menu is used. The only screen in which the tabs are not shown is in the administer nodes screen. Here are a couple of screenshots that show the administration and the end result:

Final touches

After all these changes I was already pretty excited, because the wiki was looking much better and the advanced functionality, specially nodes, was very cool. Yes, believe it or not, I was aware of all this functionality because I knew the code, but seeing it in use and presented this way made a different impression on me.

Some final touches to the portlet that I made were:

Friendly URLs: most wikis products have friendly URLs and Liferay has a pretty cool framework to implement them for portlets. So I used it and in about 10 minutes the wiki had friendly URLs
Most wikis have menus or even boxes with different type of content around. Leveraging portlets Liferay is unbeatable here but to leverage that it was important to maintain the portlet in NORMAL state while the user was navigating it. I reviewed all links to make sure this was the case and changed those were it wasn't.
Configurability. I created two new properties in portal.properties to allow configuring:
- The name of the default node that is automatically created
- The URL that is used to build the link for more help on wiki syntax. By default it points to an article in LiferayPedia, but I'm pretty sure many people (specially in non-english speaking communities) would want to substitute that with their own customized help

Conclusions and availability

The main conclusion from this work is that usability does not only determine if a certain tool is easier to use or not, often it determines if the tool or a some of its features are used at all or not. That's something very important for us software developers because, what's the point of implementing a feature if it's not going to be used?

Disclaimer: I'm not a usability expert and just made some very informal usability tests when developing this, so I'm pretty sure there are still many usability flaws. I just hope that it's a good start point.

The second conclusion is that our wiki is much better than we thought. It still lacks important features but it's a very good foundation. In fact I have a huge list of improvements that I'd like us to implement. Anybody in the audience would like to sponsor some of them so that we can spend more time on them? :)

Finally some of you have asked when this will be available and how you can test it. The answer is that it's already available in Liferay's subversion repository and will be included in the 4.4 release (no release date yet). If you can't wait to try it out download the sources from sourceforge, build them and run tomcat (or your app server of choice).

Ok, that was a quite lengthy post, I'll need a few days of vacation from blogging to recover ;). I hope it was helpful for all of you interested in the subject,

Improve our wiki portlet or integrate an existing wiki... which is better?

2007-10-29T13:20:55Z

It's no big secret that Liferay's bundled wiki is one of the most often criticized. And I can understand it. For example, when you first add the portlet you get a view that looks nothing like a wiki and the only option available is adding a node:

Hmmm... but what is a node? You may ask. If you go ahead and create a node, it doesn't improve a whole lot:

Nodes are actually a very cool feature of Liferay's wiki, but presenting it up front scares people because it makes the tool very different to typical wikis and requires investigation and effort to get it working. This is just an example of the usability problems that the portlet has but it also lacks some features often found in the most popular wikis such as MediaWiki, JSPWiki, Confluence, etc.

Because of this, the wiki portlet is often the target of criticism and people asks as to do something about it, but ... is it better to spend the time and resources in improving our wiki or is it better to integrate one of the popular wiki tools out there?

This is a question that comes up often in internal conversations among Liferay's developers, in blogs from first time users of Liferay and in the forums. So I thought it was time to analyze the advantages and drawbacks of each approach:

Integrating an existing Wiki
The requirements would be: open source and with a good community, actively developed and support for all modern features of wikis.

Advantages

Time, time, time. Unfortunately time is finite and we never have time to do everything that we would want to do, including making Liferay's wiki the best wiki ever. This option frees time since other people are developing the wiki that Liferay's users will use. That way Liferay's developers can concentrate on making the portal-specific features the best ever ;)
Specialized knowledge: the people developing the wiki will most probably know more about wikis than Liferay's developers.
Advanced features: an specialized wiki product will always have more advanced features, as a result of the previous two points.
Some Liferay users may already be familiar with a wiki product and would like to use it within Liferay

Drawbacks

Lack of a unique support source: when an external tool is integrated, people using Liferay have to go to two different sources to get help to solve any problem they may have. And that includes both professional support and community support.
A unique set of pages for the whole portal. Liferay has a feature called data scoping what allows each community (and organization and user) to have it's own data. For example if you put the Message Boards (or Calendar or Wiki, or ...) portlet in community A and also in community B, each get their own instance of the tool, with separate categories, threads, etc. If, for example, JSPwiki is integrated, there would only be ONE set of wiki pages for the whole portal as opposed to one per community.
Separate user repositories. Each wiki product that I know has their own user management system which has its own repositories of users. Fortunately, sometimes it's possible to solve this but having Liferay and the wiki to use CAS, LDAP and/or a some custom integration. Although that means more work to get the portal running.
Lack of integration with Liferay's permission system
The wiki's internal navigation and menus sometimes conflict with the portal's navigation, causing confusion to the end user.

Improving Liferay's bundled wiki
The benefits and drawbacks of this option are the exact opposite of those already mentioned for the previous option. But I'd like to highlight some of them:

Benefits

Separate sets of pages per community. Furthermore, each community can have several nodes (aka spaces) to separate their own pages in different groups.
Full integration with the permission system. It's possible to set different permissions for different pages and create roles that give specific permissions for the wiki portlet.
Integration with the new asset publishing system. This makes it very easy to generate lists of pages such as: all pages ordered alphabetically, latest pages created, latest pages modified, etc.
Integration with some other of Liferay's transversal features: comments system, tagging, rating (to be done), etc.
A single place to ask for support (either profesional support or community support)

Drawbacks

Some people are already disappointed with it and may not want to give it a second opportunity (I hope to be wrong here)
Lack of advanced features
The wiki needs some urgent usability improvements. Without it people won't see it as a good base to build on top of.

Conclusions
The more I think about it and discuss about it with other people, the more convinced I am that we should do both. Why? Because both options have advantages that the other will never have. What about the time? Yeah, that's the problem, time is finite, BUT:

Our wiki is actually not that bad and with some usability changes that should not take more than a day it would be a whole lot better (and I'm cheating about the estimate here, since I've already done it, more on that on a later post)
Liferay is a good platform for integrating existing applications and we want to improve our support since it's an strategic feature of a portal. In fact, just try to download the JSPwiki WAR and copy it to the autodeploy directory, you'll be surprised to see that it's been automatically integrated as a portlet. Of course the integration is not complete, primarily because the user repositories are different, but it's a very good start point.
Since we are considering integrating an open source product we can get the communities of both products to collaborate. That way with enough time several of the above listed drawbacks could be eliminated.

Thoughts?