This page lists the "user problematics" or "pain points" identified through the walkthrough exercises and from other sources. Where possible, each item in the list should link to a description of the problem it represents, any principles that apply, and the process through which it was identified -- e.g. the walkthrough exercise that revealed it. If there is a relevant Component Solution, that too should be referenced.
Everyone is invited to contribute to the list. While desirable, descriptions are not required.
My distillation of initial pain points - note that this is "to some extent" from a developer perspective, and is not from a walkthrough, but just "off the top of my head":
Portal views refer to the main ways in which the portal contents are displayed to the user.
An aggregator and distributor of pages and tiles based on user identity.
The abstract concept of a channel or portlet; the most primitive box of content.
A page is a container of one or more tiles. Pages are usually the primary navigation element (and are often rendered as and referred to as tabs).
The concept of tiles being self-contained and portal-agnostic, meaning that any tile should be able to be dropped into any portal that complies with the proper tile specification.
The primary view, where multiple tiles are stacked into a page.
As expanded below, each tile may have different size, view, context, complexity, functionality, interface, and content. This is both the value and curse of the portal. One tile might contain an integration to a large complex application like an SIS, while another tile is simply a list of URLs. Another tile might be web content pulled from outside the portal. Even between two tiles of similar type there is variance in approach. In the case of application integration - email for instance - one email tile implementation might make the default display only a summary of the number of new messages, whereas another might try to display the full inbox. An inbox is a large, complex interface. Imagine several large, complex interfaces stuffed into tight boxes, sprinkled with tiles of miniscule content swimming adrift in a sea of white space, shouldering alien content teleported in from the ends of the Web, all tiled together rather hodge-podge and pell-mell. Thus is the page view of most portals.
The portal really throws down the gauntlet when it comes to the user experience, a content Frankenstein that has yet to be tamed.
A secondary view, where the page real estate is given solely to one tile.
In a quest for portability of tiles, the portal and the tile contents have no communication. The portal can signal a focused view to the tile, but in many cases the tile does not pass that user action on to the tile. As a result, you get a focused tile view in the portal, but the tile contents remain in the same state they were in from the page view. Thus the end result is often a "maximized" tile view with "minimized" or "cameo" tile content view. In other words, the tile knows it has the full real estate, but the tile contents are dumb to the matter, resulting in a waste of interface. This problem also occurs in reverse. When leaving the focused view and returning to the page view, the tile knows to become "cameo", but the tile contents remain in whatever state it was in when focused.
The tile contents should grow with the focused view and shrink in returning to the page view; keep the tile contents context aware.
Each tile may have several views. The current standard for portlets, for instance, identifies four modes (View, Edit, Help, Custom) and four states (Normal, Maximized, Minimized, Custom)
Views, modes, and states are open to interpretation and are often optional, resulting in great variance and inconsistency of tile content between tiles in the same page and portal. User interaction (example clicking on "Edit") does not produce a similar result in all tiles.
Tiles placed into a shared environment (portal), should have similar and cohesive views.
A portal provides a point of integration with disparate applications. Often, the integration point is merely a few links or superficial data from the application. Because there is no further integration, trying to access other application functionality or data requires pushing the user into the application itself.