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]] De la part de Andrew Petro Envoyé : mardi 10 décembre 2013 23:26 À : [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] 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
