Favorites is an in-development, one might say kind of radical feature.  It is being developed out loud and in public (mostly) on feature branches.  Adopters of uPortal 4.1 / Respondr will not be required to use this feature.

This feature is being developed (primarily?) by UW-Madison for use in the redesigned UW-Madison portal.

Favorites is a different way of interacting with layout.

Instead of (or in addition to) thinking about tabs and organization of portlets within columns on tabs (a dashboard-centric view), favorites thinks about favoriting individual portlets and collections of portlets (a one-portlet-at-a-time-maximized-centric view).

Instead of (or in addition to) adding portlets to one's layout, with Favorites, users add a portlet to their favorites.

Talk is cheap, where's the code?

Feature branch for favorites portlet: https://github.com/Jasig/uPortal/tree/UP-3896

Some features have come into this branch via pull requests, vis:

 * un-favoriting: https://github.com/Jasig/uPortal/pull/203

Got mockups / screenshots?

Note that some of these do not reflect the very latest code / design.

Design

Where are favorites stored?

Individually favorited portlets are stored in a DLM fragment folder of type="favorites".  Since it's a goofy non-regular type, it won't be rendered in traditional spots in the layout (it's not a tab).

Favorited collections (currently) are DLM fragment tab-level folders of type="favorite_collection".  Since this too is a goofy non-regular type, it won't be rendered in traditional spots in the layout (it's not a tab).

Thoughts: Possibly Favorites should be able to consider regular old layout tabs (type="regular") as favorited collections.  Possibly this should be a portlet preference allowing both approaches.  Which you'd want probably depends on whether you're trying to use Favorites instead of or along side of traditional tabs, whether and what layouts you're carrying forward from prior uPortal versions in your implementation, whether you're trying to offer respondr alongside of or instead of universality.  Anyway, Favorites doesn't do any of that yet – currently it's hard-coded to consider tabs of type="favorite_collection" as collections of favorites.

Viewing

VIEW mode UI lists favorites.  Users can click favorited portlets to launch that portlet by fname with MAXIMIZED window state. Users can click Collections of favorites view those collections as if they were focused-upon tab in the layout.

Editing

Edit UI lists all favorites, collections first then portlets.

In edit mode users can re-order individual favorites and favorited collections, subject to DLM precedence and re-ordering restrictions.

Items with deleteAllowed=true (DLM) are hyperlinks to ActionUrls deleting the layout node from the relevant favorites-modeling layout folder (type="favorites" or type="favorite_collection").  Trash glyph.

Items with deleteAllowed=false (DLM) are not hyperlinks and have tool tips explaining they are not deleteable.  Lock glyph.

Edit controller checks if signaled nodeId is deletable.  Adds errorMessage render parameter if needed.  Adds successMessage render parameter if success.

Adding to favorites

Add to Favorites is added to the per-portlet options menu:

Configuration

Turning it off

If a user doesn't have a folder of type "favorites" in their layout, the theme transform detects that fact and suppresses "Add to favorites" from the portlet options menu, since there's no folder into which to save the user's favorites.  This means that you can control who has access to Favorites by deciding to whom you direct DLM managed fragments with folders of type=favorites.  

If you publish the Favorites portlet and the folder of type=favorites to no one, then you can safely ignore the Favorites feature entirely.

You might gently introduce Favorites to a beta audience by only publishing the Favorites portlet to that audience and also only publishing favorites-type-folder-containing-fragments to that beta audience.

Integration with Marketplace

The Marketplace portlet is intended to be a good place for users to browse for favorites.  If you choose to implement Marketplace (or to substitute your own suitable portlet), you can tell Favorites the fname of your Marketplace portlet via portal.properties configuration.  When this fname is declared, Favorites will display the link to Marketplace in appropriate places.  When it's not declared, no worries, degrades gracefully.

Forced favorites, restrictions on re-ordering

Since individual favorites and favorited collections are merely usages of DLM layouts, DLM edit restriction apply. Because these types are goofy, the built-in admin UI tooling for editing these layouts and the restrictions on them just doesn't work.  However, you can edit the DLM fragments containing the template type=favorites and type=favorites_collection folders by editing and importing/exporting the relevant fragment-layout XML entity files.

Delete restrictions should just work.

Re-order restrictions will be goofy, since the Favorites edit UI currently only makes a partial effort to reflect DLM restrictions.  If it thinks you can't move an item at all, the move control is suppressed.  However, DLM is more complicated than that – conceivably you might be able to move an item to some drop locations but not others.  The UI won't reflect this and experimentation suggests that rules would only be enforced on next login.

Anyway, those ordering restrictions seem like false requirements.  If you actually have those requirements, please do get in touch and/or jump in to help implement support for them – our own feelings at Wisconsin are that we probably want to leave re-ordering wide open for end-user customization if they care enough to re-order.

Who's interested in adopting / working on this?

Tentatively interested parties: the Wisconsin crew (Jim Helwig, Tim Levett, Andrew Petro, Timothy Vertein), Aaron Grant / Oakland, Anthony Colebourne / Manchester; Unicon (Andrew Wills (Deactivated), James Wennmacher (Deactivated), etc.) on behalf of clients