The Favorites feature branch is now rebased to merge cleanly on latest
master.
https://github.com/Jasig/uPortal/pull/290
The noty notifications now play nicely with uPortal's header, incidentally.
On 4/10/14, 1:54 PM, Andrew Petro wrote:
Heh. The Marketplace branch merge to master caused this to need a
rebase. Looking into it. Anyway the pull request should already be
helpful for documenting the proposed changeset.
Andrew
On 4/10/14, 1:20 PM, Andrew Petro wrote:
And now the very exciting Pull Request:
https://github.com/Jasig/uPortal/pull/290
Andrew
On 4/7/14, 11:00 AM, Andrew Petro wrote:
uPortal developers,
We are cruising towards, but are not quite yet at, a Pull Request
proposing merge of the Favorites feature branch into Jasig uPortal
master towards uPortal 4.1. :)
Here's the freshly rebased feature branch:
https://github.com/Jasig/uPortal/tree/UP-3896
And the handy compare view:
https://github.com/Jasig/uPortal/compare/UP-3896
And the wiki page updated to document:
https://wiki.jasig.org/display/UPC/Favorites
AP> it might end up being preferable to invent an
@type="favorited_collection" or somesuch and differentiate the
concept of favorited collections from traditional layout tabs, to
enable having both working alongside one another.
Favorites evolved to using special layout folder types to model
individually favorited portlets and to model favorited collections.
Known issues:
0. Introduces noty notifications, as does Marketplace, so when
Marketplace merges to master, will get to rebase this again! Other
changes probably overlap with Marketplace meaning these branches
will need to be merged together onto master with some care, probably
with rebasing of whichever is second (likely, Favorites).
1. Introduces noty notifications, which seems to have an issue
playing nice with uPortal's header regions. I think Marketplace has
this same issue, so will probably only have to resolve that once.
2. I'd love to see https://github.com/Jasig/uPortal/pull/264
resolved so that Favorites edit mode works when Favorites is
maximized under respondr. That won't block proposing the merge, but
favorites is intended to be usable maximized. :)
Kind regards,
Andrew
On 1/22/14, 9:24 AM, Andrew Petro wrote:
Anthony,
Glad Favorites may line up with Manchester needs as well.
AC> there will be a concept of pushed favorites? i.e. the set one
gets at first login, based on group?
Yes. The technology certainly supports this, what with "favorited
collections" being just another view on "regular" folders, and
"favorites" being portlets in folders of type "favorites". So, you
can already provide different or multiple DLM managed fragments
with folders of type "favorites" and their merged contents will be
considered the user's favorited portlets and likewise whatever tabs
DLM pushes to them show up as their favorite collections.
Defaulting favorites came up tangentially in a design-flavored
meeting recently here, so I think it will end up being a real
requirement here at Wisconsin (something we actually use rather
than just something that the technology supports).
There's some technical issues to work out. If a user has multiple
folders of type "favorites" in their layout, which one does a newly
favorited portlet get added to? I imagine that also complexifies
re-ordering of favorites, which is not yet developed.
AC> It might be nice if you could also favorite any web content.
Might. It's something that's been discussed around here but I
don't think we have concrete plans around that yet. Offhand it
would complexify using the layout as the store of favorites. It
might be sufficient to provide some user experience sugar around
favoriting a portlet that has the behavior of redirecting to the
the desired web content on render as launched from the Favorites
portlet. This ties in somewhat with ideas for giving users a way
to get at their portlet settings (edit mode of subscribed portlets)
*other* than through chrome on and links in those actual portlets,
i.e., rolling up (links to?) edit modes in some kind of centralized
menu. Cf. what iOS does for some kinds of settings. This mockup, a
bit: http://navy8o.axshare.com/#p=settings
So. Favoriting things other than portlets and tabs aka
collections: not there yet but might come.
AC> I like the idea of a hybrid UI where we keep our existing tabs
but push the favorites portlets to the home tab.
Yeah. The direction we seem to be going locally is to *not* show
tabs, though maybe tabs come back when we all realize that
mobile-first doesn't mean desktop-never. :)
I do think it will need to be true that Favorites is implementable
with or without traditional tabs, and maybe that will drive having
to do something other than just treat "regular" folders as
favorited collections. While currently the portlet treats
@type="regular" tabs as "favorited collections", it might end up
being preferable to invent an @type="favorited_collection" or
somesuch and differentiate the concept of favorited collections
from traditional layout tabs, to enable having both working
alongside one another.
I'm also not completely thrilled with the current implementation
being wedded to the tab->column->portlet folder hierarchy rather
than being able to cope with other kinds of layout hierarchies, but
I figure that's a problem to solve when it becomes an actual
problem for someone.
AC> A home tab with favorites plus notifications/calendar/news in
my mind would allow us to keep some "portal like" features.
Yes. That's precisely the current rough design for re-designed
My-UW. The landing page, while not styled as a tab, is just such a
tab, providing several dashboard-y portlets in a dashboard kind of
experience.
AC> Also we could migrate uses BookmarksPortlet content.
Eh. Offhand I see Bookmarks as something different. Bookmarks
embraces tree-ness, at least my own bookmarks do. Favorites is less
hierarchical. But I'm open to being wrong about that. :)
AC> Finally my thoughts in this area lead me to think about a
custom window state like the windows 8 tile.
That's very interesting. To what extent can we make hay with
treating the plain old NORMAL window state as that tile? Favorites
creates a pretty natural opportunity to differentiate, in that if
launching a portlet from favorites launches it as MAXIMIZED, then
the portlet can use MAXIMIZED window state for that
I-gots-the-whole-window experience (yet implement responsive markup
so that that maximized experience is good across actual window
sizes), and can embrace a more reserved rendering in NORMAL window
state.
All that said, I think maybe part of the message of Responsive is
that UIs that respond to their window (or portlet container!) sizes
are the evolution beyond the blunt instrument of telling a portlet
how big it is with its window state. We may not need NORMAL,
MAXIMIZED, and TILE window states (or, at least, can use the very
same view implementations to handle all those) if the portlet UI
automagically arranges and styles itself for the container size it
finds itself rendered in. It seems like there would be a lot more
to be gained from pursuing such a "it just works" approach rather
than in creating a new window state and then cajoling portlets into
implementing it? :)
Kind regards,
Andrew
On 1/16/14, 4:51 PM, Anthony Colebourne wrote:
Hi,
This feature it exciting and timely for us. Great work.
I'm I right in thinking that there will be a concept of pushed
favorites? i.e. the set one gets at first login, based on group?
It might be nice if you could also favorite any web content. We
might push common external links such as our LMS and Email (OWA).
Also we could migrate uses BookmarksPortlet content.
I like the idea of a hybrid UI where we keep our existing tabs but
push the favorites portlets to the home tab. I think for this to
work well the portlet lookup approaches (gallery vs edit
favorites) would need to be merged.
Although I think the one-portlet-at-a-time-maximized-centric view
is prevailing (due I think to the mobile first approach that
really de-clutters the old dashboard world).
It pains me to move away from what was, the primary reason for
adopting portlet technology in the first place. Having said this,
the case for "uPlatform" is still very strong.
A home tab with favorites plus notifications/calendar/news in my
mind would allow us to keep some "portal like" features. Also if
the favorites portlet was "badge number" aware or broadcast some
useful portlet event for future extension/innovation then we
really begin to leverage the portlet paradigm.
Finally my thoughts in this area lead me to think about a custom
window state like the windows 8 tile. So this would be like a
favorites portlet on steroids can actually render favorite-ed
portlets in a well-defined "small and simple" UI container.
-- Anthony.
On 16/01/14 03:13, Andrew Petro wrote:
Hi All,
Favorites development is coming along.
There's now a wiki page for documenting:
https://wiki.jasig.org/display/UPC/Favorites
There's a feature branch for the favorites portlet:
https://github.com/Jasig/uPortal/tree/UP-3896
and a feature branch off of that feature branch for the
un-favoriting
capability:
https://github.com/Jasig/uPortal/tree/unfavorite_from_favorites_portlet
That un-favoriting bit is feeling ready for merge into the favorites
feature branch (with some technical debt noted), so it's now an
eminently reviewable and feed-back-able pull request:
https://github.com/Jasig/uPortal/pull/203
Kind regards,
Andrew
On 12/13/13, 2:50 PM, Tim Levett wrote:
Hi All,
At UW-Madison we have started creating a favourite framework
portlet.
It is a different way to view tabs. I've attached some screen
shots of
the initial landing page. We do plan on putting this into the
master
jasig branch soon.
Regards,
Tim Levett
UW-Madison
lev...@wisc.edu
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
