uPortal 2.6.1 generic screenshots

In which I share some screenshots of an unmodified uPortal 2.6.1.

This blog post is a work in progress

In order to make the attached screenshots available for viewing in a timely manner, I am releasing this blog post early and without benefit of a textual editing pass to introduce niceties such as consistent person and tense, rich hyperlinks to related material, and additional screenshots to tell a fuller uPortal story. As such, you can expect me to obsessively come back to this post and improve it in the coming days. In the meantime, I hope you'll find it worthwhile even in its present state.

Getting in touch with my inner pedant

First let me opine pedantically for just a moment that I think this exercise is a little silly. uPortal is not a product, it is a platform. The point isn't what it looks like and what it can do out of the box. This is why so many people adopted it even though out of the box is sported hues that might generously be called "pea green" for several releases through the 2.4 release. The point of uPortal is what it brings within reach of favorable cost-benefit ratios for implementation.

No one should run a uPortal that has not been re-skinned and re-branded to reflect institutional needs. Is this portal part of a larger initiative? is it a sober and serious administrative endeavor? Or is it a fun and wacky student portal? Is it a services delivery platform? Or is it an information delivery platform? Is yours a small portal or a big one? Student-centric, or learner-centric, or is it targeted to staff? Does it span a lifecycle cradle to grave?

Unicon's blessed with some talented designers and developers who skin uPortal regularly. I'd be inclined to make fun of their branding surveys (which ask stakeholders to identify feelings and abstract colors they associate with their portal project) if they didn't work so very well. But the surveys do work well and in every case I am personally aware of, the client has not merely been pleased with the resulting skin and brand: they have been delighted. Unicon's design, skinning, and branding services are a cost-effective way to help set appropriate user expectations and make your portal feel to be a central and connected part of your online campus.

Given that potential, the potential at modest cost to have a skin that makes your portal really sing, I have a hard time putting a lot of weight on what the portal looks like when one doesn't avail oneself of that customized skinning potential. It just seems to miss the point.

So this is just a little silly. It's not a lot silly. Certainly I see that it is worthwhile to make it easy to see what uPortal looks like out of the box and to better document its freshly installed features and behaviors. But if you're looking to understand the potential and value of uPortal, it's just as important to survey what people have accomplished with this framework when you do invest in skinning and customization and plugging in available portlets and channels, as it is to understand what building blocks the framework offers out of the box. It's important to understand the University of Wisconsin-Madison story of converting recurring portal licensing fees into investment in a customized uPortal instance and recovering those recurring costs ongoingly. It's important to understand the Rutgers story of portal as a compelling services delivery platform. It's important to understand the YaleInfo story and how a portal can be valuable even before users log in (even if they don't log in at all, because their need was met without logging in). It's important to understand the Trinity International University story of lightweight integration with a content management system. It's important to understand the Colorado story of surfacing PeopleSoft functionality in a compelling way in a campus portal. It's not about uPortal as product. It's about uPortal as platform.

Pressing onward: uPortal 2.6.1 GA generic screenshots

Point missed or not, the purpose of this blog post is to share some generic screenshots, and share them I will.

Portal Before Authentication

As has been discussed and presented upon, there is potential for deriving good value from uPortal even before the user logs in.

On initial render of the portal a uPortal deployer is greeted with a channel showcasing the DLM (Distributed Layout Management) administrators' guide. DLM is one of the most important features to understand in making the most of adopting uPortal and configuring it is a natural next step after bringing up a new uPortal instance, so it makes some sense that this is the first portlet greeting new deployers.

Once the portal is customized, using layout management and custom portlet plugins to put the right functionality into the portal for the use to which it is being put, this unauthenticated view on the portal can include arbitrary other information and dynamic content, e.g. quick links to frequently used campus web applications, news, and announcements. Yale University's uPortal demonstrates this approach to high value unauthenticated user experiences. Contrastingly, other uPortal deloyers (such as Rutgers University do not use the uPortal technology at all for the unauthenticated user experience, instead relying on lighter-weight web site technologies.

Logging in as the admin user

To get at those richer authenticated user experiences, the user needs to log in. Out of the box there's default administrative user account (named "admin").

By default uPortal validates usernames and passwords against a local account store table in the uPortal database, but it can be and is often configured to instead validate credentials against an enterprise directory or even to use enterprise single sign on technologies such as the Central Authentication Service.

Note that once the user has logged in, the portal can greet the user by name (in this case, "Admin User"), having drawn this user attribute information into the user session from the configured Person Directory subsystem.

One of the example tabs available to the admin user by default (and typically also granted to developer users) is a Development tab including a portlet snooping on the request headers, parameters, and attributes to provide context for understanding inputs to the portal, a portlet showing the portal's understanding of user attributes related to the current user (as drawn from the Person Directory subsystem, which is both configurable and programmatically extensible), and a simple demonstration of consuming syndicated news into the portal, in this case news from the uPortal project website itself.

The entertainment tab is an informal example of drawing other kinds of content into the portal and targeting it at particular user groups. It includes an image channel showcasing a daily cartoon, a web proxy to a simple but complete remote application (the number guessing game), and presentation of a Java Applet. The point here isn't that these specific channel usages are compelling -- they aren't even all that entertaining -- rather, the point is that it is easy to draw in these types of channels into managed fragments that are then presented to particular user groups.

(Incidentally, that cartoon reminds me of how use of open source software keeps costs low by forgoing expensive licensing costs and keeping the sales cycle cost if not as low as I would like, at least lower than it would otherwise be.)

Channels, Modes, and Events

I'd like to focus in for a bit on that silly little number guessing channel.

One common channel behavior to implement is focus. The portal theme provides an ability to focus on any channel using the focus channel control in the channel title bar. Additionally, channels can change their state to focused in response to interactions that may not include the end user explicitly clicking that focus button. In focus mode, in the default uPortal 2.6.1 theme, the channel title and controls are drawn into that top header portion of the page.

Many people are familiar with that number guessing game, but it might be nice to be able to get some help with using it. Channels can choose to implement handling for a help event and provide their own help UI. The number guess channel implements a trivial example of this. (While implementing help is a best practice, if your channel doesn't implement this or any other particular channel event handling, particular channel controls can be turned on and off on a per-channel-publication basis.)

While the number guessing game doesn't have end user preferences to edit, it does implement enough of a preferences editing view to demonstrate effective handling of the channel edit event fired by that "edit preferences" link.

Finally, channels can implement an "about mode" so as to offer credit where credit is due to the developers of the channel or offer users an ability to learn more about a channel.

These events and modes are features of the IChannel API (uPortal's custom plugin API) and have supported analogues in the JSR-168 Java portlet API. The number guess example is implemented particularly as an instance of the CWebProxy channel. The example supports these various modes by implementing URL endpoints implementing the various modes. The number guess channel configuration simply maps these modes and events to URL endpoints, sets some other configuration for the web proxy, categorizes the channel for easy end user browsing and discovery, and defining which groups are permitted to subscribe to the channel.

Administrators get at the channel configuration workflow via the upper left menu item (which is available only to sufficiently privileged users). This leads to a menu allowing editing of existing channels and creation of new channel instances, which is itself extensible with additional menu items as needed.

While channel administration is treated as a special case linked from that upper right navigation menu, much of the administrative functionality in the portal is built into the involved portlets and into special administrative portlets. In fact, by default, the administrative meta-user sees an entire tab of these sorts of portlets, including

Administrative functionality available via the admin tools fragment includes a groups management UI for exploring configured read-only group stores and for manipulating read-write group stores (such as the default store using the uPortal database), a channel for administration of uPortal's rich permissions management subsystem, and a simple channel for user account management.

Besides supporting uPortal-custom channel APIs and implementations, uPortal supports the JSR-168 Java portlet API and ships with several portlets and a fragment showcasing this support. The portlets fragment includes the University of Wisconsin-Madison bookmarks portlet, a free and open source JSR-168 portlet under collaborative development by members of the Java Architectures Special Interest Group, a simple Google search portlet, a configuration of the WSRP consumer portlet pointed at an occasionally hosted library search WSRP endpoint hosted in the UK, and an instance of the Pluto test portlet exercising the generic JSR-168 API support.