Thanks for your post Andrew. I agree with your general statement that there are two things going on and that the portal should determine general 'shape' characteristics and communicate that to the portlet which optionally could use that information to tailor its display accordingly.
I wanted to bring everyone's attention to some work-in-progress that was done late last quarter that is fairly related to this discussion. https://issues.jasig.org/browse/UP-4197 is to improve uPortal Respondr's mobile UX experience, particularly targeted toward general responsiveness on slow mobile networks but also UX experience. It's current implementation sets a user attribute mobileSinglePortletExperience when user is using mobile web browser and Respondr theme that can be passed to portlets via portlet.xml to have them choose alternate behavior. The intention of this user attribute right now (as best I recall; darn I should have taken better notes during design discussion) is to enable the portal to select a streamlined presentation format in Respondr (specifically display only a single portlet and not a whole collection of them) and for framework-portlets to perform or communicate to CSS some alternate UI behavior, in particular related to communicating this 'single portlet view' into navigation that could be different for a single-portlet mobile view. This attribute can also be used by portlets to perform separate presentation options that assume the portlet has basically the full width of the page view. (BTW I am very interested in feedback and discussion on the approach). As an aside, I would like to consider using spring.io's device detection capability (thanks for bringing that to my attention. I wasn't aware of it) within uPortal as a characteristic that could be passed to the portlet. I'm not a big fan of our reg-ex expression strategy and would like to use a more general approach that we don't have to support. I am intrigued by the option of tablet as it opens the possibility of other UX improvements that our current approach (desktop/mobile) doesn't easily allow for. Thanks, James Wennmacher - Unicon 480.558.2420 ----- Original Message ----- From: "Andrew Petro" <apetro.li...@gmail.com> To: uportal-dev@lists.ja-sig.org Sent: Wednesday, January 7, 2015 8:09:10 AM Subject: Re: [uportal-dev] portlet-utils isMobile with respondr I suggest making this about two things. One thing is the API between portal and portlets. Thing 2 is how the portal implements fulfilling that API. I think what's going on here is uPortal exposed an API whereby portlets could get the theme name request.getProperty(themeNameProperty); and that used to be a useful thing, what with portlets comparing that theme name to decide which views to use. We'd been calling it isMobile vs not isMobile (desktop?), but maybe what was really going on there was **theme**-specific views. Views tailored to look good under mUniversality and Universality. And maybe there's a continued place for that. It's probably not actually true that portlets can generate generic markup that looks good under all possible themes -- portlets are going to look a lot better if they can tailor their markup to the theme they're running under, probably. Maybe this gets at a migration path for starting to use respondr's Bootstrappy goodness when available but continuing to support Universality for a while? Interestingly, this feature might allow a place like MyUW that has forked respondr quite a bit and so has something with its own name ("bucky") to cleanly have portlets select different JSPs that are tailored to "bucky". If portlet namespacing JSPs by theme name was implemented well, well, MyUW's overlay on those portlets could consist only of adding the new Bucky-tailored JSPs. Anyway. And then there's this other concept, whether the browser is roughly "mobile" flavored. And maybe what we're discovering here is that portlets want to know that. Okay. If so, I think the portal should be figuring that out once as well as it can, and then exposing that fact to portlets via a well-defined API. Something like request.getProperty("mobileness"); and uPortal implements that property on the portlet requests, setting it to some well-defined values. Maybe "true" "false" or "dunno" would get the abstraction about right. Anyway. And then, to the extent that portlets wanted to choose their views or markup or styles or other stuff depending upon a mobileness abstraction rather than a theme name abstraction, well, then they could do it, even under repondr where all comers get the same theme name. :) And then we can have interesting explorations of how best to implement fulfilling that API portal-side. Probably something pluggable and configurable. Maybe use spring.io device detection. Maybe keep doing our lovingly hand crafted user-agent regular expression matching. Maybe do whatever it was that Steve Swinsburg was trying to get me to understand in that other thread. :) I do think breaking it up this way makes some sense -- the portal seems to usually be the right architectural layer to be making a mobileness determination, with the portlets usually consuming a simpler abstraction rather than themselves trying to compute the mobileness of the request. Rather than each portlet figuring it out for themselves. Then in the near term MyUW's Courses portlet implementation might choose view implementations based on the mobileness abstraction, with the mobile-tailored JSPs for mobile devices and the desktop-tailored JSPs for others. And perhaps in the longer term the theme-name abstraction would actually be better, perhaps with a transition period where the portlet's existing mobile JSPs serve the mUniversality theme, the existing desktop JSPs serve the Universality theme, and shiny new responsive Bootstrap-using JSPs serve the Bucky theme. Depending how the timeline works out between Courses portlet improvement and Universality / mUniversality retirement. Kind regards, Andrew On Tue Jan 06 2015 at 2:51:37 PM Tim Levett < tim.lev...@wisc.edu > wrote: Hi Devs, We came across an interesting problem and I'm curious if anyone else has had this issue. We are using the portlet-utils project in the CoursesPortlet and we use the method https://github.com/Jasig/portlet-utils/blob/master/portlet-mvc-util/src/main/java/org/jasig/portlet/utils/mvc/ThemeNameViewSelectorImpl.java#L30 a lot to decide to show mobile based portlets. This uses themes to determine mobile or not. Now that we are on respondr which is used for mobile and desktop it is always showing desktop. Really we should do something like the Spring.io project https://spring.io/guides/gs/device-detection/ but that doesn't seem to play nice with portlets. Does anyone have an alternative method/example to figure out mobile or desktop on the server side with portlets? ​Thanks in advance. Happy new year! Tim Levett tim.lev...@wisc.edu MyUW-Infrastructure https://calendar.wisc.edu/share/u/tim.lev...@wisc.edu/dr(-14,30) -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: apetro.li...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jwennmac...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- 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
