James, Thanks for writing this. Good, and important stuff.
I can live with incremental progress and regard what you propose as incremental progress. Progress is good. Better is better. -- I think uPortal should consider taking a step that's more bold. This may be the moment to grab what MyUW is proving out with an AngularJS front end and make that the move uPortal makes as a product. What MyUW's "Bucky" responsive theme does is very similar to what you propose except instead of directing the user to the upper left portlet in focused mode, it instead directs the user to a zero portlets AngularJS front end that implements a very snappy version of that landing page experience. As you propose, the use navigates from there to render single portlets. And from those maximized portlet views, can navigate back to the AngularJS-implemented home page. Once you accept that a landing page doesn't render a mosaic of many portlets, the step beyond that is for it to render zero portlets and thereby get fast. :) This is still wonderfully incremental in that 1) Adopters can still choose to render the mosaic many-portlets landing page approach as much as they like; indeed, with the new rendering pipeline branching capabilities the local algorithm for deciding what to render how to what requests can be quite sophsisticated. 2) Adopters can (and will!) continue to deliver a lot of important functionality via portlets, just leading more with portlets that are focused and so can make more assumptions about how much of the viewport width they enjoy and thus commodity responsive web design approaches (i.e., Bootstrap) become much more directly applicable and Just Work. Which is to say, this isn't the moment that uPortal stops being a JSR-286 portlet container, it's just the moment in which is starts better enabling some perhaps more exciting development approaches as well. --- Of course, even going with the perhaps-less-bold solution you describe, that gets the uPortal product closer to what MyUW is doing and puts an adopter closer to being able to swap out that one-landing-portlet to instead be implemented as an AngularJS path. So I regard it as progress. :) Kind regards, Andrew On Mon, Oct 27, 2014 at 12:32 PM, James Wennmacher <[email protected]> wrote: > We are looking at improving the mobile user experience on uPortal > Respondr and we'd like your feedback on the ideas (and design) before we go > to the broader uportal-user community. I apologize I don't have Andrew P's > elegant blog pages to communicate this more clearly :-) . > > Pending broader feedback, we've identified an issue that we think it would > be good to get out in front of with some incremental progress before it > becomes a more noticeable issue within the community for those on 4.1 > Respondr or considering it. > > https://issues.jasig.org/browse/UP-4197 > > *Issue:* > - For a mobile experience particularly on mobile networks, uPortal's > Respondr theme sends all portlets for the selected tab to the device. This > has the disadvantage of > a) large amount of data sent to device incurring transmission delays > and potentially significant data usage since each portlet includes its own > set of potentially different JavaScript libraries > b) most content is not in the view area and must be scrolled to, > reducing quality of user experience. If user isn't seeing it, it is not > worth creating and sending it. > > *Proposed solution:* > > 1. On access to uPortal attempt to detect if a user's device is a mobile > device (phone or tablet) and redirect the user to a single-portlet, > maximized initial view I'll call 'Mobile Respondr Experience'. > > a) Proposed solution is to select the first portlet on the first tab > that the user has on their layout. > > b) As an exception case, if the user has no portlets in their layout we > can't direct to a single portlet so they get the normal view. > > 2. Users with 'Mobile Respondr Experience' do not get ability to select a > tab and display multiple portlets. The navigational menu allows users to > select a portlet to view. > > a) Initial proposal is a drop-down menu like current menu button (I've > heard it called the hamburger) but could be something you swipe in from the > side in the future > > See attached screen images illustrating the idea. > > Of course the mUniversality view attempted to resolve this issue > differently, but one thing I think we don't want is multiple themes to > address the mobile experience. > The intent is to retain as much of the Respondr/Responsive Design aspects > as possible, have a single theme, but target specific issues (rendering > multiple portlets) that degrade the user experience especially on slow > networks and slowly improve the experience with limited, bite-size > improvements as we evolve the mobile offering. > > *Design considerations:* > > 1. For initial iteration, determining to render a 'Mobile Respondr > Experience' is a combination of > a) theme = Respondr > b) User-Agent string matches a RegEx expression of mobile user agent > strings > > If so, create an attribute mobileRespondrExperience for the user (in the > session-based sessionScopeAdditionalDescriptors) that can be passed to PAGS > or to portlets. This determination would occur as part of setting up user > attributes; e.g. at login time (or when searching for a user so it displays > properly in Manage Users). > > This allows Universality, mUniversality, custom themes, etc. to not be > impacted. I considered collecting information about the user's device > (screen size, etc.) as part of the criteria but decided for the first, > incremental step to just use the User-Agent HTTP header. This means if the > device is a larger tablet or phone you would generally get the Mobile > Respondr Experience. > > 2. If user is using a 'Mobile Respondr Experience', prior to rendering > portlets if requested URL is not focused on a single portlet, determine the > first portlet that would render for the user and redirect the browser to > display that portlet. > > The initial implementation will leverage Andrew P's great work described > at http://apetro.ghost.io/pipelines-need-valves/ to invoke an alternate > pipeline that redirects the browser to a single portlet. > > 3. The navigation menu will be moved out of the theme XSL and placed into > a framework portlet. This portlet will use the mobileRespondrExperience > attribute to add a marker CSS class to the page (probably on the HTML body > tag) that the CSS can use to present the navigation as the hamburger menu > (mobile style) regardless of media query settings. This allows the page to > display navigation using the Mobile Respondr Experience instead of > displaying the navigation as tabs despite the width of the window. > > A critical design issue is that the Mobile Respondr Experience > determination must be made server-side and communicated to the > javascript/css on the rendered page. The CSS cannot rely on purely media > queries (ala Bootstrap) to determine whether to display tabs or use the > hamburger menu. This allows the normal responsive nature of media queries > when resizing, plus the 'set the experience' choice determined by the > portal without collisions. > *Future* > > In the future we can enhance selection of the Mobile Respondr Experience > by: > > - Allowing the Mobile Respondr Experience to be a session-selectable > feature. When you have the Mobile Respondr Experience you can select an > option to use the Desktop Experience. Since the experience would be driven > by a user attribute, the user changing their browser setting to request a > desktop view after logging in would not affect the experience unless we > decided to re-evaluate that with each request but I don't think that is > worth it since we'd want to have something in the UI allow for changes. > - Allowing the Mobile Respondr Experience to be a user-selectable > feature stored as a user preference, maybe even per user-agent string or > cookie-based so you can have different settings on your tablet or mobile > phone. > - Detect that the URL is targeting a folder and display the first > portlet in the folder. Since the navigation menus generally would not > target folders, this is deemed a low priority for initial release. > > b) As an option we could accept targeting a tab and display the first > portlet on the tab, but I'll defer that to an enhancement. > > > *Criticisms/Alternate approaches * > > 1. There is overlap between the mobileRespondrExperience user attribute > and the existing PAGS groups Respondr Theme Users and Mobile Device > Access. The latter is more granular and used for other functions. As long > as we use as much common code as possible it won't be a terrible violation > of the DRY principle and I think it best to keep the choice of what > determines Mobile Respondr Experience as close to a single data item as > possible. > > 2. I considered enhancing the UserPreferences to include a map of session > and persisted preferences. That is a more substantial change and it > prevents passing the information to non-framework portlets unless we expose > those preferences as user attributes anyway. Such an enhancement of > exposing certain UserPreferences as user attributes may be how we implement > the future enhancements. > > 3. It desirable to have a 'grand mobile plan' mapped out to insure we are > making progress toward a unified vision. There is enough variability in > the uPortal direction (AngularJS front-ends, portal of launchers vs. > aggregated content, responsive portlets, etc.) and significantly a lack of > resources that I think our best bet is to make small, logical steps forward > as we evolve the mobile strategy. I think this generally fits with current > thinking and yet leaves open alternate future strategies. > *Feedback* > > Sorry for such a long email. I know it is hard to digest. :-) I'd love > to hear your feedback on the item being solved, the general solution > strategy, and of course on the design thoughts. > > Thanks, > > -- > James Wennmacher - Unicon480.558.2420 > > -- > > 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
