Fall 2009 Day 1 - Portal Visioning

Owned by Jim Helwig
Last updated: Sept 28, 2009Version comment
5 min read

Characteristics of a portal:

  • what is a portal?
  • aggregate
  • single sign on
  • personalized, targeted
  • one-stop-shop
  • dashboard
  • "junk yard"
  • public/private graduated access
  • intranet
  • one portal to rule them all and in the xml bind them
  • thicker lipstick (shield users from institutional dysfunction by presenting unified enterprise)

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.

One campus started a visioning process with 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.

People are expecting that parents and other groups now have access to information. Some of this extends to having a personalized experience. If you want to draw people in, you have to create additional value.

The portal is a dashboard, but people think of the the collection of everything as a the portal if it has the same look-n-feel. Hard to distinguish the difference between the portal and intranet. This can be extended to include the public site as well. Your banks web site is public, but you can log in and then have it be personalized. What distinguishes the portal from everything else?

Everything became a portal. When you use the term, you had tot clarify it. It was used as a marketing tool. There never was a common understanding of what a portal meant. In general, most of us do not use the term 'portal' when we market our service to the end use. Users may not actually understand that there is a portal behind it. Other students see their learning management tool as a portal.

How do we get further involvement from service providers to add content into the portal and increase its value? This requires lowering the barriers to entry.

Branding and marketing is important. There are many different applications with portal-like characteristics. A central, campus portal can help reduce the confusion. It can help discourage other portals from popping up. UofI is looking at having their central portal have a departmental feel when you log in. It would recognize you and show the right department. It allows the departments to express their own brand. It is difficult to actually get them to create content. Start out small, let the complexity and right content come later. The portal should pull things together instead of eliminating other portals/sites/apps.

The portal is a place you can hide the complexity/dysfunction of the campus structure.

An agora. An open place of assembly.

One key is whether or not the portal is actually useful.

The user should have the ability to customize their preferences. What groups or types of content they see. Ability to block content. There is an institutional need to push out certain content. Sometimes it seems that our community is trying to make it easy to exclude content. It seems our communities are sometimes focused on excluding content instead of sharing and finding content. IT and higher ed communities seem unusual in their needs. If it is too easy to create and share content, the level of noise increases and the valuable content is lost.