James, I totally agree that single responsive UIs in portlets rather than forked UIs depending upon whether we think the device is mobile flavored is the way to go. And that Respondr enables those responsive UIs through exposing Bootstrap, etc.
And that rendering one-portlet-at-a-time so greatly improves this since it makes ootb Bootstrap techniques just work (portlet width is viewport width) and it improves the feasibility of responsive UIs vs tailored UIs — such a portlet UI might well feed down to the client more content than it chooses to display client-side, but if it’s just one portlet doing this at a time, the result may still be fast enough and low bandwidth enough to be acceptable. All that said, the Respondr technology is compatible with the heroic view switching in portlets depending on mobile-ness of the client, isn't it? To the extent that adopters want to be doing those heroics in their portlets, or need to continue to do so as a transition strategy until improving single UIs to be responsive, they should be able to keep doing them under Respondr, right? Which should help provide a pretty gentle and compelling upgrade path for adopters to flow forward off mUniversality and into Respondr? Andrew On Mon, Nov 3, 2014 at 11:32 AM, James Wennmacher <[email protected]> wrote: > Andrew as always I appreciate the thoughtful feedback. See below. > > James Wennmacher - Unicon480.558.2420 > > On 11/03/2014 07:58 AM, Andrew Petro wrote: > > 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? > > JNW> I hope it is not too much to hope for :-). The other aspect of > Respondr mobile view is to not have mobile-specific views in the portlets > to reduce maintenance. I believe if we make the Respondr mobile view > reasonably performant, it will naturally supercede mUniversality as > generally superior. I suspect it will never be as performant (larger > libraries, more CSS than the slimmer mUniversality views), but if we can > reduce the overall performance difference (and improve the UI) I believe we > can hit a threshold where it is acceptable to the community as the mobile > web solution. > > > 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? :) > > JNW> Agreed, and I hope we can retire Universality/mUniversality. > Interest and traction on Respondr so far seems good. My concern at this > point is the mobile experience to help keep that interest and traction > going. > > > Andrew > > > > -- > > 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
