Seven years ago we developed what we called a Dynamic Menu Portlet which basically displayed a collection of bookmarks based on the user's groups. The idea was we could publish one portlet called, say, Academic Resources and the contents would vary depending on if you had staff, student or instructor roles. It is driven off of tables in the database and these tables could be populated via XML files in version control. The original code dump is available off of https://wiki.jasig.org/display/JSG/UW-Madison+Contributions.
Since Andrew has moved the bookmark portlet roadmap discussion over to the bookmarks-portlet-user list (which I am thinking would get more traction on portlet-user), the only reason I bring this up now is because it is a great example of how NOT to contribute code to the community. We developed this in isolation (when we should have been much more public about what we did), we just zipped up the code (instead of moving it into the Jasig/Apereo repository) and we basically sat by (instead of effectively publicizing what we did so that others would get more involved). We continue to learn from our mistakes and are trying to be much more actively engaged in portlet discussions, sharing what our thoughts are and looking for opportunities to collaborate. JimH Recent thread on the HRS portlets: http://jasig.275507.n4.nabble.com/intentions-for-HRS-Portlets-td4661313.html on 12/10/2013 5:51 PM Aaron Grant said the following:
I wouldn't mind seeing in the long term a way to pre-configure links for certain groups in this portlet (i.e. set of links for graduate students, another set for undergraduate students, etc). And of course then users could additionally add more custom links to whatever they desire. I've considered also adding a mobile theme for this portlet to make it easier to click on options on mobile devices. Although due to the low usage, this has been on the back burner. We have a pretty low usage rate for this portlet, maybe 300 total bookmarks for 20k users, although we really don't showcase this portlet either (it sits in the customized area only). With that said, I wouldn't mind if the portlet wasn't bundled by default and I would add it to our custom build process if that happened to keep this option in our portal. Aaron On Tue, Dec 10, 2013 at 6:03 PM, AUXEPAULES Ludovic <[email protected] <mailto:[email protected]>> wrote: About 300 bookmarks have been added by users in our portal since 09/2012. Our build incorporates Bookmarks Portlet via a Maven overlay (we use a lot this feature : >25 portlets in our "test portal"). There are two waiting pull requests on Bookmarks Portlet project? Best Regards, Ludovic Auxepaules -----Message d'origine----- De : [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]>] De la part de Andrew Petro Envoyé : mardi 10 décembre 2013 23:26 À : [email protected] <mailto:[email protected]> Objet : Re: [uportal-dev] Take BookmarksPortlet out of 4.1? Short version: > Would anyone object to removing (de-bundling) the BookmarksPortlet for the upcoming 4.1 release? I'd be a -0, favoring dropping from the ootb Welcome tab but not de-bundling for uPortal 4.1. ---- Long version: Yes, the bookmarks portlet UW-Madison uses is the Jasig Bookmarks portlet. Our build incorporates it via a Maven overlay along the lines of that shipping in ootb uPortal 4, so we could easily continue to include the portlet in our portal regardless of whether it remains bundled or not in ootb uPortal 4.1. I agree with Jim that it remains to be seen whether and how bookmarks portlet functionality carries forward into redesigned MyUW-Madison. Taking this past month as a random example and taking only a very quick, shallow look at the analytics: Madison's bookmarks portlet was the fourth most-rendered portlet in our portal for that time period. That's because it's on the default welcome tab, but it does mean at least users don't dislike it so much as to remove it from their layouts. :) I agree with Drew that the bookmarks portlet isn't the most impressive and most demoable portal content. I'd favor a more modest adjustment for uPortal 4.1 of dropping the portlet from the welcome tab. I'd favor continuing to include the portlet ootb as an available portlet. The lift for an adopter to then remove the portlet entirely from their uPortal implementation, upon locally evaluating it and deciding it doesn't help, is modest, and is not different from the lift they will make in removing portlets like Notification, Calendar, Courses, Email, Contacts, which despite being lovely will not make the cut for inclusion in all uPortal implementations. That would seem to nail the cleanup, put best foot forward, but rock the boat less. I haven't checked how much the Bookmarks Portlet is contributing to uPortal build time / build and runtime resource consumption. I'm assuming trivially. If the Bookmarks Portlet is a resource hog I could be easily convinced it's not worth the cost and unbundling is in order. So, looping back to the original question, now explicated: > Would anyone object to removing (de-bundling) the BookmarksPortlet for the upcoming 4.1 release? I'd be a -0. I don't favor going so far as de-bundling, but I wouldn't veto consensus to do so, especially since it's quite easy to decide to include this portlet in our local uPortal implementation regardless of what's happening ootb. Kind regards, Andrew On 12/10/13, 4:02 PM, Jim Helwig wrote: > We have a bookmarks portlet but I would have to see if it is the > bundled version. We can probably dig up some data on usage. To be > honest, I don't see it having prominent position in our redesigned > portal. Perhaps it is old school and I support taking it off the > default welcome tab. > > Regarding clutter and build time, perhaps we need to refactor how > things are bundled and what that means. It should be dirt-simple to > add portlets to your install. Perhaps we could trim uPortal to only > "bundle" framework portlets if it is easy to distinguish which > portlets are up-to-snuff and easy to add. > > JimH > > On 12/10/13, 3:42 PM, Drew Wills wrote: >> On 12/10/2013 02:15 PM, Jim Helwig wrote: >>> Very simple portlets might not require regular commits. What is the >>> motivating rationale? >> >> Nothing more than a desire to de-clutter, if we're not interested in >> it any longer. A chance to save a modest amount of disk space, build >> time, and ongoing maintenance & documentation efforts. >> >> We have many more bundled portlets these days than originally, with >> the likelihood of more in the future. >> >> The Bookmarks portlet is in competition with tools like delicious, >> pinterest, social networks, and the browser itself. Feature-wise, it >> doesn't measure up. I just don't see many folks wanting to enter >> their bookmarks into their school portal. >> >> And yet it's on the Welcome tab of the quickstart data. I would be >> delighted to learn that I have it all wrong -- but I'm concerned that >> we're not putting our best foot forward by giving real estate to this >> empty tool when it comes to new folks evaluating the portal. I'd be >> happier giving the real estate to portlets like Notification, >> Calendar, Courses, Email, Contacts, etc., where it's easy to showcase >> pre-configured content, and it's easier to provide valuable content >> in the portlet the first time a user logs in. >> >> And so I suppose we could consider taking it off the Welcome tab, but >> not de-bundling it. But we know only a fraction of users find >> portlets that are not on their original layout (their fragments). In >> a way that approach would exacerbate the issue -- what portion of the >> user population would both (1) find the Bookmarks if it weren't on >> their layout originally and (2) be interested in entering their data? >> >> drew >> > -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Aaron Grant Senior Applications Architect Oakland University - UTS <http://oakland.edu/uts> -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
-- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
