About usability once again

Currently I’m testing Beta 3 of Liferay 6.1 release and despite many nice changes there are still couple of usability bugs.

New feature in Liferay 6.1 is that you can do almost anything with your site without using Control Panel. While it looks very nice and jazzy in my opinion it was bad thing to do as it often confuses users (especially if they know so much about CMS system as my mom does). They don’t know what is the difference between “Control Panel->Web Content->Add” web content and “Asset Publisher->Add new Basic Web Content” (as you may noticed there is inconsistency in those two labels). They just don’t know which of those two options they should use. Same goes for site settings and Edit Profile (this one opens layer even if you are in control panel already). IMHO most of those layers should be replaced by link that will redirect users to proper page in control panel. But lets forget for a moment about my feeling toward that and take a closer look at one aspect of those layers.

We have layers that do the same thing as Control Panel. After every change you will see Sucess message that will look like this:

Your request completed successfully. The page will be refreshed when you close this dialog. Alternatively you can hide this dialog.

As you may see “hide this dialog” is a nice link that will close your layer immediately. Now go to Control Panel, do the same thing. Ta daa, you will see the same message with the same link but this time it won’t do anything.

And now is the problem to solve. Should we remove that link? Should we duplicate messages for Layers and for Control Panel? Maybe we should leave it as it is and tell users that this is not a bug but a feature? Maybe we should replace layers with links to Control Panel and forget about such problems?

Well, I will leave that answer to you 🙂

Advertisement

Liferay leader in Garnter’s Magic Quadrant for Horizontal Portals

On 24th of October Gartner published results for his Magic Quadrant for Horizontal Portals. Once again Liferay is named a leader next to such big vendors like Oracle, Sap and Microsoft.  You can read whole article here.

As you can see below Liferay made a nice run for leader position.

Now the only challenge is to keep this good trend especially when there is such competitor like Drupal which has quite large community.  Also important is that Gartner pointed out couple of potential problems with fast grow of Liferay (you can read it here).
One of it is:

As it extends toward UXP, Liferay could become as bulky as its competitors and compromise its lean-portal value proposition.

This is the one we should all watch carefully because with very good improvement of look and feel of Liferay 6.1 came many UX mistakes and that can destroy all the advantages LR has over Miscrosoft Sharepoint or Oracle WebCenter. And where is new version of Social Office when we need it? Well, lets hope  all those failures will be corrected till final release which is scheduled for Q4’2011.

Till then, Congratulations Liferay 🙂

Asset Publisher and queries count

In this post, I will mainly describe my expierience with Asset Publisher in Liferay 6.1 (87489 revision). In the previous post I showed how Asset Publisher constructs entry query and how many records it picks up.

The starting point of my test was the following configuration:

• About 10 000 AssetEntries
• First page with 1 Asset Publisher without any filters. It gets ~4900 records.
• Second page with 1 Asset Publisher with categories filter. It gets ~ 300 records.

Following table shows results of my tests.

Scenario	Guest	Logged In user
1st request. Asset Publisher with ~4900 results. 20 per page.	~ 9800 queries to database	~ 29300 queries to database
2nd request. Asset Publisher with ~4900 results. 20 per page.	0 queries to database	~ 29300 queries to database
1st request. Asset Publisher with ~300 results. 20 per page.	~ 900 queries to database	~ 900 queries to database
2nd request. Asset Publisher with ~300 results. 20 per page.	0 queries to database	~ 30 queries to database

Interesting situation is the second row of this table (Asset Publisher with ~4900 results. 20 per page and logged in user). Asset Publisher retrievs 5000 records from database. Now in a loop it sends one query to transform AssetEntry to specific entity (JournalArticle in my case) and sends two queries to check permissions. It gives three queries in one record.

So Liferay sends 2 * (5000 * 3 queries per item) = 30 000 queries. In the trunk version the second query is cached so it gives 15 000 queries.

Fortunately, most of the queries is partially cached.

From a business point of view I want to display 20 articles in one AssetPublisher with pagination so I don’t understand why my portal sends over 30 000 queries to database. It’s a horrible situation when simple task frequently overuses my server resources.

One of bottleneck in Liferay 6.1

A few days ago we’ve prepared a jmeter’s test. Our goal was to find a bottlenecks in the newest Liferay 6.1 portal. So we load about 7k AssetEntries (JournalArticles only) and drag and drop one Asset Publisher on the site. To my surprise – page loaded for about 30 seconds. In my mind was born a strange thought: is it possible have we done something wrong? Maybe our content’s importer is killing the portal. So it’s time to debug Liferay.

In AssetEntryServiceImpl we found interesting code:

protected Object[] filterQuery(AssetEntryQuery entryQuery)
throws PortalException, SystemException {
[...]
int end = entryQuery.getEnd();
int start = entryQuery.getStart();
entryQuery.setEnd(end + PropsValues.ASSET_FILTER_SEARCH_LIMIT);
entryQuery.setStart(0);
List entries = assetEntryLocalService.getEntries(entryQuery);
[...]
}


We want to pick 20 entries and Liferay get 20 + 5000 records from database. Twenty – because AssetPublisher has to display this records, plus 5000 – just in case. It gives 10040 records per request in every Asset Publisher. Furthermore – Liferay calls this method two times in every request. Firstly to get countEntries (pagination), secondly to get entities.
Later in this method Liferay checks permissions on every entity and picks only entities which have View permission. I understand this logic, but it’s very expensive.

Maybe Liferay developers should find more optimal way to get Asset Entries. I leave this question open.