I have been doing some research and thinking lately about AJAX and how it might change (enhance) the portal world. There are two schools of though,
1. that it will revolutionize the way we develop and use portals, and
2. that it will simply provide additional capability for some portal applications.
I will say that all this new capability is definitely leading us toward heavier pages, for better or worse, I do not really know. I know it is changing the way we handle performance testing. The heavy pages slow down initial response times, especially as the browser tries to make sense of everything and spends time rendering the page. Fortunately, most of the bigger script files can be cached at the client to relieve some long term stress on the portal or web server. AJAX will also change the request pattern that is put on the appserver somewhat. Fewer page requests on the portal with smaller requests, repeated more often, from AJAX enabled components.
This growth also starts to blur the line between a separation of concerns in the development model, and the responsibilities of different layers in the system. I am still trying to work through where the line should be drawn between a presentation layer using JSF and the model, perhaps using a lightweight framework such as Spring. Moving more functionality to the client side confuses me again, but it is probably not all that bad, and we can still leverage whatever model layer we determine is appropriate. Definitely this is something we should watch as things evolve. I guess this is true with all types of applications, but since my focus is portal I tend to have blinders on sometimes.
On the lighter side, take a look at some of the cool things you can do with this technology around portals. Here are two portals that allow for very flexible portlet positioning. I think you will enjoy them.
I have to admit that I only spent a minute or two on each site moving portlets around. There may be more capability there, then I am aware of.
Portal in Action
Help create portal patterns @ <a href="http://www.portalpatterns.org" target="_blank">portalpatterns.org</a>!
As some of you may know, I have been toying with the idea of patterns in the portal space for a while now. Initially this involvement stemmed from a set of articles that I wrote for developerWorks on Portlet design and modeling. You can see this at: Modeling WebSphere Portal Portlets with UML - Part 1. ( You'll have to do a search to find parts 2 and 3.)
I have had a few requests recently, that I decided to refocus some of my effort in this area. I did some work last year trying to define a list of patterns that would be useful for folks as they started building their portal. The list has evolved a bit from my original work, and as it continues to evolve could definitely benefit from more refinement. I'm still struggling with what patterns actually mean in the context of a portal, but I usually do not let small points like that stop me from moving forward. : )
Customers are always asking for best practices when building applications or designing their site, and there appears to be some big holes around design and usability best practices for portals. Not only within IBM, but across the portal industry. I need this type of information myself, often when discussing the multitude of options that can drive new portal teams crazy. Since there was a bunch of information just sitting on my laptop, and not in a very re-usable form, I have decided to try and do some community building around this idea. I have launched a new web site called PortalPatterns.org. I am using MediaWiki to drive the site, it is very easy to use and is somewhat appropriate since Wiki's are probably the precursor to more recent portal frameworks.
The focus of the site is for listing and describing many (as many as possible) of the options that folks have available for building their portals and portal applications. It would be great if it could evolve eventually into a larger repository or could be used to collaborate on portal pattern languages. The site is also designed to be somewhat technology agnostic. In light of this I am using the term Portal Application, or Portal Application Pattern (PAP) to mean portlets. Which on different platforms could be portlets, widgets, gadgets, etc.. I do not belive that patterns of this type should not be tied to any particular technology or product, at least not initially. The implementation of different patterns will of course be different based on the technology, which will be addressed in the site also, by allowing for specific technological solutions to be discussed after the pattern description.
Anyway, I've mapped out what patterns I have so far and will start to actually describe each pattern as time allows. Check it out and join in the fun, or contact me if you have some ideas or information to offer![Read More]
Oh, way cool. Someone broadcast a question last week requesting information on how they might provide a simple (lower impact) user experience to low-bandwidth users who access the portal. My assumption in reading the question, was that some organization had a remote office (or multiple locations) with a slow connection or perhaps there were remote users dialing up into the system. In either case the IP address of this particular group of users is known and perhaps could be used to help achieve this request.
Like a good soldier I sent off a reply that perhaps they could use the IBM HTTP Server and setup some virtual hosts. Then they could use rewrite rules to redirect a specific IP address to a separate virtual portal setup in WebSphere Portal. This alternate virtual portal could use a different (stripped down) theme and display a smaller set of portlets which provide less functionality, but faster access to key information.
Then I thought! Hey, this should be documented as a portal pattern. I mentioned this idea in my last blog entry. I quickly came up with a name, identifying it as the "Low Bandwidth Access Pattern". I then added a more detailed description to the portalpatterns web site PortalPatterns.org - Low Bandwidth Access Pattern.
Having seen this question a couple of times over the years, I figured that by documenting it on a public site, I could refer folks there, instead of having to dig up old emails every few months. I often take that approach in this blog, by the way, when someone asks me a question that I think is broad enough to help other teams, or I have been asked a similar question before, I try and make an entry here and direct folks to that. Saves me from trying to save stuff somewhere where it will never be seen again.
I think PortalPatterns.org is going to be useful in this capacity. I encourage other portal experts who have the same issues or questions to participate in the site and record information that is helpful to everyone. For me I think the payoff is that I will not have to repeat myself as much, or that we can leverage information from different sources. The site pretty much has open access for everyone, but if you drop me a line I will gladly add you as sysops so that you can put your own spin on this important information.
Be aware that currently a lot of the patterns are defined, but I have not had time to really flush out the information, so it may be a while before the content is to a point where it needs to be, for the site to be really useful to folks.