Strategies to link to a full content view in different a different page

[Jorge Ferrer, modificado hace 13 años.]

Hey guys,

A very common need of websites is to show a list of content abstracts (or even just titles) and link them to a different page (or sometimes a different portlet in the same page).

Within Liferay the two most common strategies to publish the list of content are:

• Asset Publisher: this is the simplest solution and it's quite powerful (specially since version 6)
• Web Content Display to publish a dummy web content that uses an XSL or Velocity template to query the content from a database: This solution requires more work and knowledge of XSL or Velocity but has the benefit of providing full control of the generated HTML and also the URL of the link to go to the full content view.

With the first solution, Asset Publisher, automatically implements support for linking to and showing the full content view, this view is always shown within the same portlet that published the list of abstracts/titles.

The second solution, using a velocity/XSL template and a Web Content display provides more flexibility and allows site administrators to link to a different page or a different portlet if desired. This is possible because the template author will have knowledge of the specific pages that have been created and the portlets within them so she can use this information to create the link.

The problem with this second solution is that it requires a bit of knowledge and many Liferay users don't even know that it exists. Because of this we would like to explore ways to improve Asset Publisher to be able to support linking to a full content view in a different page. I'm looking for ideas for how to achieve this in a general way. Any takers?

[Ray Augé, modificado hace 13 años.]

There has always been a third option which is to pass articleId+groupId as parameters to a WebContentDisplay portlet.

[Jonas X. Yuan, modificado hace 13 años.]

@Jorge, @Ray,thanks.

The third option could be implemented easily - passing articleId+groupId as parameters to a WebContentDisplay portlet.

Eventually, this option had been asked by several clients and got implemented. In general, clients were OK with this option.

[shima shima, modificado hace 9 años.]

hi
please explain how doese it?

[Jorge Ferrer, modificado hace 9 años.]

Within the configuration choose "Display in context" for the link behavior

[Ahmed Hasan, modificado hace 13 años.]

Hi Jorge,

In one of our implementations, http://www.newzfirst.com, we have done this linking, where every link to an article opens in a different page. May be tomorrow during our day, i will check with my developers how this has been implemented and share the details with you. Also see if this can be done thru a much better approach.

Ahmed Hasan
mPower Global Inc.

[Ray Augé, modificado hace 13 años.]

I looks like they identified a particular instance of asset publisher portlet (Qd8l) on a specific page (/full-story), and targeted all articles toward it. For the most part it looks like they used multiple asset publisher portlets to show lists of contents and are targetting the (full-page).

I wonder was this done using the portlet configuration to target a remote page?

All in all, this site works how we would have envisioned the WCM/Asset Pub to work. Good job!

[Grzegorz Kucner, modificado hace 13 años.]

Ray Augé:

I looks like they identified a particular instance of asset publisher portlet (Qd8l) on a specific page (/full-story), and targeted all articles toward it. For the most part it looks like they used multiple asset publisher portlets to show lists of contents and are targetting the (full-page).

I wonder was this done using the portlet configuration to target a remote page?

All in all, this site works how we would have envisioned the WCM/Asset Pub to work. Good job!

I use exactly the same solution as Ahmed's in my sites.
It is simple and works quite fine. Asset publisher configuration is extended with two attributes target page url and target asset publisher id. How to set proper value in these attributes depends on implementation and needs. Next step is modification of abstracts.jsp to ensure that parameters are taken into account for example we can do this in such way:

		    
LiferayPortletURL liferayURL = (LiferayPortletURL)viewFullContentURL;
liferayURL.setPortletId(assetPublisherId);

and

if (className.equals(JournalArticle.class.getName()) && Validator.isNotNull(assetPublisherId) && Validator.isNotNull(redirectUrl)) {
    int pos1 = viewURL.indexOf("/-/");
    viewURL = redirectUrl + viewURL.substring(pos1);
    viewURL = HttpUtil.setParameter(viewURL, "redirect", redirectUrl);
} else {
    viewURL = _checkViewURL(viewURL, currentURL, themeDisplay);
}    

Of course it is not clean solution but it is simple and works moreover we have nice friendly urls which can be easy indexed by robots.
Usually there is no need to redirect to many different pages from one asset publisher. Solutions seems to be sufficient in most cases. Why to use asset publisher instead of WCD? Asset generates return link with WCD we have to implement additional mechanism.

Another solution is to implement mechanism based on portlet events. The target portlet can be Web Content Display or Asset Publisher. Using events we can pass parameters to more than one portlet it can be useful.

[Szymon Gołębiewski, modificado hace 13 años.]

Grzegorz Kucner:

Usually there is no need to redirect to many different pages from one asset publisher. Solutions seems to be sufficient in most cases.

Such solutioon will work for corporate pages or sites where one box presents content from one category. But when you have box that will show artciles from category "sport" and you want to show them in different layouts (one for "basketball" and one for "football") then you must point AP to different pages. If we want to develop platform for building big news portals we can't do a half-resolution to this problem

[shima shima, modificado hace 9 años.]

hi ahmed
I watch your link . would u please explaine how show assetpublishers content in display content page?

[Mauro Mariuzzo, modificado hace 13 años.]

With Liferay 5.2 where categories aren't so powerful and there wasn't the global scope, I've have implemented a "Landing page" solution based on tags.

Suppose you have 3 kind of information: hotel contract, airlines contract, rent-a-car contract.

Every WebContent about "hotel contract" have tags "contract" and "hotel". Every WebContent about "airlines contract" have tags "contract" and "airline"; and every "rent-a-car contract" have tags "contract" and "rent-a-car".

So you can easyly create a page called contracts with an AssetPublisher filtering by "contract" tags showing the last contracts in abstract mode.

But you want that see:

• a single hotel contract in a specific page having other portlet with hotels infos
• a single airlines contract in a specific page having other portlet with airlines infos
• a single rent-a-car contract in a specific page having other portlet with rent-a-car infos

And in that pages you want the other portlet have to show content related to the specific contract.

To "hotel","airlines","rent-a-cars" tags I've added a property called "view_page" containing the friendlyURL of the page where I want to see elements having that tag.

So:

• hotel tag have "/contracts/hotel" as "view_page"
• airline tag have "/contracts/airline" as "view_page"
• rent-a-car tag have "/contracts/rent-a-car" as "view_page"

When the AssetPublisher build the "viewURL" it check:

• if the asset is a Web Content
• if the WebContent have a tags with the "view_page" property
• then the URL is the view_page friendlyURL plus "/tags/X/Y/Z" (where X, Y, Z are the tags attached to the asset).

This mean that a WebContent with "contract", "airline", "alitalia" tags produce a "/contracts/airline/tags/contract/airline/alitalia".

This mean (for 5.2) that AssetPublishers into "/contracts/airline" page automatically filter assets using "contract", "airline" and "alitalia" tags.

Another tags property (system) is used to exclude tags from the "view page game" and make the url shorter.


This approach require a man act as "tags administrator", but content writers have only to add a tag.


With 6.0 the "/tags/" feature doesn't work like 5.2. And there isn't an similar feature for categories.


Because a port in Jan, we are investigating how to port our functionality to 6.0

[Ray Augé, modificado hace 13 años.]

Mauro Mariuzzo:

To "hotel","airlines","rent-a-cars" tags I've added a property called "view_page" containing the friendlyURL of the page where I want to see elements having that tag.

So:

• hotel tag have "/contracts/hotel" as "view_page"
• airline tag have "/contracts/airline" as "view_page"
• rent-a-car tag have "/contracts/rent-a-car" as "view_page"

When the AssetPublisher build the "viewURL" it check:

• if the asset is a Web Content
• if the WebContent have a tags with the "view_page" property
• then the URL is the view_page friendlyURL plus "/tags/X/Y/Z" (where X, Y, Z are the tags attached to the asset).

This mean that a WebContent with "contract", "airline", "alitalia" tags produce a "/contracts/airline/tags/contract/airline/alitalia".

Don't worry Mauro, I'm also thinking about this technique.

[Szymon Gołębiewski, modificado hace 13 años.]

Ray Augé:

Mauro Mariuzzo:

To "hotel","airlines","rent-a-cars" tags I've added a property called "view_page" containing the friendlyURL of the page where I want to see elements having that tag.

So:

• hotel tag have "/contracts/hotel" as "view_page"
• airline tag have "/contracts/airline" as "view_page"
• rent-a-car tag have "/contracts/rent-a-car" as "view_page"

When the AssetPublisher build the "viewURL" it check:

• if the asset is a Web Content
• if the WebContent have a tags with the "view_page" property
• then the URL is the view_page friendlyURL plus "/tags/X/Y/Z" (where X, Y, Z are the tags attached to the asset).

This mean that a WebContent with "contract", "airline", "alitalia" tags produce a "/contracts/airline/tags/contract/airline/alitalia".

Don't worry Mauro, I'm also thinking about this technique.

This technique is similar to the one you proposed before:
1. Usability is bad - you depend on tags. Categories (vocabulary) would be better approach.
2. There can be many articles with the same set of tags / URLs - SEO problem again.
3. My article "About Batmobile" has 2 tags: hotel and airline. On what page it will be shown in full view after clicking a link: /contracts/hotel or /contracts/airline ? Editors problem again
4. number of tags = number of different "use for view" pages + other tags (but that one can be solved by using Category Vocabulary).
5. We point article to page. But which Asset Publisher (or other portlet) should display it in full view? As in my example there can be many AP on one page.

[Mauro Mariuzzo, modificado hace 13 años.]

Szymon Gołębiewski:

This technique is similar to the one you proposed before:
1. Usability is bad - you depend on tags. Categories (vocabulary) would be better approach.

Yes, with 6.0 category is better because thay are "pre-setted"

Szymon Gołębiewski:

2. There can be many articles with the same set of tags / URLs - SEO problem again.

It is a SEO problem if the target page show different results.

But if the target page have an AP configured to show all content in "full-page" and you have 2 WC with that set of tag both are shown in the target page.

To show only one WC everyone needs a "unique tags key". This is easy to force with category, and need more coordination using tags

Szymon Gołębiewski:

3. My article "About Batmobile" has 2 tags: hotel and airline. On what page it will be shown in full view after clicking a link: /contracts/hotel or /contracts/airline ? Editors problem again

This is the real problem of my tags implementation. You need coordination between editor team members and a wiki to list tags with view_page functionaly

Szymon Gołębiewski:

4. number of tags = number of different "use for view" pages + other tags (but that one can be solved by using Category Vocabulary).

With "use for view" approach you set target page in every WC. This let you to be clear.

Supposing you want to change the target page. You have to edit every WC.

With tags you have to change a property.

I'm not stating that tags is better. I've evaluated different approaches and for my specific projects the tags approch was right

Szymon Gołębiewski:

5. We point article to page. But which Asset Publisher (or other portlet) should display it in full view? As in my example there can be many AP on one page.

Yes, we can have many AP:

• one has to show article in full view
• another has to show the same article using a different template
• another has to show documents or bookmarks related to the article
• other have nothing to do wih article

Using tags (I'm saying tags because I'm speaking about my 5.2 solution) every AP is able to identify the right content.

If we use a friendly url mapping pointing to a specific AP instance, are we able to make avery portlet show the right thing?

Sincerely I'd like to escape from my tags solution

[Szymon Gołębiewski, modificado hace 13 años.]

Mauro Mariuzzo:

It is a SEO problem if the target page show different results.

But if the target page have an AP configured to show all content in "full-page" and you have 2 WC with that set of tag both are shown in the target page.

To show only one WC everyone needs a "unique tags key". This is easy to force with category, and need more coordination using tags

Ok, so I have two articles about my local football team. I want to read first one (full view) and on separate page (but in the same layouot) I want to read the second one. In tags approach both articles have the same URL (I want to show only ONE article per page). Same URL for different articles is a bad idea.

What I want to achieve is something like here:
http://www.bbc.co.uk/
In the sport box you will find such two articles:
http://news.bbc.co.uk/sport2/hi/football/teams/m/man_city/9325924.stm
http://news.bbc.co.uk/sport2/hi/cricket/9325830.stm

Full view of both articles is different. Also URL is different so Google won't mess Page rank of this page.


This is the real problem of my tags implementation. You need coordination between editor team members and a wiki to list tags with view_page functionaly

Mauro Mariuzzo:

With "use for view" approach you set target page in every WC. This let you to be clear.

Supposing you want to change the target page. You have to edit every WC.

With tags you have to change a property.

Yep, your're right. We need to figure out some kind of mashup of those two strategies and remeber about poor editors

So to summarize:
1. We need to define which one from many AP on selected page will show content in full page (other can show related articles, documents etc.)
2. As there can be many portlets with the same ID we must pair it with proper page. We will use unique URL of that page (beacuse it's unique) and page title (beacuse it's human readable).
3. We must give editors easy ability to point article to selected page and Liferay must bound that article with "page+portlet" pair
4. We must have option to change destination of many articles (for example we're gonna merge footbal into sport or merge cricket with basketball).
5. We must be able to point different articles from one AP to different pages
6. Different articles must have different URL (SEO).

And all of this must be easy to use

My idea is:
1. We can add another property to AP called "this AP can be used for full view" (pt.1 solved)
2. I think we can find all the AP marked as "this AP can be used for full view" and get the name of Pages they are deployed on [Ray can we do that in Liferay?] (pt.2 solved)
3. Liferay can make automaticaly Category Vocabulary named "Pages for full view" contaninig Categories named using Page titles. Such vocabulary will be displayed on WC editing page and it will be easy to use (pt.3 solved)
4. In LR 6.0 you can merge tags. All content containing tag A will be reassign to tag B. If we could get such functionality for categories (don't know why this doesn't work) we can reassign all WC from one page to another (pt.4 solved)
5. We can change abstract.jsp of AP to construct URL for articles using properties from our Catgegories (pt.5 solved).
6. As in this URL ID of article will be attached every URL will be different (pt.6 solved).

What do you think about that?

[Jorge Ferrer, modificado hace 13 años.]

Hey guys,

First of all thanks a lot to Szymon, Grzegorz, Ahmed, Mauro, Orin, Jonas and Ray for all your ideas and suggestions. I wasn't expecting such a great response but this encourages me to keep sharing these challenging topics with the community.

Furthermore, I'm very excited because I really feel that we are very close to reaching a very good solution to this need. And I must admit I was beginning to loose hope because we've been searching for it for quite some time

IMHO the root of the solution is Szymon's proposal to associate pages to web content. When I first read it I kind of rejected the idea because one of the fundamental principles of Liferay is the decoupling of pages from the individual assets. But that decoupling is also what makes features like linking to a full content in another page so hard. So the more I think of it the more I like the idea and I now believe that if done right we can get the best of both worlds.

I've been reading several times the whole thread to make sure I captured all the different requirements and have tried to summarize the solution reached in a wiki page. I've chosen to do it in a wiki page because I think it's mature enough and it's easier for newcomers to start with the solution.

The solution I've described is actually very similar to Szymon's proposal in his last email, which BTW was very useful for me when summarizing the thread. There is only one main change that I've introduced: I've eliminated the usage of categories. There are two main reasons for this:

• It would be harder to discover and explain this feature if site admins have to learn that categories are used to determine the target of a link.
• It would be quite hard to implement a system that keeps a synchronization between available pages and an specific category vocabulary.

So what I've defined is a way to directly associate web content with pages as well as ways to do this in batches whenever needed (to make sure I met point #4 in Szymon's last post).

I would appreciate if you could read the wiki page and let me know if there is something that I've missed. I've also highlighted some remaining challenges that should be addressed and I'd love to have your feedback on them. Here is the link to the page:

http://www.liferay.com/community/wiki/-/wiki/Proposals/More+flexible+linking+of+web+content+to+full+page+in+Asset+Publisher

Again, thanks a lot for your contributions to this thread. Thanks to them I'm pretty sure this will be doable for 6.1

[Szymon Gołębiewski, modificado hace 13 años.]

Jorge,

I will post here my answers as there is no "reply with quote" option in the wiki comments

Jorge Ferrer:

By default, whenever an asset publisher portlet is added to a page it will automatically become the preferred web content publisher if there is no other instance of the same portlet in the page.

I think by default this should be unmarked for such reasons:
* by default AP will not behave like in older versions of Liferay
* after upgrade / import pages will start to act differently - site administrator might be confused
* if you are building news Portal you will add many AP to the page but the chance that the first one will be used for full view is minimal but if you are building corporate site without this functionality you won't need that functionality at all. In both cases there are many obsolete "clicks". Let's do not do that "by default" action.

Jorge Ferrer:

The web content administration portlet should be expanded to allow selecting several web content in order to associate a preferred display page to all of them.

Also, from each page, it should be possible for the page administrator to retrieve a list of all web content that point to that page and edit all of them in one step to set a different preferred display page. This operation will be executed automatically also whenever the page is deleted.

For that we only need to extend web content portlet in Control Panel by adding new search options (search by Page) and then add new button next to Expire and Delete. I think this search (I don't know how it's done right now) should be based on Lucene not database queries and it should be done in such manner that developers can make their own search option (for example by WC structure fields which are already indexed!). I think such batch update option will be awesome also from marketing side - there are only few CMS that allow such thing to do

Jorge Ferrer:

A site administrator could potentially remove all asset publisher instances from a page that has been selected as the preferred display page of one or more web content. What would happen in this case when the canonical URL of the web content is used? Here are two possible solutions

1. Never allow this to happen. Whenever a page admin removes the last asset publisher, if there are web content pointing to this page, the portal will ask the user to which other page should those web content be associated from now on.
2. Dynamically add to the page an asset publisher portlet instance in the main column. In order for this to work nicely we would need each layout template to define which is the main column.

CMS is not a toy. If you remove last AP and you use full view feature you will know what will happen. Also option 1 would be nice but it's not neccesarry when we have in Control Panel ability to filter "Web content without a page"
Option 2 will be very frustrating if you want to remove all AP from Page (beacuse you want something else there) and Liferay will add AP for you. There will be many JIRA tickets for that

Let's keep it simple but usable

[Ray Augé, modificado hace 13 años.]

I still don't see how we decided the specific AP on a target page! Do potential APs also appear in the page selector as sub-nodes of the potential target pages? If we list the AP's this way, how do we identify the AP we actually want? By their name?

[Szymon Gołębiewski, modificado hace 13 años.]

Ray Augé:

By their name?

I think combination of portlet title and poprtlet ID will be better because often users change that title to something like "New articles", "Top articles". This will allow us to change name of our "Full page" AP to "Full view" and hide it so our readers won't see it

[Ray Augé, modificado hace 13 años.]

This solution suggests that Layouts will need to be indexed in order to support the searches required. That will be the initial dependency. But I've been meaning to do that for some time, so it will be good to get it done.

[Jorge Ferrer, modificado hace 13 años.]

Szymon Gołębiewski:

Jorge,

I will post here my answers as there is no "reply with quote" option in the wiki comments

Sure, sorry for not making that explicit in my post, but please keep the discussion in this thread. The forum is a much better tool for discussion. The wiki is just used to write the final decisions. For example, I've just edited it to change some aspects based on your comments

Szymon Gołębiewski:

Jorge Ferrer:

By default, whenever an asset publisher portlet is added to a page it will automatically become the preferred web content publisher if there is no other instance of the same portlet in the page.

I think by default this should be unmarked for such reasons:
* by default AP will not behave like in older versions of Liferay
* after upgrade / import pages will start to act differently - site administrator might be confused
* if you are building news Portal you will add many AP to the page but the chance that the first one will be used for full view is minimal but if you are building corporate site without this functionality you won't need that functionality at all. In both cases there are many obsolete "clicks". Let's do not do that "by default" action.

Ok, makes sense. The reason why I added that is because I'm concerned that users may not find this option if it's hidden in the configuration.

But we can probably find another solution for that issue. For example we are thinking of more intuitive ways to allow users to add content to a page so that they don't need to know that there is an application called Asset Publisher and that they have to add it to the page and then configure it. The current idea is to add a couple of new entries in the "Add" menu in the dockbar called "Content" and "Content List" and after they are selected the user is presented with a list of the most common possibilities (such as the ability to select or create new web content, documents, blog entries, etc, or the ability to select preconfigured asset publisher portlets). Considering this one of the common possibilities could be a "Content Placeholder" that is an Asset Publisher configured by default to be Preferred web content publisher.

I've changed this in the wiki page

BTW, how common do you think it will be to have a placeholder portlet that doesn't show any content except when it's referred to from a canonical web content URL?

I mean, will that be more common than reusing an Asset Publisher instance that by default is showing something else?

Szymon Gołębiewski:

Jorge Ferrer:

The web content administration portlet should be expanded to allow selecting several web content in order to associate a preferred display page to all of them.

Also, from each page, it should be possible for the page administrator to retrieve a list of all web content that point to that page and edit all of them in one step to set a different preferred display page. This operation will be executed automatically also whenever the page is deleted.

For that we only need to extend web content portlet in Control Panel by adding new search options (search by Page) and then add new button next to Expire and Delete. I think this search (I don't know how it's done right now) should be based on Lucene not database queries and it should be done in such manner that developers can make their own search option (for example by WC structure fields which are already indexed!). I think such batch update option will be awesome also from marketing side - there are only few CMS that allow such thing to do

Sounds good to me. I was also thinking of providing a quick link to this functionality when editing the page, so that the user is not required to go to the Control Panel.

Szymon Gołębiewski:

Jorge Ferrer:

A site administrator could potentially remove all asset publisher instances from a page that has been selected as the preferred display page of one or more web content. What would happen in this case when the canonical URL of the web content is used? Here are two possible solutions

1. Never allow this to happen. Whenever a page admin removes the last asset publisher, if there are web content pointing to this page, the portal will ask the user to which other page should those web content be associated from now on.
2. Dynamically add to the page an asset publisher portlet instance in the main column. In order for this to work nicely we would need each layout template to define which is the main column.

CMS is not a toy. If you remove last AP and you use full view feature you will know what will happen. Also option 1 would be nice but it's not neccesarry when we have in Control Panel ability to filter "Web content without a page"
Option 2 will be very frustrating if you want to remove all AP from Page (beacuse you want something else there) and Liferay will add AP for you. There will be many JIRA tickets for that

Let's keep it simple but usable

I agree, but I think a good UI does its best to prevent its user from making mistakes. Note that in option 2 what I really meant is to add dynamically but only for that request. Kind of what we do in 6.0 when a site admin clicks "Add > Blog Entry" in AP. The Blogs portlet is dynamically added to the page so that the site admin can use its form.

Considering this, do you still think it's a bad solution?

Ray Augé:

I still don't see how we decided the specific AP on a target page! Do potential APs also appear in the page selector as sub-nodes of the potential target pages? If we list the AP's this way, how do we identify the AP we actually want? By their name?

The specific AP is what I've called the Preferred web content publisher. It will not be determined by the web content, which will only select the page, but by the page administrator.

I've decided to do this because I think that linking it to the web content would provide more flexibility than what it's really needed and would make maintenance harder. By linking the portlet only to the page, we leave the responsibility of deciding where in the page it will be shown to the page administrator who is the right person for that decision. Makes sense?

[Szymon Gołębiewski, modificado hace 13 años.]

Jorge Ferrer:

But we can probably find another solution for that issue. For example we are thinking of more intuitive ways to allow users to add content to a page so that they don't need to know that there is an application called Asset Publisher and that they have to add it to the page and then configure it. The current idea is to add a couple of new entries in the "Add" menu in the dockbar called "Content" and "Content List" and after they are selected the user is presented with a list of the most common possibilities (such as the ability to select or create new web content, documents, blog entries, etc, or the ability to select preconfigured asset publisher portlets). Considering this one of the common possibilities could be a "Content Placeholder" that is an Asset Publisher configured by default to be Preferred web content publisher.

BTW, how common do you think it will be to have a placeholder portlet that doesn't show any content except when it's referred to from a canonical web content URL?

I mean, will that be more common than reusing an Asset Publisher instance that by default is showing something else?

Such list of preconfigured portlets would be a very nice option in the short version of add menu. In the full menu all should stay the same.
Also one question don't know is it right place) - why Web Content List double functionality of AP? Can it be "merged" into AP? This will simplify a list of portlets and help users beacuse currently they don't see a difference between those two portlets.

For the same reason I think that Place holder portlet should be made as preconfigured AP.
I think "Full view placeholder" will be used in 30-40% cases beacuse if you use it you must define separate page for "view". For the rest (corporate sites, simple layout sites or even static pages like "about us" on news portals) users will use existing page for displaying full view so normal AP (with fallback to "show normal list of articles") will be sufficient.

Jorge Ferrer:

Sounds good to me. I was also thinking of providing a quick link to this functionality when editing the page, so that the user is not required to go to the Control Panel.

On December we did some research on how users use Liferay (frontend and control panel). For 3 days we tested group of 24 people in age 25-50yr and we saw such problems:
1. There are mamy translation related problems.
For example "Post reply" mean an action (verb). After translation to Polish we have "Odpowiedź" which means "Reply" (noun) but it should be "Odpowiedz".
2. Ideology of Liferay is different from most applications known to our users (blogging platforms other CMS application) where you assign article to page and then you can make boks that will display articles "from selected node and children folders". Liferay puts things in one big bag and then AP select what they want to show. That was a very big problem in the start but after some explanations from teacher they learned how to use it. Suggestion: let's add to all guides or LR books a page or two about that idelogy but using some nifty metaphores. In my case I've used "bag" and "sifter"
3. Liferay is overloadded with options, buttons, links etc.
Good example is ability to add webcontent from AP. Users saw the same fields as in Control Panel but they didn't know is is right to add articles by AP portlet or should they use Control Panel. Forum displayed so many options next to every post that users were overhelmed and used only "Post Reply" - measured usability of Liferay forum was lower than usability of PhpBB forum!

So when you write "quick link to this functionality when editing the page" I hope that you mean link that will forward them to Control Panel with preconfigured search filters not another strange layer, button, window etc.

Jorge Ferrer:

I agree, but I think a good UI does its best to prevent its user from making mistakes. Note that in option 2 what I really meant is to add dynamically but only for that request. Kind of what we do in 6.0 when a site admin clicks "Add > Blog Entry" in AP. The Blogs portlet is dynamically added to the page so that the site admin can use its form.

Considering this, do you still think it's a bad solution?

But in case of Blog Blogs are added only for the time of adding new blog entry. When site admin removes last asset we will dynamicaly add new one for him? That can be frustrating.

IMHO it would be better to add a layer with message "You are removing last of AP dedicated to displaying you #145 web contents. After removal they will be orphaned and will display in full view on page where user clicks them. If you want to reasign them use ##control panel for web content##"

Jorge Ferrer:

Ray Augé:

I still don't see how we decided the specific AP on a target page! Do potential APs also appear in the page selector as sub-nodes of the potential target pages? If we list the AP's this way, how do we identify the AP we actually want? By their name?

The specific AP is what I've called the Preferred web content publisher. It will not be determined by the web content, which will only select the page, but by the page administrator.

I've decided to do this because I think that linking it to the web content would provide more flexibility than what it's really needed and would make maintenance harder. By linking the portlet only to the page, we leave the responsibility of deciding where in the page it will be shown to the page administrator who is the right person for that decision. Makes sense?

I think Ray was asking "If we have on one Page two APs marked as Preferred web content publisher how we will distinguish them in WC editor". In my opinion there will be only few cases when one Page has many Preferred web content publisher. After re-thinking that I say let's stick with possibility to place only one Preferred web content publisher per page.



I think that this solution / feature is great.

[Jorge Ferrer, modificado hace 13 años.]

Hi Szymon,

Thanks again for your answers.

Szymon Gołębiewski:

Also one question don't know is it right place) - why Web Content List double functionality of AP? Can it be "merged" into AP? This will simplify a list of portlets and help users beacuse currently they don't see a difference between those two portlets.

Agreed. We have plans to rewrite "Web Content Display" and "Web Content List" as preconfigured Asset Publishers for 6.1.

Szymon Gołębiewski:

For the same reason I think that Place holder portlet should be made as preconfigured AP.
I think "Full view placeholder" will be used in 30-40% cases beacuse if you use it you must define separate page for "view". For the rest (corporate sites, simple layout sites or even static pages like "about us" on news portals) users will use existing page for displaying full view so normal AP (with fallback to "show normal list of articles") will be sufficient.

Ok, sounds good to me.

Szymon Gołębiewski:

On December we did some research on how users use Liferay (frontend and control panel). For 3 days we tested group of 24 people in age 25-50yr and we saw such problems:
1. There are mamy translation related problems.
For example "Post reply" mean an action (verb). After translation to Polish we have "Odpowiedź" which means "Reply" (noun) but it should be "Odpowiedz".

We have a volunteer translator for Polish called Tomasz (see http://www.liferay.com/community/wiki/-/wiki/Main/Liferay+Translation+Team#section-Translation+Team-PolishPl) that helps review the keys and try to avoid such mistakes. Maybe you can help him by fixing this mistakes and sending a patch?

Also note that Liferay has an infrastructure to specify when a key is a verb or a noun. For example, in that case the JSP could specify <liferay-ui:message key="reply[verb]"/> and then in those languages where there is a difference they could have a different translation for that key than for the regular "reply" key.

Szymon Gołębiewski:

Good example is ability to add webcontent from AP. Users saw the same fields as in Control Panel but they didn't know is is right to add articles by AP portlet or should they use Control Panel. Forum displayed so many options next to every post that users were overhelmed and used only "Post Reply" - measured usability of Liferay forum was lower than usability of PhpBB forum!

That's very interesting. We've been recently talking about the complexity of the message boards and how to solve it. Keep tuned for more information on our conclusions. We'd love to receive your feedback too.

BTW, do you have any report on this usability tests that you would be able to share?

Szymon Gołębiewski:

So when you write "quick link to this functionality when editing the page" I hope that you mean link that will forward them to Control Panel with preconfigured search filters not another strange layer, button, window etc.

I know what you mean. We want to balance the potential confusion that appears when there is more than one way of doing things with the drawbacks of forcing users to go to the Control Panel for everything (which many users don't like because of the loose of context).

The solution we've decided to apply, and will be increasingly used in 6.1 is to have portlets open an overlay (like the one for portlet configuration) that shows a "limited" view of the Control Panel that shows directly the operation at hand.

For example, the asset publisher "Add" button has already been modified in trunk to apply this idea. Now when it's clicked an overlay appears with the form of the content to be added. The overlay's title will make it clear that it's part of the Control Panel and it will also provide a link to access the "full" control panel if desired.

Szymon Gołębiewski:

Jorge Ferrer:

I agree, but I think a good UI does its best to prevent its user from making mistakes. Note that in option 2 what I really meant is to add dynamically but only for that request. Kind of what we do in 6.0 when a site admin clicks "Add > Blog Entry" in AP. The Blogs portlet is dynamically added to the page so that the site admin can use its form.

Considering this, do you still think it's a bad solution?

But in case of Blog Blogs are added only for the time of adding new blog entry. When site admin removes last asset we will dynamicaly add new one for him? That can be frustrating.

IMHO it would be better to add a layer with message "You are removing last of AP dedicated to displaying you #145 web contents. After removal they will be orphaned and will display in full view on page where user clicks them. If you want to reasign them use ##control panel for web content##"

I see what you mean, but I still think that a dynamically added AP for the request and only for the purpose of showing the content would be a better solution. I don't think it should confuse the site admin because he'll never see the portlet unless he uses the content canonical URL and at that point he will probably want to see it. A clear benefit of this solution is that even if the site admin makes a mistake the consequences would be minimized because the canonical URLs would still work and visitors will still be able to see the content and even more important, search engines won't think that the content is gone.

Szymon Gołębiewski:

I think Ray was asking "If we have on one Page two APs marked as Preferred web content publisher how we will distinguish them in WC editor". In my opinion there will be only few cases when one Page has many Preferred web content publisher. After re-thinking that I say let's stick with possibility to place only one Preferred web content publisher per page.

Got it. My idea is that such a thing would never be possible. Whenever an asset publisher is set as the preferred, if there was another asset publisher previously set as preferred it will stop being so immediately.

Szymon Gołębiewski:

I think that this solution / feature is great.

I'm very glad to hear that

Thanks a lot for your help defining it.

BTW, Happy New Year!!

[Szymon Gołębiewski, modificado hace 13 años.]

Hi Jorge,

Jorge Ferrer:

We have a volunteer translator for Polish called Tomasz (see http://www.liferay.com/community/wiki/-/wiki/Main/Liferay+Translation+Team#section-Translation+Team-PolishPl) that helps review the keys and try to avoid such mistakes. Maybe you can help him by fixing this mistakes and sending a patch?

Also note that Liferay has an infrastructure to specify when a key is a verb or a noun. For example, in that case the JSP could specify <liferay-ui:message key="reply[verb]"/> and then in those languages where there is a difference they could have a different translation for that key than for the regular "reply" key.

Nice. Didn't know that.

Jorge Ferrer:

That's very interesting. We've been recently talking about the complexity of the message boards and how to solve it. Keep tuned for more information on our conclusions. We'd love to receive your feedback too.

Just tell me where to post

Jorge Ferrer:

BTW, do you have any report on this usability tests that you would be able to share?

We have some reports but:
1. they are in polish language
2. they containt some restricted information
3. We gonna do another round of tests at the end of January We gonna re-test forum and control panel to see how our fixes worked for users. So im thinking that after that last wave of tests I will prepare some report specially for you.

Jorge Ferrer:

I know what you mean. We want to balance the potential confusion that appears when there is more than one way of doing things with the drawbacks of forcing users to go to the Control Panel for everything (which many users don't like because of the loose of context).

The solution we've decided to apply, and will be increasingly used in 6.1 is to have portlets open an overlay (like the one for portlet configuration) that shows a "limited" view of the Control Panel that shows directly the operation at hand.

For example, the asset publisher "Add" button has already been modified in trunk to apply this idea. Now when it's clicked an overlay appears with the form of the content to be added. The overlay's title will make it clear that it's part of the Control Panel and it will also provide a link to access the "full" control panel if desired.

I've just checked that. Very nice but "add-new Web Content" title for that overlay doesn't infor about Control Panel at all Maybe it should be "Control Panel > Web Content > Add new". But I like that idea very, very much.

Jorge Ferrer:

I see what you mean, but I still think that a dynamically added AP for the request and only for the purpose of showing the content would be a better solution. I don't think it should confuse the site admin because he'll never see the portlet unless he uses the content canonical URL and at that point he will probably want to see it. A clear benefit of this solution is that even if the site admin makes a mistake the consequences would be minimized because the canonical URLs would still work and visitors will still be able to see the content and even more important, search engines won't think that the content is gone.

Maybe you're right. Let's see the first version and then we will continue (or not) on this topic

Jorge Ferrer:

BTW, Happy New Year!!

Happy New Year

[Jorge Ferrer, modificado hace 13 años.]

BTW, should I assume that other than for the comments above you both agree that the solution is good?

[Ray Augé, modificado hace 13 años.]

I think the solution is sound.

And, you are suggesting that a Portlet page have a property called "content target" sorry "Preferred web content publisher" which specifies the id of a target AP portlet on the page, set by the page designer!

Correct?

[Jorge Ferrer, modificado hace 13 años.]

Ray Augé:

I think the solution is sound.

And, you are suggesting that a Portlet page have a property called "content target" sorry "Preferred web content publisher" which specifies the id of a target AP portlet on the page, set by the page designer!

Correct?

Yes, that's exactly the implementation I was thinking of

[Szymon Gołębiewski, modificado hace 13 años.]

This topic was previously discussed here:
http://issues.liferay.com/browse/LPS-3028
http://www.liferay.com/community/forums/-/message_boards/message/2317379

Strange is that this feature is basic functionality in every CMS i now but in Liferay it was never developed :|

Ok, so now solution we made for our projects:
Portal tree (example.com) looks like this:
-- Home page (hidden beacuse we don't want to show it in menu)
-- Topics
---- Cars (look&feel: green)
------ Vans
------ Trucks
---- IT (look&feel: blue)
------ Hosting
------ Servers
------ Hi-Tech(look&feel: orange)
-- About us

And we have such web content:
1. "About Cars" (category: cars)
2. "About Vans" (category: vans, cars)
3. "About Batmobile" (category: cars, hi-tech)

For obvious reasons Vans and Hosting have different "look and feel".
Pages Home Page, Cars, IT contain many Asset Publishers in different configuration.
Cars will display articles with categories: cars, vans, trucks
Vans will display articles with categories: vans
IT will display articles with categories: it, hosting, servers, hi-tech
Hi-tech will display articles with categories: hi-tech
Home page will display articles from all categories.

On Home page we want to show in Asset Publisher newest articles. After selecting desired WC user should see it in proper template such as different column layout and different "Look&Feel".

Current problems:
1. Page tree is not related with Categories in any way
2. Asset Publisher can only display WC in his own maximized view.
3. Web content doesn't know what is his parent category / page he belongs to (I want to display "About Batmobile" in Hi-tech section of our portal).

Solution:
1. Add new field named "use for view" to Page properties
2. Add new field named "ID of Asset used for displaying full page" to Page properties
2. Add new field named "View page" to Web Content that will show list of pages with field "use for view" and store user choice.
3. Change in Asset Publisher the part of code where he is constructing "read more" link to use "View page","ID of Asset used for displaying full page"
VOILA!

New site structure:
-- Home page (hidden beacuse we don't want to show it in menu)
-- Topics
---- Cars
------ Vans
-------- view (use for view, hidden)
------ Trucks
-------- view (use for view, hidden)
---- IT
------ Hosting
-------- view (use for view, hidden)
------ Servers
-------- view (use for view, hidden)
------ Hi-Tech
-------- view (use for view, hidden)
-- About us (use for view)

Now I can show Batmobile article on "Home Page", "Cars" and "Hi-tech" and I know that after selecting "Read more" user will see full view of this article in Orange look & feel.

Q & A:
1. Why does Home page, Cars aren't marked as "use for view"?
Those pages are used on our portal just for grouping and showing different article listings from the pages / categories below.

2. So why does about us is not marked as "use for view"?
About us has simple layout with one Asset Publisher so we marked About us page as "use for view".

3. Why pages that are marked as "use for view" hidden?
That's because we don't want to show them in menu.

4. Are there any Cons of that solution?
Yep, there are some that we're still figuring out:
a) Even if your portal has one layout and look&feel for all articles full view you still have to define "view" page for almost every page in tree. That's because page position in tree is used in BreadCrumb so users will be confused if they see "example.com->IT" for articles that are in "Hi-tech" or "Hosting". Little help is that you can make new page and use "copy existing page" feature or make pages using "page templates" feature - this way all pages will use Asset Publisher with the same ID.
b) For "About Batmobile" breadcrumb will show "example.com->IT->Hi-tech->view" :|
c) There is no simple way to find Asset Publisher ID. You can use "Sharing" tab but javascript that marks all text in textarea will make you site administrators very angry.
d) How to handle "view" page or asset publisher deletion? Now, your articles will be orphaned (they will point to non existing page or asset publisher)
e) "Read more" link has "_blank" attibute assigned. This is bad on so many levels :|
f) Let's treat this solution as alpha release because of it's usability ;) There is sooo much clicking & configuring.

Proof of concept: http://liferay.eo.pl/web/guest

Currently we're thinking about such upgrade to that solution:
1. Mark asset publisher as "Show articles in full view"
2. Copy pages tree to category vocabulary named "use for view" upon "add page" action.

This will solve problems:
- described in point a)
- described in point c)
- described in point e)
and you still will be able to define different view page for "Hi-tech"

[Ray Augé, modificado hace 13 años.]

It seems the crux of the problem is around the full view url (obviously) and managing the target(s).

What if portlets themselves could be "categorized"? This could be used as "naming" for purpose of finding the appropriate target for a given asset.

From this point the Asset Publisher could calculate the matching target Asset Publisher based on the categories of the asset that match those of any potential matches, first best match wins.

Thoughts?

[Orin Fink, modificado hace 13 años.]

We have struggled a bit with this situation as well. Our solution is similar to the one mentioned earlier.

However, it _seems like there is a mechanism in the asset publisher that should handle the situation but may not be implemented fully. In the portlet "Look and Feel" configuration, you can specify an alternate page to send links to. Furthermore, in the asset publisher configuration, the option for "Asset Link Behaviour" shows us "show in a specific portlet".

Now, if these two settings are working together then a user should be able to select a _specific portlet from the page where the look and feel settings are saying to send the links.

Regardless, we did find a workaround using only the UI but it was a bit odd.

1) We created a sub-page of the page that had the asset publisher with the list of abstracts and when that page was created, we made sure to "copy" the parent page. This set us up with a second page that had an asset publisher on it but more importantly, the instanceID of that assets publisher was the same instance ID of the parent page.
2) We reconfigured the asset publisher on the sub page to have "Display style" set to "Full Content"
3) We then set the "Look and Feel" properties of the parent page asset publisher to point the links to the sub page
4) We set the properties of the asset publisher configuration on the parent page to "show in a specific portlet" and viola, it all worked. You can see the result here:

http://www.cmap.illinois.gov/full-circle/case-studies

So, all that being said, the fact that we have to rely on a second page to have asset publisher with the exact same instanceID as the asset publisher on the parent page seems problematic... when the "Show in specific portlet" is selected, we should be able to select the specific portlet to show the content in, based on the Look and Feel link behaviour that is set.

Make sense?

[Ray Augé, modificado hace 13 años.]

Again the problem lies in when you need assets in one Asset Publisher to target "different" target pages.

Like an aggregate view of all news... but then a sports/fifa article could if possible go to a page dedicated to FIFA. I think that needs to be part of the requirements if at all possible.

This is why the url logic should at some level allow for dynamic identification of the best possible target.

[Szymon Gołębiewski, modificado hace 13 años.]

Ray Augé:

It seems the crux of the problem is around the full view url (obviously) and managing the target(s).

What if portlets themselves could be "categorized"? This could be used as "naming" for purpose of finding the appropriate target for a given asset.

From this point the Asset Publisher could calculate the matching target Asset Publisher based on the categories of the asset that match those of any potential matches, first best match wins.

Thoughts?

1. You will have to "categorize" Asset Publisher using only one "Category" because i you will have AP with "hi-tech" and "cars" and "hi-tech" "cars" "vans" where will you display "About batmobile"? Editors don't like to rely on automatics because often what you get is not what you wanted.

2. You will have to display in WC editing page user readable listing of options to choose (display on page XXX) so you will have to store pairs of "Portlet ID & Page name" or just display it as category vocabulary. You can't rely on calculations made "on display" - you must match it on "Publish" action (also from performance reasons)

3. If you will use separate Category vocabulary for this and exclude this Vocabulary from Category Navigation portlet as it will be used only for defining full page view.

Orin Fink:

So, all that being said, the fact that we have to rely on a second page to have asset publisher with the exact same instanceID as the asset publisher on the parent page seems problematic... when the "Show in specific portlet" is selected, we should be able to select the specific portlet to show the content in, based on the Look and Feel link behaviour that is set.

Make sense?

This way you won't be able to point from one asset publisher to different pages (from Home Page to Cars and from Home Page to hi-tech)

[Ray Augé, modificado hace 13 años.]

Szymon Gołębiewski:

1. You will have to "categorize" Asset Publisher using only one "Category" because i you will have AP with "hi-tech" and "cars" and "hi-tech" "cars" "vans" where will you display "About batmobile"? Editors don't like to rely on automatics because often what you get is not what you wanted.

Hmm, the idea I had was to read the "query" details of any AP that closely match first, then evaluate the query to see if the asset matches, do this for any closely matching AP portlet in the com/org, and use the best match. I don't know why we would impose any limit on the match criteria. we would simply use the best match (not just the first close match).

Szymon Gołębiewski:

2. You will have to display in WC editing page user readable listing of options to choose (display on page XXX) so you will have to store pairs of "Portlet ID & Page name" or just display it as category vocabulary. You can't rely on calculations made "on display" - you must match it on "Publish" action (also from performance reasons)

Since we have the page and portletId from the preferences above, creating a redirect is simple. There is no need to store any data.

Szymon Gołębiewski:

3. If you will use separate Category vocabulary for this and exclude this Vocabulary from Category Navigation portlet as it will be used only for defining full page view.

I didn't think that using a different vocabulary would be nessecary, in fact, it reduce the chance of possible match.

Do you still all this is too risky? The idea would be to require very little work on the part of the page designer. All they need to do is configure APs and categorize assets. Everything else is dynamic.

[Szymon Gołębiewski, modificado hace 13 años.]

Ray Augé:

Hmm, the idea I had was to read the "query" details of any AP that closely match first, then evaluate the query to see if the asset matches, do this for any closely matching AP portlet in the com/org, and use the best match. I don't know why we would impose any limit on the match criteria. we would simply use the best match (not just the first close match).

Editors (people using liferay) won't now where they article (again my example "About batmobile") will be shown. Users, and only users must define what is "Origin page" of their article.

Ray Augé:

I didn't think that using a different vocabulary would be nessecary, in fact, it reduce the chance of possible match.

I don't want my readers to see those categories used for calculation. So I will remove permissions to view. But now my editors will be confused because there will be no way of knowing where their article will be displayed

Ray Augé:

Do you still all this is too risky? The idea would be to require very little work on the part of the page designer. All they need to do is configure APs and categorize assets. Everything else is dynamic.

I have portal with pages that contain 4 Asset Publishers. In your solution every Asset Publisher will do calculations. Let's say calculation for one web content is a 1 query to DB. Assets Publishers display 10 (in average) articles. That give us additional (comparing to now) 40 queries to database. Multiply that by pages on our portal and it will give us a huge amount of queries to DB :/ Also, as I recall finding best match based on multiply tags (on both sides: asset publishers set and web content set) is a complicated query (it will depend a little bit on algorithm you will use but still heavy).

So we gonna end with situation where best from performance point of view option is not so best from editors point of view. And again - editors will not know where their web content will be shown.

[Ray Augé, modificado hace 13 años.]

Szymon Gołębiewski:

Editors (people using liferay) won't now where they article (again my example "About batmobile") will be shown. Users, and only users must define what is "Origin page" of their article.

This is a good point.

Szymon Gołębiewski:

I don't want my readers to see those categories used for calculation. So I will remove permissions to view. But now my editors will be confused because there will be no way of knowing where their article will be displayed

...

I have portal with pages that contain 4 Asset Publishers. In your solution every Asset Publisher will do calculations. Let's say calculation for one web content is a 1 query to DB. Assets Publishers display 10 (in average) articles. That give us additional (comparing to now) 40 queries to database. Multiply that by pages on our portal and it will give us a huge amount of queries to DB :/ Also, as I recall finding best match based on multiply tags (on both sides: asset publishers set and web content set) is a complicated query (it will depend a little bit on algorithm you will use but still heavy).

Oh no!... I did not suggest this.

What I meant was, when the user clicks the link (if we chose the "new" option in the configuration "Show In Closest Matching Asset Publisher") we will direct first to an action which will at that point try to determine the best match (only one query, even if there are lots of asset publishers that might be close, but ideally we try to match as close as possible on first try), then we evaluate the logic of each portlet that might be a close match. At most we ever do one query, and it would happen only when users click the links to see full view.

[Szymon Gołębiewski, modificado hace 13 años.]

Ray Augé:

What I meant was, when the user clicks the link (if we chose the "new" option in the configuration "Show In Closest Matching Asset Publisher") we will direct first to an action which will at that point try to determine the best match (only one query, even if there are lots of asset publishers that might be close, but ideally we try to match as close as possible on first try), then we evaluate the logic of each portlet that might be a close match. At most we ever do one query, and it would happen only when users click the links to see full view.

Such approach is bad from SEO point of view because URL adres in href attribute must be known on page display not calcualted on click. Also another problem is when you change categories only in one Asset Publisher - this will change destination URLs for many articles. This one is mega-bad for SEO of portals (even if we use sitemap protocol).

And again - editors will be confused a bit more beacuse they finaly added proper set of categories to their article to show him on proper page ("About Batmobie" on "hi-tech") and then some frakkin' Site administrator changes configuration of one AP and now "Batmobile" points to "Sport"

[Ray Augé, modificado hace 13 años.]

Szymon Gołębiewski:

Such approach is bad from SEO point of view because URL adres in href attribute must be known on page display not calcualted on click.

I was afraid you'd mention this!

Szymon Gołębiewski:

Also another problem is when you change categories only in one Asset Publisher - this will change destination URLs for many articles. This one is mega-bad for SEO of portals (even if we use sitemap protocol).

Now this I had not thought of...

Szymon Gołębiewski:

And again - editors will be confused a bit more beacuse they finaly added proper set of categories to their article to show him on proper page ("About Batmobie" on "hi-tech") and then some frakkin' Site administrator changes configuration of one AP and now "Batmobile" points to "Sport"

Yeah, that could get frustrating.

So the rules should be more "near" the initial AP portlet (like in it's preferences), but still has to be dynamic enough to be able to go to different places based on categorization.

Is that correct?

[Ray Augé, modificado hace 13 años.]

Ok, so back to this!

Szymon Gołębiewski:

Solution:
1. Add new field named "use for view" to Page properties
2. Add new field named "ID of Asset used for displaying full page" to Page properties
2. Add new field named "View page" to Web Content that will show list of pages with field "use for view" and store user choice.
3. Change in Asset Publisher the part of code where he is constructing "read more" link to use "View page","ID of Asset used for displaying full page"

Can you explain exactly which entity you mean for each of these points? It's not quite clear to me.

[Szymon Gołębiewski, modificado hace 13 años.]

By "you must add" I mean "you must add something like Custom field" to Page and Web Content.

If by "entity" you mean something in Java then answer is "I don't know" I must ask my developers how they do it - I'm just the guy finding solutions not developing them

[Ray Augé, modificado hace 13 años.]

Thanks for your input Szymon! If you could ask that would help to clarify things a bit for us.