Yes on all questions. James Wennmacher - Unicon 480.558.2420
On 11/03/2014 02:19 PM, Andrew Petro wrote: > 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] <mailto:[email protected]>> wrote: > > Andrew as always I appreciate the thoughtful feedback. See below. > > James Wennmacher - Unicon > 480.558.2420 <tel:480.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 [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
