1) The login screen, even with the changes made to the current 2.4 source, still looks out of place. Why can't it be formatted using the Nphalanx theme? The style sheet and graphics are available. Besides, many systems that require logging on have a default (i.e., non-personalized) look for the login page.

2) In the Administration Portlet. In the tree view, select a portlet within a page. One the right side, click Theme. Three render options show up with drop-down list boxes. I have tried every combination of the options there, and there appear to be only 3 or 4 workable combinations (many combinations are even duplicates). Instead of having three options, make it a single ?Portlet window rendering? option with the choices a) show title and borders, b) show title, no border, c) show borders, no title (of dubious use unless the entire window is bordered, which it currently is not), and d) no title or borders. For the hard-code, you can still provide an 'Advanced' button to show the three rendering options.

3) Same location as #2. Display a graphic image that corresponds to the rendering option(s) chosen (this is made easier if you follow suggestion #2). This way the user can see how the portlet will be displayed without having to go to the page to see.

4) In the Administration Portlet. In the tree view, select a page. The drop-down list box of protlets can get very unwieldy. Instead, display the portlets in a table with columns such as portlet name, portlet display name, description, keywords, when deployed, etc. Allow sorting on each column (the drop-down list is unsorted, making finding anything difficult). Display only 10, 20 or 50 items (let user choose how many) and provide navigation buttons to move forward and backwards through the entire collection of portals. Also, provide a filter capability to show only portals whose name, description keywords match a search/regular expression. Also, provide a portlet preview capability where the protlet is displayed on a temporary page.

5) Same location as #4. Why is the 'center' column to the left of the 'left' column. Ask me how many times I have put portlets into the wrong location. Perhaps the better thing to do is display the selected portlets in an order that corresponds to their location on the page, perhaps with a border around each section on the page. This would given a better visual clue of how the page is laid out.

6) Same location as #4. Why is there only a single, fixed layout available? Why not provide more options. For example, offer the user a header, a footer, a center column, a left column, and a right column. Let the user turn each column off or on.

7) Same location as #4. Provide some mechanism for common functions on the same page that displays the selected portlets. For example, to remove a prtlet from the page layout I must first click on the portlet and then click the destroy button. Adding a delete button (next to the arrow buttons that move the portlet to a different location) would help. Other common functions might be the rendering option (especially if you follow recommendation #2).

8) Check the user interface against Firefox. Some things don't work. For example, tool tips for some icons which appear in IE don't appear in Firefox because the 'title' property was not defined.

I think the biggest thing that is needed for the portal is a WYSIWYG style page layout. While I think the current tree view in the admin portlet is a nice way to get a big picture view of "what is where" in the portal, it's not very intuative or user freindly.

Some of the other portals (EXO for example) has a way for you to visually edit the layout of the page. Dropping things is place using a visual layout engine. To be honest I haven't seen a open source portal that really does this great, but I have seen some that are a step in the right direction.

When I am building pages in jboss, I usually open two browser windows, one with the admin portlet and another showing the page I am trying to build. Everytime I make a change in the admin util I refresh the page I am building to see the results. I have seen other people using this same approach. This tells me that people really want a visual editor with (semi) instant feed.

Part of this request might entail making some sort of layout infrastructure beyond what JBoss Portal has to offer. What I mean is giving the user the ability to layout arbitrary containers with customizable sizing properties. For example giving them a container that will layout portlets in row or column order, being able to specify the number of rows or columns, specifying pixle or percentage widths to these containers.

Combining these two ideas would give the user to create any layout they desire and do so in a user friendly way. The current JBoss Portal layou engine locks the user into a predefined structure and the layout utility is not that user friendly.

While I abosutely love the stabilty, reliablity and general quality of the JBoss portal, I see this as one of the biggest areas I would like to see improved.

"PeterJ" wrote:Why can't it be formatted using the Nphalanx theme? The style sheet and graphics are available. Besides, many systems that require logging on have a default (i.e., non-personalized) look for the login page.

Right. Thats the way it used to be. I'll see if I can get that behaviour back for 2.6, or even 2.4.

"PeterJ" wrote:

In the Administration Portlet....

All items noted. The Admin Portlet will literally be gutted and completely redone for 2.6. Usability of that portlet is our main concern with it. If there is time, we also plan to introduce wizards.

"PeterJ" wrote:

8) Check the user interface against Firefox. Some things don't work. For example, tool tips for some icons which appear in IE don't appear in Firefox because the 'title' property was not defined.

"Frozen4Time" wrote:I think the biggest thing that is needed for the portal is a WYSIWYG style page layout. While I think the current tree view in the admin portlet is a nice way to get a big picture view of "what is where" in the portal, it's not very intuative or user freindly.

We actually discussed this idea for managing the layout of pages. You should see something of this nature in 2.6, when we introduce the ability for users to customize pages. Ideally, the same functionality can be introduced to the admin side.

Google, actually had something like this (drag-n-drop wysiwyg layout builder) in their first versions of their portal. For some reason, I can't find it anymore, but it was a killer feature.

"Frozen4Time" wrote:

For example giving them a container that will layout portlets in row or column order, being able to specify the number of rows or columns, specifying pixle or percentage widths to these containers.

A good idea, but it gets tricky. Layouts (# and names of columns) are currently defined in jsps, so this would have to change in to making layouts dynamic.

"Frozen4Time" wrote:

The current JBoss Portal layou engine locks the user into a predefined structure and the layout utility is not that user friendly.

True. The only workaround for now, is to have X# layouts deployed, allowing for the user/admin to pick whichever he wants.

Yes. Their new layout editting isn't wysiwyg. Before, they had an AJAX-powered editor, that would show a small representation of "yourpage" and you were able to drag-n-drop "portlets" on to it. You could even add new ones, or delete some from within the small representation.

Maybe the new one is more "useable". Don't know, I prefered the old way, but I could see how it would confuse most users.

I definately realize that the suggestions I made aren't all that easy and would require some redsign in the layout engine. I guess the point is that I understand the challenges. Never the less I wanted to make my suggestion.

An AJAX based lyout engine would be really nice, but it doesn't HAVE to be that dynamic. Even if the layout util has to make a round trip to the server when layout changes are made, that wouls still be nice enough. This is how EXO works. Its not AJAX, but when you add a container or portlet, an http request goes to the server and a new page comes back with the additions/modifcations.

This isn't quite as slick as the google editor, but it gets the job done. Basically, the key being that you are looking at the page while you are making changes to it.

The reason I have been mentioning EXO is because that is what I am currently using for a project. EXO isn't terribly stable, is a pain to install and hard to pre-configure. These are the things I love about JBoss portal. The only real hold up is the layout engine. The fact that you mention letting users layout their own pages says to me you guys are moving in the right direction since a portal user would expect a simple easy to use layout engine.

I am really trying to champion JBoss portal in my organization and these features would make that task much easier.

Being able to dynamically create any layout you want would be a big benefit, but as you say that would involve being able to cofigure this at runtime which would involve creating a lot of infrastructure as well as changing existing conventions. That being said I think it would be a great feature.

I also like to be able to have a fullfledged way of layouting my portal page via a flexible UI /layout model as is the case with Jetspeed ( a portal I otherwise do not like particularly well )

There you have pluggable decorators which can render your porlet frames (frameless window, framed window with insets etc..).You have pluggable page layouts ( three column, two column, etc...) to choose from.and so on. I don't find this in jboss portal. The "region" mechanism seems to be rather corse grained in comparison.

----

Another interesting thing I read about in the Jetspeed 2 Jira is their plan for a thingy they call Jetspeed Desktop:

This seems to go even a bit further than having an AJAX supported WYSIWYG portal page layout mechanism which helps to define a server side layout.

----

I've been musing about assembling the perfect collection of technologies for being able to deliver rich web clients while at the same time being standards based and being able to rapid prototype.

The fixed choices are that this should be portal driven, use Java Server Faces, Seam, Facelets, JSF-Avatar and EJB3.

The bulding-block that has been missing for years is that there does not seem to be a JSF component kit which satisfies all needs.Most kits work well in standalone mode (Apache Tomawhak, Oracle ADFFaces aka Apache Trinidat etc) but they fail to work well in collaboration with a portal framework and / or seam.Additionally, the component/render kits are not really satisfyable and robust. I would have to combine aspects from 5 different AJAX kits and another 5 JSF kits to satisfy my vision. (Tomawhak, Trinidat, Tobago, Dojo, Qooxdoo, Rialto, ZK, DWR, jMaki, etc. etc.)What currently happens is that some JSF component/render kit provider now try to integrate components from all these kits into their component library. This is the same type of misuse happening with multiple inheritance where any object which happens to have an interesting method is turned into a supertype...

In practice, it is not acceptable to download the javascript/html code for 20 AJAX and web frameworks before being able to look at a beautifully rendered page.I think the community is lacking a robust and satisfyable JSF component library/rendering kit. Everyone is doing some things right but no single vendor does it all right at the same time.- EXO alone supports WCAG 1.0- Tomawhak is a pot pourri of external scripts reused and doesn't support drag and drop etc..- ADFFaces is too invasive and doesn't integrate well with other supplementary technologies, so is the current version of SEAM.again, this list could be continued forever

Therefore I think that instead of providing halfhearted approaches for embedding JSF rich client frameworks which have not been designed with portals in mind by allowing header injections and the like, I'm thinking more into the direction of defining an XML GUI language that the JSF portlets would emit. The portal would then be responsible for rendering this meta language into javascript/html etc.

Again, there are many such XML GUI definition languages out there (OASIS' UIML, Netscape's XUL, W3C's XBL, etc...) but none is a satisfyable solution, probably because the contexts of these approaches are too different from the portal context. XUL was designed with thick desktop environments in mind. UIML is too old - the portal metaphor was uncommon then...)

I don't know whether JBoss/Redhat have enough resources to start off from scratch to design a real groundbraking JSF component/render kit, but lets assume that this is most likely beyond the focus: how can you impove your UI?I'm finding myself in the same spot: IF I revamp all the UI stuff I've done which will be a tremendous effort, then I want to do it right the first time and without compromises. I would need to have something at hand that supports drag and drop, client side validation, portal affinity, half objects, AJAX, etc. However, this can only be achieved by mingeling different things together and spending a tremendous effort doing so. That's why I don't understand why all the world is focussing on narrow focus frameworks like lets say an "AJAX toolkit" instead of working on a comprehensive JSF kit with out of the box support for the abovementioned.For example, it would be appriciable to have transparent AJAX support like the ingenious approach taken Avatar. I can only applaud Ed Burns for this approach. Of course, a JSF framework using this approach should be designed by keeping in mind that it also has to be usable in the context of portals...

Why am I saying all this? well because I would like to see that the JBoss Portal standard portlets like the CMS, administration or forum portlets are done using a JSF kit.But before conducting this migration, I believe that it is paramount to first work on a satisfyable JSF kit that has at least been designed with portal technology in mind.

---

Another thing I'd like to say is that sample apps always asume that developers will put all libs within their webapps. So lets do a hello-world app. All the Tomawhak, myfaces, SEAM and facelets libs go into the webapp. On the business layer side, you'd like to use JBPM and there you have another two libs to pollute your application. Your hello world app turns out to be 20 MBs in size for holding a single web page.This of course is not the usecase that is applicable for real world scenarios.However, one can spend weeks trying to arrange all the libs so that the technologies work well together and yet not find a way to do it.Therefore, one requirement I would like to propose is that JBoss provides samples that really match production environment use-cases in addition to samples which focus on showcasing technological aspects and therefore righteously trying to reduce unnecessary plumbing.

However, one can spend weeks trying to arrange all the libs so that the technologies work well together and yet not find a way to do it.

I menat to say: "... arrange all the libs OUTSIDE of one's JEE apps..."

Take a look at the SEAM samples. All the libs are always contained within the webapps. If I try to put all libs for JSF, JSF render-kits, Facelets, SEAM etc. into some JBoss location, some lib dir, or tomcat-lib dir, the whole shebang doesn't work. One will find that a webapp which only uses ADFFaces suddenly fails with a stacktrace that contains SEAM JSF listeners although the webapp uses an isolated classloader and doesn't use SEAM.... Problems like these keep me from really getting started with portals plus rich client stuff. I'd need to have guidance on how to best integrate several technologies. I.E. there should be additional sample apps which better showcase real-world usecases.

Those are real world use cases, but there are as many use cases as Java developers...

Self contained libs is the easiest way to deal with classloading stuff. We also realize that people do not want to copy/move libs around just to see an example running.

You can share libs, but your different web apps may require different versions of the same libs. we decided to provide shared myfaces libs in JBoss AS, it's cool for some people, it's a pain for others who prefer to embed their own libs.

yeah, I see your point. As you mentioned, putting libs into the app is the easiest way. What I am proposing is that JBoss provides guidance on how to deal with the shared lib approach for those developers who want to go the other way.

Let's say that there was one howto on how to install SEAM, Facelets, JSF, Tomawhak, Trinidat and jBPM into Jboss as shared libs and then deploy a portlet app which makes use of these technologies.

In this case, the effort of finding out how to do this was invested only once and the knowledge made available to all developers who then wouldn't have to find out for themselves one by one.

Stripping this configuration down can then be done easily I suppose because moving part of the libs from a shared mode into apps will probably not break anything.

so if there is an error in the portlet-instances.xml definition ("MyPtlet" instead of "MyPortlet"), the instance is set in a wrong way in the database, and it is impossible to get the management portlet to show the instances. It is not possible to suppress this instance in the management portlet, to have the new descriptor (corrected) used again.

what I did : stop jboss, suppress all the table in the database, correct the portlet-instances.xml, restart jboss.... not great... I've just realized I could have suppress the whole portal in the management portlet, and then restart JBoss, but even... it is not really nice...

a nice UI enhancement would be to include all widgets /regions usually found within a portal page.

For example, the current jboss portal demo pages have tabs and portlets but it is also common to have a breadcrump menu and a dynamic dropdown menu at the top region and to have a standard-but customizable approach for populating the dropdown menu and the tabs.