Hi Frank,
First of all, thanks fo all your suggestions. They are very appreciated. I've added comments for each of them below:
I must admit I had never thought something like that would be useful. In fact I'm not sure this strategy fits best with the way Liferay's permission system works. Also, the Control Panel may not be the only place from which it's possible to administer the portal.
I wonder if we should do something slightly different. For example, maybe what we could do is add a security control that limits the conditions under which certain users could login. For example, we could make it so that omniadmins can only login when doing it through a certain domain name. What do you think of this approach?
When we started designing the Control Panel I originally thought of it as two different UIs, one for the whole portal and one for each site. But then some people brought up that doing so could be very confusing for some people since it forces them to know ahead of time where is each tool. This could lead to going to the Site Control Panel only to find that what you're looking for is not there and so on (a typical usability issue in may applications).
Furthermore, in Liferay installations where there is only one site having two separate UIs makes little sense. Finally, there aren't really just two levels (site and portal), there are at least two more: personal and server.
So we decided to create a unified Control Panel with four different sections in the menu: personal, content (we thought it was a better word than site), portal and server. When you go to any item within content there is a selector that allows you to change the site (i.e, organization or community). One of the added benefits of this approach is that if you administer the documents (for example) of several communities you can quickly do so from a unified UI by using the selector.
Of course, it's not perfect either (not yet at least). I've observed that there are a few usability issues with people not noticing the availability of the "site" selector, or some confusion due to the fact that the selector is only shown when one of the items within content is selected. We are still looking for solutions to improve the user experience in these areas and any ideas are very welcome.
See the previous comment.
One similar request we've received is that in some types of portals it's confusing to leave a site to go to the Control Panel which has (sometimes) a very different look & feel. One suggestion was to use the them from the site from which you go to the Control Panel. But that also has the drawback that the same Control Panel would look different some times than others which is a known usability anti-pattern.
One solution that we've thought of as we were designing the Dockbar for 5.3 is making the Control Panel an underlay. That means that it would appear from the top, but and you could just close it at any time to see the site you were in. I really like this solution and hope to see it implemented soon. We've found some technical difficulties so it might not be in 5.3, but hopefully it'll be soon after.
This is already possible, but instead of being tied to sites it's tied to roles. IMHO, that's a more flexible approach.
Agreed, we need a tool to allow community administrators to list/search members and mange memberships.
Agreed. In fact I think those UIs should be improved in several other areas too. I would like to do some of that in the 5.3 SE cycle.
I'm not sure what you mean. It's possible to do that exactly where you specify: Control Panel > Portal > Settings
This is already implemented and will debut in 5.3
First of all, thanks fo all your suggestions. They are very appreciated. I've added comments for each of them below:
Frank Yu:
1. Regular logged in users and portal administrators share the same URL for Control Panel. In my case, it is
http://localhost:8080/group/control_panel?doAsGroupId=10829&refererPlid=10919. I strongly suggest that a separate URL such as
http://localhost:8080/admin/control_panel?doAsGroupId=10829&refererPlid=10919 is used for portal/organization/community administrators for better security. The critical administrative portlets in Portal and Server sections are available only if the URL is from /admin/... With this change, IT administrator can implement rewrite rules in Apache to block any access to the Portal and Server sections from the public network (since Liferay uses username/password based authentication in most deployments and administrator's credential could be hacked). This is very important for enterprise portal deployment in production, especially for mission critical systems such as financial or health portals. etc.
I must admit I had never thought something like that would be useful. In fact I'm not sure this strategy fits best with the way Liferay's permission system works. Also, the Control Panel may not be the only place from which it's possible to administer the portal.
I wonder if we should do something slightly different. For example, maybe what we could do is add a security control that limits the conditions under which certain users could login. For example, we could make it so that omniadmins can only login when doing it through a certain domain name. What do you think of this approach?
Frank Yu:
2. In addition to the portal control panel (at portal system level), provide a dedicated site control panel for each site (at Organization or Community level).
When we started designing the Control Panel I originally thought of it as two different UIs, one for the whole portal and one for each site. But then some people brought up that doing so could be very confusing for some people since it forces them to know ahead of time where is each tool. This could lead to going to the Site Control Panel only to find that what you're looking for is not there and so on (a typical usability issue in may applications).
Furthermore, in Liferay installations where there is only one site having two separate UIs makes little sense. Finally, there aren't really just two levels (site and portal), there are at least two more: personal and server.
So we decided to create a unified Control Panel with four different sections in the menu: personal, content (we thought it was a better word than site), portal and server. When you go to any item within content there is a selector that allows you to change the site (i.e, organization or community). One of the added benefits of this approach is that if you administer the documents (for example) of several communities you can quickly do so from a unified UI by using the selector.
Of course, it's not perfect either (not yet at least). I've observed that there are a few usability issues with people not noticing the availability of the "site" selector, or some confusion due to the fact that the selector is only shown when one of the items within content is selected. We are still looking for solutions to improve the user experience in these areas and any ideas are very welcome.
Frank Yu:
3. Use different color schemes to distinguish between a portal control panel and site control panel. This is a nice to have feature.
See the previous comment.
One similar request we've received is that in some types of portals it's confusing to leave a site to go to the Control Panel which has (sometimes) a very different look & feel. One suggestion was to use the them from the site from which you go to the Control Panel. But that also has the drawback that the same Control Panel would look different some times than others which is a known usability anti-pattern.
One solution that we've thought of as we were designing the Dockbar for 5.3 is making the Control Panel an underlay. That means that it would appear from the top, but and you could just close it at any time to see the site you were in. I really like this solution and hope to see it implemented soon. We've found some technical difficulties so it might not be in 5.3, but hopefully it'll be soon after.
Frank Yu:
4. Portal administrator can assign portlets (or other plugins) to a particular site. A site administrator can then add portlets to site pages from the assigned portlet pool. This is more desired if each site is for different customer (such as in portal hosting environment).
This is already possible, but instead of being tied to sites it's tied to roles. IMHO, that's a more flexible approach.
Frank Yu:
5. In portal control panel, all users can be displayed and searchable. In site control panel, only users who belong to this site (organization or community) can be displayed and searchable.
Agreed, we need a tool to allow community administrators to list/search members and mange memberships.
Frank Yu:
6. Implement search function on Plugins Configuration and Plugins Installation page. It is hard to browse to the right plugin when multiple pages exist.
Agreed. In fact I think those UIs should be improved in several other areas too. I would like to do some of that in the 5.3 SE cycle.
Frank Yu:
7. Provide GUI to change the default Liferay logo (at portal system level) to any desired logo on Control Panel > Portal > Setting page. The similar feature is available at Community level but not at system level.
I'm not sure what you mean. It's possible to do that exactly where you specify: Control Panel > Portal > Settings
Frank Yu:
8. The structures/templates in Web Content is available only in each organization/community. Please provide an utility to share (or at least copy) structures/templates across organizations/communities, including My Community (if enabled) of each power use. Please see a separate post at
http://www.liferay.com/web/guest/community/forums/-/message_boards/message/3997278.
This is already implemented and will debut in 5.3
Hi Jorge,
Thank you very much for your fast response with detailed explaination!
This approach should work. It serves the same purpose of limiting potential access to administrative portlets in Portal and Server sections in Control Panel and thus enhances portal security.
Interesting. Can't wait to see the implementation.
Sorry I didn't notice that it is on Display Settings page so this is NOT an issue.
Thank you. Great to hear this has been impemented in 5.3.
Thank you very much for your fast response with detailed explaination!
Jorge Ferrer:
Frank Yu:
1. Regular logged in users and portal administrators share the same URL for Control Panel. In my case, it is....
I wonder if we should do something slightly different. For example, maybe what we could do is add a security control that limits the conditions under which certain users could login. For example, we could make it so that omniadmins can only login when doing it through a certain domain name. What do you think of this approach?
This approach should work. It serves the same purpose of limiting potential access to administrative portlets in Portal and Server sections in Control Panel and thus enhances portal security.
Jorge Ferrer:
One solution that we've thought of as we were designing the Dockbar for 5.3 is making the Control Panel an underlay. That means that it would appear from the top, but and you could just close it at any time to see the site you were in. I really like this solution and hope to see it implemented soon. We've found some technical difficulties so it might not be in 5.3, but hopefully it'll be soon after.
Interesting. Can't wait to see the implementation.
Jorge Ferrer:
Frank Yu:
7. Provide GUI to change the default Liferay logo (at portal system level) to any desired logo on Control Panel > Portal > Setting page....
I'm not sure what you mean. It's possible to do that exactly where you specify: Control Panel > Portal > Settings
Sorry I didn't notice that it is on Display Settings page so this is NOT an issue.
Jorge Ferrer:
Frank Yu:
8. The structures/templates in Web Content is available only in each organization/community. Please provide an utility to share (or at least copy) structures/templates across organizations/communities, including My Community (if enabled) of each power user. ...
This is already implemented and will debut in 5.3
Thank you. Great to hear this has been impemented in 5.3.
