Andrew thanks for the response (and so quick!). I'm very interested in the MyUW Bucky approach and I'm eager to see it evolve and eager to see it in action. I agree that there is much value in rendering portlets primarily (exclusively?) in focused mode as it does allow for much more off-the-shelf technology to be used in the portlets with generally snappier user interactions and far fewer technology collisions.
Regards, James Wennmacher - Unicon 480.558.2420 On 10/27/2014 10:52 AM, Andrew Petro wrote: > 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] <mailto:[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 - Unicon > 480.558.2420 <tel:480.558.2420> > > -- > > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://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 -- 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
