James, Like I mentioned previously, this sounds like progress and I'm in favor of it.
Now digging into some of the details: JW> 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. As I understand it, the way mUniversality addressed this differently was to on initial render display the expanded menu of content in the layout, ready for user navigation. Whereas Respondr looks to collapse that navigation into a hamburger and take a best guess at what content to show the user on initial render. Is it too much to hope that these are close enough that Repondr becomes a natural upgrade path for current mUniversality adopters under this change? I suspect that the show-the-upper-left-most-portlet algorithm is going to end up being too arbitrary, but no need to address that now -- can discover what options adopters need in place of that when the upper-left approach proves too limiting. Current mUniversality adopters really wanting the show-the-navigation-menu-expanded-on-initial-render behavior, however, could tweak this algorithm to render a responsive sitemap portlet by fname, say, and viola! they have an mUniversality experience implemented on Respondr. And then we get to retire some themes for uPortal 5 or so, right? :) 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
