Hi James,
I think first and foremost we should all acknowledge the fact that you're probbaly not going to get an impartial response to your questions -- not when you are it on a Liferay forum.
Clearly you are frustrated. I did actually read through your entire post -- but it took all my patience to do so. Opening comments like "Here is the issue. The UI absolutely sucks. Especially with Liferay 7" probably isn't the best way to solicit help from people on the Liferay forum -- people excited about the next release no less. You're also wrong by the way. If you have ever worked with any of the competing products you would know that Liferay's UI is far better than most. And before you go on a tear about "UX and Useability" I will state my opinion (wanted or not) which is that both those terms are as overused as "Architect" in this business. The fact remains that what is intuituve for one might be completely confusing for many others.
Now, to your question. First mistake -- as has been pointed out, is that you are using an Alpha version of the product. Liferay 7 is almost ready for release so I won't claim that any great changes are expected but if you want to use a stable version, 6.2 is what you should using, but I suspect you know that after 5 months of usage.
The next thing to consider is what you are working with. A portal is not the same as a monolith web application. A portal certainly makes some things a lot harder than just a plain old web app but the "harder" factor also comes with many other benefits that you do not get with a plain old web app. Some of the pain points you describe I think many of us would share and there are certianly features in Liferay that still leave me scratching my head as to why they are there, but portals have standards so sometimes these things exist in order to meet compliancy. So whether or not you should use Liferay is not a 20 minute conversation and really should be a task undertaken by someone who (a.) understands the benefits of the technology, (b.) the complexity that comes with those benefits and (c.) hask knowledge of the strategic direction of the business (and IT) to figure out if there is alignment there. From experience most people get into bad water as a result of one of two scenarios
1. They chose the portal without really understanding why you would or what a portal is. Usually this is the result of reading an article or typing "java portals" into google and not bothering to look beyond page 1 of the results
.
2. Java developers that approach portal archtiecture with the same hammer they use to build standalone monoliths. Portals are not the same so you can't always use the same paradigms. They think that they can get all the awesomeness of "plugins" but not have to do anything different. Then they get 6 months in and can't do something that is elementary in a regular java app because its not how a portal works. Rather than criticize the JSR standards, they simply declare that "Liferay sucks".
Neither of these cases are the correct way to select or use the portal and do no represent the power and benefits of the technology.
I'm not going to bother talking about the title bar complaint. It is easily remedied through configuration. Five minutes on google (or even this forum) would have revealed that to you. The permissioning system in Liferay is large and granular -- but very easy to use compared to many other products.
Rather than tell you "use it" or "drop it" I'll share with you some of my experience. I think I have almost earned industry dinosaur statu as I have about 20 years under my belt not -- and only the last 4 - 5 have included Liferay. A long time ago Java developers did things like dependency injection by hand. It was a sweet pattern that provided flexibility -- but boring to code because you do the same thing over and over again (yawn). Then someone came up with frameworks (like Spring) so that you get all the flexbility, but you don't have to do all the plumbing yourself. Liferay, for my tool kit, is like the next step in the evolution. I use the portal to build web sites and web applications -- it simply depends on my client's needs. The beauty is that it has a very rich and a very intuitive (semantic) api with simple patterns for extension. So once you get over the "JSR" standards piece and understand how portlets work, working with Liferay is a dream. The fact that you can literally change ANYTHING in it to meet your needs means I don't have to create a login process from scratch because my requirement has an extra field (when compared to the out of the box). I can hook it -- add the field, hook the action to recognize my new field and I'm done. All the encryption, the persistence, the servlet filters, the wiring, the auditing, the session management, the tokens, etc -- all handled for me. So Liferay, for me, takes care of the stuff that I don't like to do (or even that I might not be good at) and leaves me to focus on the requirements my client has. It is a PLATFORM for development. At leat that is how I see it. A lot of developers only see the requriements -- the functional requirements and give no thought to the things that are actually hard. Clustering, caching, threading, resource management, security etc. You get all that stuff for FREE when you use Liferay -- and that is not an insignificant amount of work.
Is it always super straight forward and Mickey Mouse? nope. Is there a learning curve? definitely (though it should get shallower with LR7). Have I been through more than one keyboard out of frustration sometimes? You bet -- though that honour is not limited to just Liferay
Closing thought. If Liferay is so difficult and unintuitive and not the right solution for websites, much less audiences with limited technical knowledge, then why would it be used for http://www.sesamestreet.org/ ... you don't get much simpler than gearing your site towards a child I think you should give it a chance and use the forums to get the guidance and help to push through problems. Of all the products I have worked with, this forum has some of the best support (I think).
I think first and foremost we should all acknowledge the fact that you're probbaly not going to get an impartial response to your questions -- not when you are it on a Liferay forum.
Clearly you are frustrated. I did actually read through your entire post -- but it took all my patience to do so. Opening comments like "Here is the issue. The UI absolutely sucks. Especially with Liferay 7" probably isn't the best way to solicit help from people on the Liferay forum -- people excited about the next release no less. You're also wrong by the way. If you have ever worked with any of the competing products you would know that Liferay's UI is far better than most. And before you go on a tear about "UX and Useability" I will state my opinion (wanted or not) which is that both those terms are as overused as "Architect" in this business. The fact remains that what is intuituve for one might be completely confusing for many others.
Now, to your question. First mistake -- as has been pointed out, is that you are using an Alpha version of the product. Liferay 7 is almost ready for release so I won't claim that any great changes are expected but if you want to use a stable version, 6.2 is what you should using, but I suspect you know that after 5 months of usage.
The next thing to consider is what you are working with. A portal is not the same as a monolith web application. A portal certainly makes some things a lot harder than just a plain old web app but the "harder" factor also comes with many other benefits that you do not get with a plain old web app. Some of the pain points you describe I think many of us would share and there are certianly features in Liferay that still leave me scratching my head as to why they are there, but portals have standards so sometimes these things exist in order to meet compliancy. So whether or not you should use Liferay is not a 20 minute conversation and really should be a task undertaken by someone who (a.) understands the benefits of the technology, (b.) the complexity that comes with those benefits and (c.) hask knowledge of the strategic direction of the business (and IT) to figure out if there is alignment there. From experience most people get into bad water as a result of one of two scenarios
1. They chose the portal without really understanding why you would or what a portal is. Usually this is the result of reading an article or typing "java portals" into google and not bothering to look beyond page 1 of the results
.2. Java developers that approach portal archtiecture with the same hammer they use to build standalone monoliths. Portals are not the same so you can't always use the same paradigms. They think that they can get all the awesomeness of "plugins" but not have to do anything different. Then they get 6 months in and can't do something that is elementary in a regular java app because its not how a portal works. Rather than criticize the JSR standards, they simply declare that "Liferay sucks".
Neither of these cases are the correct way to select or use the portal and do no represent the power and benefits of the technology.
I'm not going to bother talking about the title bar complaint. It is easily remedied through configuration. Five minutes on google (or even this forum) would have revealed that to you. The permissioning system in Liferay is large and granular -- but very easy to use compared to many other products.
Rather than tell you "use it" or "drop it" I'll share with you some of my experience. I think I have almost earned industry dinosaur statu as I have about 20 years under my belt not -- and only the last 4 - 5 have included Liferay. A long time ago Java developers did things like dependency injection by hand. It was a sweet pattern that provided flexibility -- but boring to code because you do the same thing over and over again (yawn). Then someone came up with frameworks (like Spring) so that you get all the flexbility, but you don't have to do all the plumbing yourself. Liferay, for my tool kit, is like the next step in the evolution. I use the portal to build web sites and web applications -- it simply depends on my client's needs. The beauty is that it has a very rich and a very intuitive (semantic) api with simple patterns for extension. So once you get over the "JSR" standards piece and understand how portlets work, working with Liferay is a dream. The fact that you can literally change ANYTHING in it to meet your needs means I don't have to create a login process from scratch because my requirement has an extra field (when compared to the out of the box). I can hook it -- add the field, hook the action to recognize my new field and I'm done. All the encryption, the persistence, the servlet filters, the wiring, the auditing, the session management, the tokens, etc -- all handled for me. So Liferay, for me, takes care of the stuff that I don't like to do (or even that I might not be good at) and leaves me to focus on the requirements my client has. It is a PLATFORM for development. At leat that is how I see it. A lot of developers only see the requriements -- the functional requirements and give no thought to the things that are actually hard. Clustering, caching, threading, resource management, security etc. You get all that stuff for FREE when you use Liferay -- and that is not an insignificant amount of work.
Is it always super straight forward and Mickey Mouse? nope. Is there a learning curve? definitely (though it should get shallower with LR7). Have I been through more than one keyboard out of frustration sometimes? You bet -- though that honour is not limited to just Liferay
Closing thought. If Liferay is so difficult and unintuitive and not the right solution for websites, much less audiences with limited technical knowledge, then why would it be used for http://www.sesamestreet.org/ ... you don't get much simpler than gearing your site towards a child
I think you should give it a chance and use the forums to get the guidance and help to push through problems. Of all the products I have worked with, this forum has some of the best support (I think).
We will start our own theme. From scratch. Using the _unstyled theme as a base and then writing our own CSS for any 'out of the box' portlets that we would use. I suspect this will be limited to Wiki and Message Boards...the rest of the portlets in our theme would be custom.
This is the best approach, at least I think, and about the only way I have ever delivered a project. The one exception I would say is that I tend to start with the _styled theme so that things like the dockbar, and configuration menu (in the title bar of portlets) etc still work. _unstyled creates, in my opinion anyway, a lot of additional work for you and is really only beneficial in situations where you want to disable most of the out of th things e box stuff. I hear what you are saying about the out of the box theme not really being general, but let's face it -- with every site having it's own branding and style, how the heck would you ever make a generic theme applicable to every scenario. I think the parts that are important that do (or at least should) overlap though liferay does provide, e.g. the classes for the responsive layouts. I would also add that if you stick to the aui taglibs as much as possible then it might make your life easier for some stuff (layouts, form fields, etc). Having said all that -- yeah, theming is a time consuming process. In case you haven't come across it yet, Emilio Berg has this awesome script that you can use to make your theme development much faster. https://github.com/emiloberg/Liferay-Instant-Deploy-Theme-Changes-Gulp-Script
The "dockbar" (in subsequently the user system) is intended and targeted a administrators of the portal. This means that we will write our own portlet to replace _145_portlet (dockbar) with the functionality we want, and in our portlet_normal.vm in our theme, we will not output or display the Liferay dockbar except if the user has a Role that is "Portal Administrator". Easy enough. Therefore, our application users that use the liferay authentication system will not be subjected to the liferay dockbar unnecessarily.
I can't say as I completely agree with this. The dockbar is supposed to be contextual based on your permissions and access rights. Administrator or not, for example, when you log in you only see the sites that you have access to. The things you might want to disable (for example the ability to add portlets to a page) you should be able to tune in the Roles configuration in the Control Panel. If you want to customize it, then there is nothing stopping you from wiriting a hook to do so -- however I will agree that sometimes it is easier to roll a simpler version that is your own than it is to hook an existing feature. Personally, I prefer to leverage as much of what comes with the portal as I can, particularly in an EE scenario where you have support.
All this said, I am glad to hear that you are giving Liferay a chance. Five months is certainly not an insignificant amount of experience with the portal (especially if you are working with it daily) but you're just warmin up. Five months from now I bet you would revisit this post with a whole different perspective on how to solve the same problem