Background
A decade ago there was some understanding what a portal was. "All" content should be in. Some tried to put actual content in while others put links. There was a sense that customization was important, but anecdotal evidence the actual use of customization has been less than anticipated.
Why don't people customize? Was difficult, not obvious, not necessary, not important. Folks don't customize non-portal sites either. People are putting in minimal effort. Perhaps the portal could determine what you might use the most and customize based on that. Then again, maybe I don't want to first see what I use the most. It may also be difficult to detect what is actually used (since we cannot track eyeballs).
There is a difference between customization and personalization.
The big gain for the portal at some campuses was single sign on.
Campus visioning
started out as 7 members then ballooned to a large team trying to develop vision of communication on campus. The portal team looked at the priorities being single sign on and one stop shop.
View the portal as a dashboard. You are notified in the portal that actions need to be taken but you still go to individual apps to take actions. Portlets can be developed by app owners.
What about gadgets? The portal is a boxy type of framework. Seems dated. Is it still relevant given current user expectations?
Web 2.0, social networking, may not jive well with the Enterprise view of things. We have a large, diverse pool of users - not just young students. Some things of lesser value may only warrant a simple, easy access but it may be acceptable to invest more effort to access high value content.
Some schools look at the portal as an opportunity for propaganda. The dashboard/one-stop-shop gets them in the door. Too much propaganda will kill interest that has been generated.
Perhaps a navigation portlet is all that is needed. Browse to the portlet you want to use.
We also need to take integrators and administrators into account. Instead of having everyone write their own portal, make it easy for other systems to add their content into the portal. It is still too difficult to integrate content. It should not be more difficult to usee the portal framework then rolling your own app. If the portal framework is used as a standard, it reduces the number of frameworks in use and makes the apps easier to maintain.
If "everything's in the portal", it can be difficult to find what you are looking for.
It is difficult to share portlets when there is not a standard to develop against.
It is not clear to what level portlets support inter-portlet communication. It needs to be easy to build portlets. That said, the portal and portlets are not really a full application development framework. Portlets seem to be be suited to writing discrete points of functionality. It is difficult to create creative, complex applications using only the portal. At one point it was thought that the portal could be the UI layer of Server Oriented Architecture, but it has proved too limiting. It does seem to play a role with acting as a dashboard into your SOA systems.
The portal can play a role in bringing legacy applications together.
The original model for the portal is at odds with the current set of needs.
The uPortal market is limited because it requires a certain level of sophistication to actually deploy. Very small shops are looking for an install where you click next-next-next and select some check boxes that allow you to immediately install content.
There are many services and offerings out there that make it easy for you to quickly sign up for and use tools. These are often single focus applications limited in scope. Is there a way that we can make it just as easy for content providers to integrate with the portal?
Two types of content: 1) static html 2) application integration
St Francis wrote a tool that allows departments to insert content. Anyone (even students) can publish content and create groups that can access it. It is wide open.
UofI is developing tools that help delegate portal administration. They also developed an API that allows customers to write apps that will integrate well with the portal. Both of these seem to be custom types of content management systems.