Honestly: I'll go with Adobe Flex. As a portlets 
(why? need to think...)
I had initially performance problems with Liferay 4.3.3 which disappeared after I configured Apache Portable Runtime for Tomcat and moved to BEA JRockit JDK 6, with 4 Gb memory and "-server" option.
And, performance issues of Liferay are mostly at the client side: AJAX. It is huge, it contains implementations of Collections and many more, and it is interpreter. For AJAX-based chat portlet, for instance, we need to use "heart beat" - some kind of "autorefresh", client-initiated pull. There is no server-side push possible...
Adobe Flash runs native code! And Adobe LiveCycle do push
to clients
JBoss Portal: I evaluated it this Spring, and the main issue: bad CSS quality.
Unfortunately it looks like Liferay Community is very small... many unanswered questions on Forum... Apache model with mailing list subscriptions is much better.
(why? need to think...)I had initially performance problems with Liferay 4.3.3 which disappeared after I configured Apache Portable Runtime for Tomcat and moved to BEA JRockit JDK 6, with 4 Gb memory and "-server" option.
And, performance issues of Liferay are mostly at the client side: AJAX. It is huge, it contains implementations of Collections and many more, and it is interpreter. For AJAX-based chat portlet, for instance, we need to use "heart beat" - some kind of "autorefresh", client-initiated pull. There is no server-side push possible...
Adobe Flash runs native code! And Adobe LiveCycle do push
to clientsJBoss Portal: I evaluated it this Spring, and the main issue: bad CSS quality.
Unfortunately it looks like Liferay Community is very small... many unanswered questions on Forum... Apache model with mailing list subscriptions is much better.
Luke j w:
Nope. Besides the obvious performance issues, the documentation just is not that good. This is true of most open source. Nobody wants to write it, and so the code becomes the documentation. For better or worse, not everyone can read through thousands of lines of code and understand precisely what is going on, and so I at least am a bit lost.
Absolutely agree. I have big problem right now, I urgently need to allow users post comments in my BLOG at Bambarbia's blog about BEA Workshop & Adobe Flex and "Add Entry" permission for Blogs->Permissions->Community does absolutely nothing.
Wiki is weak, forum is weak.
I need to check server logs, and to browse huge sourse code. And to modify (ppossibly) BLOG portlet, to fix bug. I'd be happy to do that and to commit changes (to publish at JIRA) but I am very afraid that some futures are simply advertised in a hope that it will be done later, if (commercially) requested. Another risk: learning path could be huge, and finally I can deside to move away.
Fuad Efendi:
Luke j w:Nope. Besides the obvious performance issues, the documentation just is not that good. This is true of most open source. Nobody wants to write it, and so the code becomes the documentation. For better or worse, not everyone can read through thousands of lines of code and understand precisely what is going on, and so I at least am a bit lost.
Absolutely agree. I have big problem right now, I urgently need to allow users post comments in my BLOG at Bambarbia's blog about BEA Workshop & Adobe Flex and "Add Entry" permission for Blogs->Permissions->Community does absolutely nothing.
Wiki is weak, forum is weak.
I need to check server logs, and to browse huge sourse code. And to modify (ppossibly) BLOG portlet, to fix bug. I'd be happy to do that and to commit changes (to publish at JIRA) but I am very afraid that some futures are simply advertised in a hope that it will be done later, if (commercially) requested. Another risk: learning path could be huge, and finally I can deside to move away.
For guest blog entries / comments, you need to edit blogs.xml under resources-actions. Currently the default in guest unavailable, so you won't be able to give them that option unless you change that xml file.
Andy W:
Thank you for this post. I am in the same position and looking for open source portal. What are your thoughts on metadot or dotnetnuke? It seems like dotnetnuke is the most common asp.net open source solution. It seems like the trend is moving more towards asp.net and it is easier to support. Thoughts?
Thanks,
Andy
I was looking for J2ee portals
Wow. Thank you all for the responses.
If liferay is reading this, perhaps this thread can help them. I suspect more than a few prospects have been turned away, afraid to ask this question.
We have now spent two days running Liferay, and are very impressed. Sure, it's got issues, but any product like it always does. Overall, the pluses seem to outweigh the minuses, but it's early in our learning curve. The granularity of permissions, the public private spaces, default page organizations, etc,. are all the best I have seen in any portlet, cms, to date. They are simple, clean, and rationale, with a minimum of clutter and forced design-think.
I'll see if I can get my engineer to post his experiences as we go along on a more technical level. I'm a mere designer.
My biggest quibbles thus are, are:
1) Forum seems largely unmoderated by skilled liferay people. That can really kill and open source effort, in my opinion. If they're making money supporting it, it would pay to throw something at the community. It will come back to them in spades.
2) The forums themselves less than stellar. I mean, one forum in English, with no subforums? Even shareware products with 100 users can do better than that. A standard PhpBB support forum, even badly run, can at least tend itself with 5 or 6 well chosen subforums. It makes administration of them easier, as the threads are more self organizing. And just the light text on dark background is a design no-no. The kind of board hackers love. Most professional forums will use a scheme that is actually readable to MOST sets of eyes. (It's a lovely theme, guys.. but forums are just not general purpose portal pages where style and flash should prevail. They are mostly text. And text is most easily read on light backgrounds, with dark text -- like this editor).
3) CSS styling seems a bit hard wired, and lacking in enough specificity. This will be another post, but what I mean is this. Almost every management and user screen uses tab widgets. The tabs are often multi level, with successive rows of tabsets, each using the same exact visual style. This is extremely awkward to understand visually. WHen I went to explore the CSS, i was expecting unique classes or IDs for each level of tabs, so they can be styled individually. Akk! Even tabset had the identical class names, and no class or attribute to signify level. This is a kind of lack of attention to interface customization detail that you can find in products like Drupal, Mambo, Joomla, etc. I was expecting better of an "enterprise quality portal" product.
Of course, I might have been missing something too. Just giving my impressions as i have them.
4) This editor blows chunks. It's slow, and in my opinion, editors that LOOK like Wizzy editors should actually be Wizzy editors
If liferay is reading this, perhaps this thread can help them. I suspect more than a few prospects have been turned away, afraid to ask this question.
We have now spent two days running Liferay, and are very impressed. Sure, it's got issues, but any product like it always does. Overall, the pluses seem to outweigh the minuses, but it's early in our learning curve. The granularity of permissions, the public private spaces, default page organizations, etc,. are all the best I have seen in any portlet, cms, to date. They are simple, clean, and rationale, with a minimum of clutter and forced design-think.
I'll see if I can get my engineer to post his experiences as we go along on a more technical level. I'm a mere designer.
My biggest quibbles thus are, are:
1) Forum seems largely unmoderated by skilled liferay people. That can really kill and open source effort, in my opinion. If they're making money supporting it, it would pay to throw something at the community. It will come back to them in spades.
2) The forums themselves less than stellar. I mean, one forum in English, with no subforums? Even shareware products with 100 users can do better than that. A standard PhpBB support forum, even badly run, can at least tend itself with 5 or 6 well chosen subforums. It makes administration of them easier, as the threads are more self organizing. And just the light text on dark background is a design no-no. The kind of board hackers love. Most professional forums will use a scheme that is actually readable to MOST sets of eyes. (It's a lovely theme, guys.. but forums are just not general purpose portal pages where style and flash should prevail. They are mostly text. And text is most easily read on light backgrounds, with dark text -- like this editor).
3) CSS styling seems a bit hard wired, and lacking in enough specificity. This will be another post, but what I mean is this. Almost every management and user screen uses tab widgets. The tabs are often multi level, with successive rows of tabsets, each using the same exact visual style. This is extremely awkward to understand visually. WHen I went to explore the CSS, i was expecting unique classes or IDs for each level of tabs, so they can be styled individually. Akk! Even tabset had the identical class names, and no class or attribute to signify level. This is a kind of lack of attention to interface customization detail that you can find in products like Drupal, Mambo, Joomla, etc. I was expecting better of an "enterprise quality portal" product.
Of course, I might have been missing something too. Just giving my impressions as i have them.
4) This editor blows chunks. It's slow, and in my opinion, editors that LOOK like Wizzy editors should actually be Wizzy editors
Matt Black:
1) Forum seems largely unmoderated by skilled liferay people. That can really kill and open source effort, in my opinion. If they're making money supporting it, it would pay to throw something at the community. It will come back to them in spades.
We are trying our best to keep up with the forum traffic. I hope that as all of you develop expertise in Liferay you will also be able to help out.
If you are using Liferay commercially our developer assistance options really should fit into a project budget reasonably well. Believe me, we really want to cultivate our community and don't want to force people to rely on commercial support, but if your clients are benefitting from the lower cost of Liferay we think it should be easy for them to put a little bit back into commercial support.
Matt Black:
2) The forums themselves less than stellar. I mean, one forum in English, with no subforums? Even shareware products with 100 users can do better than that. A standard PhpBB support forum, even badly run, can at least tend itself with 5 or 6 well chosen subforums. It makes administration of them easier, as the threads are more self organizing. And just the light text on dark background is a design no-no. The kind of board hackers love. Most professional forums will use a scheme that is actually readable to MOST sets of eyes. (It's a lovely theme, guys.. but forums are just not general purpose portal pages where style and flash should prevail. They are mostly text. And text is most easily read on light backgrounds, with dark text -- like this editor).
Regarding the forums, we used to have subdivided forums:
http://server-01.liferay.com/web/guest/devzone/forums/message_boards/category/40
But we found two limitations:
1. People would not always post to the appropriate places, and it was too much to have to try to move threads around and get that deeply involved in forum maintenance.
2. A lot of threads don't fall in neat categories but apply to several.
So in the future, we're looking at either working exclusively with tags and search for our message boards, or working with categories that can full under multiple parents (like Wikipedia, for example).
Regarding the design, we're actually working on a "white" version of the theme. We started with the dark theme with the intention of introducing the light version soon thereafter. Look for it in the next 2-4 weeks.
Regarding your points 3 and 4, I'll have to defer to the technical experts.
I have to say, I am a bit disappointed that more LR evangelists are not jumping into this thread. If others are like me, they are considering a pretty big commitment of time and money to Liferay, and it would be nice if some with a lot of real-world experience with it were sharing their experiencss here.
It was great of CEO Bryan to jump in for a few posts, and the documentation writer would be a nice addition, given all that business they are now doing Perhaps he or she could start with a "Getting Started" guide that reads better than the current "Customization guide," which is less than helpful in orienting a first timer in setting up a typical portal and "community," adding some users to it, giving them permissions, placing a few basic pages, etc.. And a simple default configuration "model" (or a few of them) that actually resembled a common site with users, a home page, and instructions on setting up all the defaults of a portal would go a long way to making this product convince people it was a solution to their quest (of finding a truly powerful, flexible, scalable, open source portal product). Most of us understand that details are always hard. But it would take a liferay staffer perhaps a day or two to write a "Step by step" set-up guide that could remove 90% of the drama of understanding this beast for we newbies. I think even some regulars would get something out of it.
I really don't mean to sound naive about open source (or unappreciative of this one). I've seen a lot of projects. The really successful ones always find a way to really kick-start that all important community. You can tell by the vicious fights swirling around them Maybe after an 8 year head start, maybe Liferay could start such a rumble. There sure is a lot of potential here. A few good documents would help at lot.
It was great of CEO Bryan to jump in for a few posts, and the documentation writer would be a nice addition, given all that business they are now doing
Perhaps he or she could start with a "Getting Started" guide that reads better than the current "Customization guide," which is less than helpful in orienting a first timer in setting up a typical portal and "community," adding some users to it, giving them permissions, placing a few basic pages, etc.. And a simple default configuration "model" (or a few of them) that actually resembled a common site with users, a home page, and instructions on setting up all the defaults of a portal would go a long way to making this product convince people it was a solution to their quest (of finding a truly powerful, flexible, scalable, open source portal product). Most of us understand that details are always hard. But it would take a liferay staffer perhaps a day or two to write a "Step by step" set-up guide that could remove 90% of the drama of understanding this beast for we newbies. I think even some regulars would get something out of it. I really don't mean to sound naive about open source (or unappreciative of this one). I've seen a lot of projects. The really successful ones always find a way to really kick-start that all important community. You can tell by the vicious fights swirling around them
Maybe after an 8 year head start, maybe Liferay could start such a rumble. There sure is a lot of potential here. A few good documents would help at lot.
Matte Black:
It was great of CEO Bryan to jump in for a few posts, and the documentation writer would be a nice addition, given all that business they are now doing
Hey Matt,
I'm the aforementioned documentation writer. Up until a month ago, I also was an end-user of Liferay, who ran into many of the same problems Joel ran into with the 4.2 -> 4.3 upgrade. In fact, he helped me out quite a bit as I was getting up to speed.
Our plans for the documentation include (for now) two books: a Liferay Administration Guide and a Liferay Developers' Guide. We've already worked up complete outlines for both, and I'm diving into the actual text as we speak. The Administration Guide will cover everything about making use of Liferay, from the install, to security administration (users / groups / roles) to portal administration (organizations, communities, pages) to the use of the bundled portlets. The Developers' Guide will cover everything about developing on Liferay as a platform, from plugins (portlets and themes) to the extension environment, to the Service Builder, Dynamic Queries, etc., plus some information on Liferay's archictecture. I've started with the Administration Guide: a 60 page first chapter on installing Liferay in all of its derivations (bundle, ext, and .war file) has already been written. In fact, I just finished up the docs for installing Liferay on WebLogic 10 yesterday.
We've collaborated internally on the outlines for these manuals, but in the spirit of open source, and working to be as transparent as possible to the community, I've posted the outlines I'm working from to the wiki here. I'd welcome any feedback (good or bad) from anyone who wants to contribute.
If you take a look at the outlines, you'll see that this is no small task, but we're undertaking it because we know it's a pain point and one of our obvious weaknesses. We'd like, however, to turn it into a strength. If it helps to get it into your hands faster, I would be happy to post the chapters (once we figure out the best place to do that) as I complete them, rather than making everyone wait until the books are complete.
Believe me, the community is important beyond measure to Liferay. I've seen that from both sides, as I once was just another member of the community, working to implement my own Liferay project at my previous organization. I received a lot of free help on the forums before my organization decided to pay Liferay for any services. And when I met several Liferay employees as a result of that, I saw firsthand how much blood, sweat, and tears are poured into this project every day, as well as how much hard work and dedication to excellence are exemplified by the people who work here. Yes, it has its failings, as nobody (and certainly no organization) is perfect, but I knew that this was an organization I wanted to be a part of. We certainly know our weaknesses (and the community helps to point us at the ones we don't know about :grin
and are doing our best to address them to the best of our ability. Thanks for posting this, Matt. It certainly has brought a lot of stuff out into the open!
Rich Sezov:
Believe me, the community is important beyond measure to Liferay. Thanks for posting this, Matt. It certainly has brought a lot of stuff out into the open.
Rich,
You're welcome, and glad to have you aboard! It's encouraging to see the doc writer Bryan mentioned, actually pop-up so soon.
Vaughan Schmidt and I have just started a Wiki for overhauling the Wiki Portlet. I am going to create a few others very soon, hoping to demonstrate that creating and maintaining Wikis is pretty easy, and that they can really help to consolidate a lot of the more coherent discussions of these issues, problems, tips and bugs. (Ironically, my Liferay project will include a tool for such work, but it's not ready for prime time, so the Wiki will have to do, for now.)
My next page will be a Liferay glossary (stub) page, which is something I am hoping you and the Liferay devs can all flesh out over time. It should include many non-Liferay terms, as well, since many people are unfamiliar with some nomenclature (portals v. portlets, etc).
While it's great that you're at work on "the books," and they will be a huge addition, I have to say that I agree with the comments above about a full- or part-time Liferay staffer who just works these forums. Such a cost would pay for itself many times over in terms of Google-able posts (advertising), topic moderation (community coherence), and overall goodwill (community public relations).
While we all love a good friggin manual (which we still won't read until absolutely necessary), in my opinion, nothing can replace a well organized set of forums, sticky posts, and both paid and volunteer moderators. One of the best open source forums I've used is that found at Aptana.com. Whether the staff is paid for their forum efforts, or not, there are many staffers involved, and the overall support is nearly immediate, and always outstanding. It's contributed nicely to Aptana's respect and awareness in the Eclipse-centric communities. Ubuntu's communities are pretty impressive too, and show how many sub forums can be made less chaotic with lots of volunteers chipping in.
I really hope Bryan will take this suggestion to heart. Even a two month trial of such a forum staffer would probably yield dramatic improvements in terms of site traffic, user posts, tips, general participation, and overall awareness of Liferay. And the latter can only go straight to Liferay's bottom line
One specific quote about topics for the forums: in the Can the admins add a HOWTO thread, Jorge Ferrer asked my advice as someone with a cognitive science background, and I wrote something more complex than what I wrote now:
What I would say now is a lot simpler: Liferay had a topic structure that was popular and worked well. Without excluding future tweaks and improvements, restoring the earlier set of topics has much to commend it from a cognitive science perspective, even if the earlier topics were designed without academic use of cognitive science.
Jonathan Hayward
Jonathan's Corner: A Glimpse into Eastern Orthodox Christianity
Jonathan Hayward:
Jorge Ferrer:Hi Jonathan,
It's nice to have a cognitive science expert around
We took that decision based on feedback from the community. But we can always reconsider adding some categories if the feedback is now in the opposite direction, as evidenced by the other two posts. Based on you knowledge of Liferay and cognitive science, what categories would you recommend?
Let me think so that I don't just give you something off-the-cuff or engineered without appropriate input. I'm not sure of exactly what the best division would be, but you might consider the following. (I'm not sure I'm the best person to make the decision, but this might feed into the decision: )
Three basic ways of dividing things are as follows.
Audience-based: in the case of a school website, "current students," "prospective students," "alumni," "faculty" would have different needs, and you can create a separate homepage for each. This is not terribly relevant here, as it seems that most posters make up one basic audience, people who are trying to understand Liferay well enough to accomplish basic tasks.
Subject-based: Material is broken down into what things are about: I would not reccommend a pure subject-based approach, but you could have subjects of "Portlet internals," "theme internals," "infrastrucure"...
Task-based: At least at my bank, the online banking is organized around things a customer might want to do: "check balance" (they made a good decision in having this be shown as soon as you log in), "view transaction history," "pay bills"...
It's a sort of "apples and oranges" comparison about which is better in general; if you've read Zen and the Art of Motorcycle Maintenance, you might remember where the author is describing two types of welders (those who want to keep in a familiar groove, and those who want new challenges to solve), and says that one is not better than the other, but if you hire a welder, you want the right kind for the work you need done so that there's a good fit. Each of these is ideal some of the time; what you want is a good fit.
The one other bit that I would add is that while each can be appropriate, it is usually not appropriate to mix approaches in the same list: you don't want to look at a store shelf and see "raisins," "dried apricots," "dried pairs," and "spark plugs," nor do you want links that say "customers," "employees," and "press releases." You can offer more than one of these, but there should be a good mix: Wal-mart does not confuse its customers by offering T-shirts in one area and food in another, but they have the sense not to put jars of pickles among the T-shirts. Fordham's theology homepage, on the right, has separate lists for three kinds of requests, and there's a big difference between clearly distinguished lists and one list that leaves the visitor unsure whether there is an audience-based or a subject-based classification.
With that stated, I don't think an audience-based approach would serve this community. Perhaps there's a difference between people who want to customize Liferay without modifying Java, and people who want to program in Java to make new Portlets and the like, and there is a difference between employees and customers, but my impression is that most of the people are customers who want to customize Liferay, and employees have other options besides the forum.
I believe that subject-based and task-based are both strong contenders, but I as a visitor would be less helped by an encyclopedia based on subject-matter (an encyclopedia could be good for internals), as a task-based approach. What would go into the categories would be something that would gracefully help people get the HOWTO-related material that they want.
What I would reccommend is that you or someone else at Liferay post a sticky note, responses allowed, asking people what the tasks are they are trying to support with the forum (ex: understand theme development well enough to make a custom theme, or fine-tune a theme the visitor wants comments on; troubleshoot an installation that is giving error message "_________" when the user is attempting such-and-such task.) I suspect that with a good list of current and past tasks, there will be a natural division into basic categories; maybe there will be more than one way of dividing, but in "data first" fashion I think that something arising from looking at the data would be better than what I could design my myself.
I think that a good task-based distinction, without ruling out subject-based, that is designed out of user responses would help people find what they want.
Jonathan Hayward
Jonathan's Corner: A Glimpse into Eastern Orthodox Christianity
What I would say now is a lot simpler: Liferay had a topic structure that was popular and worked well. Without excluding future tweaks and improvements, restoring the earlier set of topics has much to commend it from a cognitive science perspective, even if the earlier topics were designed without academic use of cognitive science.
Jonathan Hayward
Jonathan's Corner: A Glimpse into Eastern Orthodox Christianity
Sorry Jonathan,
A valid point. The word "portlet" would have clarified things. I just changed the wording of that post. See, if we had a portlet forum, that wouldn't have been needed
A valid point. The word "portlet" would have clarified things. I just changed the wording of that post. See, if we had a portlet forum, that wouldn't have been needed
Matte Black:
Sorry Jonathan,
A valid point. The word "portlet" would have clarified things. I just changed the wording of that post. See, if we had a portlet forum, that wouldn't have been needed
I decided to create a page for Wiki.liferay.com Content Overhaul.
Perhaps some of the people who have responded to this note can work with it.
Jonathan Hayward
Jonathan's Corner: A Glimpse into Eastern Orthodox Christianity
Joel Kozikowski:
I may some day use some of the other portlets that come with Liferay "out of the box", but right now, I have virtually no idea what most of them even DO! There is no place I can go to that says "Portlet X does this, and here is how you configure it." Many of the portlets are "proof-of-concept" portlets for demo purposes. Once I saw that, I just assumed most of the other ones were also, so I just disabled them all but the ones I really needed and could verify what they actually do.
Hey Joel,
This is definitely one of the issues we are addressing in the new documentation. To quote a politician I never liked much: I feel your pain (but I actually mean it).
I probably did the same thing most people do: download Liferay, bang around in it enough to see "on the surface" what it can do, and say "This is awesome! I am definitely implementing this!" The bundled functionality of wikis, blogs, forums, shopping carts, cms, user admin, etc., etc., just blows your mind when you first see it. It's like the holy grail of what most people are searching for is finally found: a piece of software that has all the features I need to run my web site built in! I don't have to muck around trying to integrate all these separate products! The problem starts when you have to actually start configuring things. For the portlets, right now, you have to just click around and figure things out. I have a web site outside of Liferay (predating my employment here) which uses Liferay's shopping cart. I can say that while I never experienced any bugs with the portlet (it does work well; my site sells stuff all the time and its Paypal integration--once you figure it out--works great), I would have saved a lot of time if I had had some guide on how to use it.
We are systematically going to go through and document the functionality of every portlet that comes bundled with Liferay. It's been a long time coming, and many of the portlets are now complicated enough that we cannot leave them out of the documentation. This is one of the reasons I keep saying we have our job cut out for us: it's going to be a big job. In fact, if anybody wants to lend a hand by writing a Wiki article on any of the portlets, it would be enormously helpful, as the sheer amount of text that needs to be written can be overwhelming.
In any case, I wanted to make sure that you knew this particular pain point is being addressed.
Joel Kozikowski:
I don't generally "complain" about things like I have been doing on this thread, but this seemed like a good time to release some pent up frustrations. Heck - I'm one of the Liferay advocates! Imgage what the LR haters are saying.
I know you don't. That's why you got my attention.
Like I said before, you helped me out quite a bit when I was trying to figure out Liferay. Because of your help (and others) on these very forums, I wound up implementing it not just for the tiny web site I mentioned, but also for the company I was working for at the time. But the learning curve was steep, even though I had the luxury of not having to divide my time between multiple projects. That's why I can identify with these frustrations, and ultimately, it's what motivates me to get these guides done. Joel Kozikowski:
Re: the documentation specifically - I'd recommend that part of the "portlet documentation" be a entry that specifies the "quality" and "intention" of the portlet. Is it a production quality portlet? Is it beta? Is its purpose for demo purposes only? That is important to know. Its easy to forgive "bad" code if it is CLEARLY marked as experimental, or new. A lot of this stuff is about managing expectations.
Noted.
Joel Kozikowski:
One suggestion about the Wiki and the Portlet docs specifically: one idea that I had was to write a small program that would generate a Wiki entry "shell" for each portlet in the system. Bascially, parse the portlet.xml and liferay-portlet.xml files and automatically generate a Wiki entry for each portlet. At least that way, you'd have a starting point. You'd also have a system that could be run (and re-run) with each new release. That way, if a new portlet comes along and someone (SHAMEFULLY) didn't document it, at least the Wiki entry would be there, and the "default" entry could say it was "Experimental" - at least, until someone got around to writing up the documentation, using it, and discovering that it really was "production" ready.
This is a great suggestion. My only concern (as is my general concern with the Wiki) is finding the information. Many people don't like the Wiki because the perception is that it's a bunch of articles thrown in there without any organization at all. We're working to address that (actually, that was being addressed before I got here), but it still to a large extent suffers from that. That's why I kind of see the Wiki as the "living" documentation, where we can stage information and then later present it to end users in a more systematic fashion.
Joel Kozikowski:
I run a separate site that has a similar situation (my primary business - on an old PHP PostNuke system that I would love to migrate to Liferay BTW). It has a LOT of content on it that has been accumulated over the last four years. For the old timers, your sort of know where things are stashed because you've seen it evolve. For a new user, however, its too easy to get overwhelmed.
Another reason to have a "newbie" doing the documentation. I don't know where a lot of this stuff is, so I have to dig up a lot of it by either finding it myself or asking people.
Joel Kozikowski:
I would suggest that that Wiki, or some other document, have a "Roadmap for new users", and a "Roadmap for developers" that is a hyper-page dedicated to guiding that new user to all the resources available.
Another great suggestion. I will put this on my to do list to implement, as I slog through the Wiki looking for content that can be adapted to the books. There's a lot of good content in there; this can help people to find it better. Have you seen the categories that have been created (primarily by Jorge, who is just a machine. I am amazed at how much he accomplishes.
The category list is here: http://wiki.liferay.com/index.php/Special:Categories
Michael Young:
For Liferay 4.4, we're putting the finishing touches on this abstraction, and in 5.0 we'll actually be plucking out portlets one by one. The only ones we'll leave are the core portlets (makes no sense to strip them).
Hey Michael! Welcome to the Jungle!
You may want to reconsider that last point (about it making no sense to strip the core portlets out). That is especially true if you separate the service layer from the presentation layer. IMO, the architecture of Liferay should look like this:
1) Core portal/portlet container
2) Plugable Service layer (including the defined entities)
3) Plugable Presentation layer (i.e. the portlets).
Right now, the direction things are going (which I REALLY like BTW), "2 and 3" end up in the same hot deployable .WAR.
Now, take my example from several posts earlier re: the Journal portlet (and my re-writing of it). My need is based on the need to "dumb down" some of the functionality for my end users. Basically, I've taken the Liferay journal model, made some decisions and done some "pre-developerment" regarding structures and templates, and then deployed for my end users. My end users don't have choices about things like which structure to used (its canned from their perspective), expiration dates, tags, etc. I've created a "simplified" portlet that gives them only what they need (basically, an editor).
So, in this use case, I make extensive use of the Journal service layer (i.e. I use its data structures, and its service interfaces for managing said data structures), but I don't use the portlets behind the scenes (well, actually in this case, I CAN - but they are reserved for "administrators" for whom I can trust to understand the advanced features).
Anyway - I could see a desire by the community to "plug in" a different user interface. If nothing else, I've found development in JSF to be much better (in terms of initial development as well as maintenance) than JSP+Struts. To some users, the underlying technology makes zero difference - they'll consume the portlets as is. To other shops that want to customize things, I could see one group preferring the JSF approach, and another preferring the JSP+Struts approach. Forget about the downside of maintaining two versions - leave that up to the community. What we need is the OPTION to have a different "Admin console" if we want it.
So, for maximum flexability, you may want to consider allowing the presentation layer to be deployed separately from the service layer.
Hey Joel
I think that makes sense. Even if the core portlets are not stripped out, what's keeping you from writing a new presentation layer as a pluggable portlet that consumes the core service?
I think the core stuff, like user admin, communities, my account, and page settings should stay.
What do you think?
I think that makes sense. Even if the core portlets are not stripped out, what's keeping you from writing a new presentation layer as a pluggable portlet that consumes the core service?
I think the core stuff, like user admin, communities, my account, and page settings should stay.
What do you think?
Michael Young:
Hey Joel
I think that makes sense. Even if the core portlets are not stripped out, what's keeping you from writing a new presentation layer as a pluggable portlet that consumes the core service?
I think the core stuff, like user admin, communities, my account, and page settings should stay.
What do you think?
Having used liferay commercially for 2 years, taken the pain of trying to customize it, I only have one piece of advice long term. Simplify, simplify, simplify. That for me means a simple small portal container containing zero portlets. Enable the portlets to be dropped in separately. This really is what I do for my own portlet development, deploying them as wars. Version 5 I really hope has the ability to start up the container with ZERO portlets whatsoever. I know you guys will probably think it should ship with core portlets, but believe me, people will always want to customize it in a way you can't predict. Why not give them the flexibility. My vote, strip out ALL the portlets if possible.
cheers,
Brian
Jonathan Hayward:
The single best resource I've read on information architecture is published by O'Reilly, and is called Information Architecture for the World Wide Web (presently in its third edition). If I may paraphrase what you've said, in that book's lingo, you're working to improve the wiki's information architecture. (Keep up the good work!)
Hey Jonathan,
Thanks for the pointer to the book. I may pick it up--it sounds like it will be helpful.
I also want to make sure that I note that I haven't been the one improving the Wiki's information architecture. I do plan on getting involved, but that's been the effort of others, and was started before I got here. The documentation has been a known issue for a long time at Liferay; I'm just the most recent addition to the effort.
Rich Sezov:
Jonathan Hayward:
The single best resource I've read on information architecture is published by O'Reilly, and is called Information Architecture for the World Wide Web (presently in its third edition). If I may paraphrase what you've said, in that book's lingo, you're working to improve the wiki's information architecture. (Keep up the good work!)
Hey Jonathan,
Thanks for the pointer to the book. I may pick it up--it sounds like it will be helpful.
I also want to make sure that I note that I haven't been the one improving the Wiki's information architecture. I do plan on getting involved, but that's been the effort of others, and was started before I got here. The documentation has been a known issue for a long time at Liferay; I'm just the most recent addition to the effort.
I'm still glad that you're working on it.
There are some ways where, in applying that book, remembering and knowing how an outsider thinks may be valuable, as well as having access to insider understanding of how things work. You might be well poised...
And thanks for passing along the note.
Thanks,
Jonathan Hayward
Jonathan's Corner: A Glimpse into Eastern Orthodox Christianity
