Responsive portlet design
80 views
Skip to first unread message
Jackson, Allan
Apr 21, 2016, 9:21:32 AM4/21/16
to uporta...@apereo.org
I’m trying to write a responsive portlet using Bootstrap’s grid system. The big problem I’m having is with the portal’s dashboard view. When the actual browser window’s size is large, Bootstrap tries to show my large desktop view even though the portlet
itself only has a small area of the dashboard to work with (so it needs to use my intermediate sizes instead).
Most of my research has indicated that "media queries are a hack”, and what we really need are element queries. It looks like there are several competing javascript libraries that implement a version of element queries, but there’s no official solution
yet.
Before just randomly picking one of these libraries, I wanted to check with other developers on how they are handling responsive portlet design. Are you using an element query js library, or did you go a different route entirely?
Thanks,
Allan Jackson
Michael Vose
Apr 21, 2016, 9:29:35 AM4/21/16
to Jackson, Allan, uporta...@apereo.org
Hello,
Within Manchester University we are adapting our content in order to fit on dashboard view.
Additionally, within uPortal’s dashboard view the .focused class is available whereas in a portlet’s maximised view the class is unavailable.
This means that you can enter the following css rule to target the dashboard view, which will not affect the portlets maximised view:
.namespace h3{
Color:#fff;
}
.focused .namespace h3{
Color:#000;
}
In this case as the .focused class exists in the dashboard view the h3 would be black (#000 ), whereas in maximised view the h3 would be white ( #fff ). This approach also means you can utilise javascript functions on elements based upon whether .focused is available.
I am aware that this approach could annoy people on this list as css within a portlet is relying on a class set in an xslt outside of a portlet and thus breaks the paradigm that a portlet is a self contained piece of code, however this is the most light weight solution as opposed to bringing in yet another javascript library to achieve something which usually can be done via html/css.
Best Regards,
Michael Vose.
--
You received this message because you are subscribed to the Google Groups "uPortal Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
uportal-user...@apereo.org.
Visit this group at
https://groups.google.com/a/apereo.org/group/uportal-user/.
Andrew Petro
Apr 21, 2016, 9:41:37 AM4/21/16
to uPortal Community, allanj...@ku.edu
Hi Allan,
Perhaps only somewhat usefully to you…
- Embrace maximized applications. When the user is rendering an application, whether a JSR-286 portlet or our non-JSR-286 AngularJS web application alternative, that application enjoys the entire browser window, at least horizontally. This means that media queries work just fine, Bootstrap (and Angular Material) features for responsiveness to window width work just fine. Technical win! Also, the UX advice around here, as I understand it, is that most tasks benefit from and deserve focus. Executing a task with a bunch of other stuff going on on the screen, well, that's harder to use than is executing a task in a context focused on, designed for, supporting completion of that specific task. So, providing maximized experiences for doing interesting things, also UX win!
- Embrace the portal home page, dashboard experience being special. It's not a matter of rendering JSR-286 portlets in particular window states. It's not a matter of rendering JSR-286 portlets at all. Rather, it's a designed, custom web application rendering lightweight widgets that are designed to look good all the same small size. Only some applications have value with custom widget presentations to surface dashboard information — indeed only some applications have value with even a link pinned to the home page. Use search and notifications and the directory of apps and deep links to provide navigation to the rest. Thereby the portal scales beyond what can be crammed into tabs.
This approach may or may not resonate for you and your campus. We're having some success with it. It does make the responsive design problem simpler.
Kind regards,
Andrew
Drew Wills
Apr 21, 2016, 11:15:09 AM4/21/16
to Michael Vose, Jackson, Allan, uporta...@apereo.org
Good suggestion Anthony (as good as any).
Another one that’s commonly kicked around is to provide 2 JSPs: one for WindowState.NORMAL and another for WindowState.MAXIMIZED.
In NORMAL you can assume you need to be small — you have (typically) 1/3 - 1/2 the width of a large display, or essentially 100% the width of a small display (due to column wrapping)… both of which work out similarly.
In MAXIMIZED you can use Media Queries per usual, since you have nearly all the width… whatever the display.
drew
Michael Vose
Apr 21, 2016, 3:01:07 PM4/21/16
to Drew Wills, Jackson, Allan, uporta...@apereo.org
Hi,
I should have stated below that with regards to utilising javascript based upon whether focused is available, an if statement would need to be utilised, otherwise an error would be thrown in the maximised view.
I believe the two jsp solution is a lot better than the current solution I am utilising.
Kindly.
From: uporta...@apereo.org [uporta...@apereo.org] on behalf of Drew Wills [awi...@unicon.net]
Sent: 21 April 2016 16:17
To: Michael Vose
Cc: Jackson, Allan; uporta...@apereo.org
Subject: Re: [uportal-user] RE: Responsive portlet design
Sent: 21 April 2016 16:17
To: Michael Vose
Cc: Jackson, Allan; uporta...@apereo.org
Subject: Re: [uportal-user] RE: Responsive portlet design
Anthony Colebourne
Apr 21, 2016, 6:11:07 PM4/21/16
to uporta...@apereo.org
Hi,
We currently use both of these solutions. Each has its merits depending
on circumstance. Factors to consider:
1) Technologies in play (e.g. WebProxy / SnippetTag / JSP etc)
2) Content source (e.g. CMS)
3) UI capabilities required in each window state
@Allan I tried a JS approach (specifically responsive-containers). In
addition, there was for a while, a version of Bootstrap that had been
modified to react to specific container classes modeled around
Bootstrap's standardised breakpoints. Neither JS solution was
satisfactory, I seem to remember issues around latency on-load and
browser reflows.
-- Anthony.
On 21/04/16 16:17, Drew Wills wrote:
> Good suggestion Anthony (as good as any).
>
> Another one that’s commonly kicked around is to provide 2 JSPs: one for
> WindowState.NORMAL and another for WindowState.MAXIMIZED.
>
> In NORMAL you can assume you need to be small — you have (typically) 1/3
> - 1/2 the width of a large display, or essentially 100% the width of a
> small display (due to column wrapping)… both of which work out similarly.
>
> In MAXIMIZED you can use Media Queries per usual, since you have nearly
> all the width… whatever the display.
>
> drew
>
>> On Apr 21, 2016, at 6:29 AM, Michael Vose
>> <michae...@manchester.ac.uk <mailto:michae...@manchester.ac.uk>>
>> [mailto:uporta...@apereo.org]*On Behalf Of*Jackson, Allan
>> *Sent:*21 April 2016 14:21
>> *To:*uporta...@apereo.org <mailto:uporta...@apereo.org>
>> *Subject:*[uportal-user] Responsive portlet design
>> <mailto:uportal-user...@apereo.org>.
>> Visit this group
>> athttps://groups.google.com/a/apereo.org/group/uportal-user/.
>> <mailto:uportal-user...@apereo.org>.
>> Visit this group
>> athttps://groups.google.com/a/apereo.org/group/uportal-user/.
We currently use both of these solutions. Each has its merits depending
on circumstance. Factors to consider:
1) Technologies in play (e.g. WebProxy / SnippetTag / JSP etc)
2) Content source (e.g. CMS)
3) UI capabilities required in each window state
@Allan I tried a JS approach (specifically responsive-containers). In
addition, there was for a while, a version of Bootstrap that had been
modified to react to specific container classes modeled around
Bootstrap's standardised breakpoints. Neither JS solution was
satisfactory, I seem to remember issues around latency on-load and
browser reflows.
-- Anthony.
On 21/04/16 16:17, Drew Wills wrote:
> Good suggestion Anthony (as good as any).
>
> Another one that’s commonly kicked around is to provide 2 JSPs: one for
> WindowState.NORMAL and another for WindowState.MAXIMIZED.
>
> In NORMAL you can assume you need to be small — you have (typically) 1/3
> - 1/2 the width of a large display, or essentially 100% the width of a
> small display (due to column wrapping)… both of which work out similarly.
>
> In MAXIMIZED you can use Media Queries per usual, since you have nearly
> all the width… whatever the display.
>
> drew
>
>> On Apr 21, 2016, at 6:29 AM, Michael Vose
>> wrote:
>>
>> Hello,
>> Within Manchester University we are adapting our content in order to
>> fit on dashboard view.
>> Additionally, within uPortal’s dashboard view the .focused class is
>> available whereas in a portlet’s maximised view the class is unavailable.
>> This means that you can enter the following css rule to target the
>> dashboard view, which will not affect the portlets maximised view:
>> .namespace h3{
>> Color:#fff;
>> }
>> .focused .namespace h3{
>> Color:#000;
>> }
>> In this case as the .focused class exists in the dashboard view the h3
>> would be black (#000 ), whereas in maximised view the h3 would be
>> white ( #fff ). This approach also means you can utilise javascript
>> functions on elements based upon whether .focused is available.
>> I am aware that this approach could annoy people on this list as css
>> within a portlet is relying on a class set in an xslt outside of a
>> portlet and thus breaks the paradigm that a portlet is a self
>> contained piece of code, however this is the most light weight
>> solution as opposed to bringing in yet another javascript library to
>> achieve something which usually can be done via html/css.
>> Best Regards,
>> Michael Vose.
>> *From:*uporta...@apereo.org <mailto:uporta...@apereo.org>
>>
>> Hello,
>> Within Manchester University we are adapting our content in order to
>> fit on dashboard view.
>> Additionally, within uPortal’s dashboard view the .focused class is
>> available whereas in a portlet’s maximised view the class is unavailable.
>> This means that you can enter the following css rule to target the
>> dashboard view, which will not affect the portlets maximised view:
>> .namespace h3{
>> Color:#fff;
>> }
>> .focused .namespace h3{
>> Color:#000;
>> }
>> In this case as the .focused class exists in the dashboard view the h3
>> would be black (#000 ), whereas in maximised view the h3 would be
>> white ( #fff ). This approach also means you can utilise javascript
>> functions on elements based upon whether .focused is available.
>> I am aware that this approach could annoy people on this list as css
>> within a portlet is relying on a class set in an xslt outside of a
>> portlet and thus breaks the paradigm that a portlet is a self
>> contained piece of code, however this is the most light weight
>> solution as opposed to bringing in yet another javascript library to
>> achieve something which usually can be done via html/css.
>> Best Regards,
>> Michael Vose.
>> [mailto:uporta...@apereo.org]*On Behalf Of*Jackson, Allan
>> *Sent:*21 April 2016 14:21
>> *To:*uporta...@apereo.org <mailto:uporta...@apereo.org>
>> *Subject:*[uportal-user] Responsive portlet design
>> I’m trying to write a responsive portlet using Bootstrap’s grid
>> system. The big problem I’m having is with the portal’s dashboard
>> view. When the actual browser window’s size is large, Bootstrap tries
>> to show my large desktop view even though the portlet itself only has
>> a small area of the dashboard to work with (so it needs to use my
>> intermediate sizes instead).
>> Most of my research has indicated that "media queries are a hack”, and
>> what we really need are element queries. It looks like there are
>> several competing javascript libraries that implement a version of
>> element queries, but there’s no official solution yet.
>> Before just randomly picking one of these libraries, I wanted to check
>> with other developers on how they are handling responsive portlet
>> design. Are you using an element query js library, or did you go a
>> different route entirely?
>> Thanks,
>> Allan Jackson
>> --
>> You received this message because you are subscribed to the Google
>> Groups "uPortal Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email touportal-use...@apereo.org
>> system. The big problem I’m having is with the portal’s dashboard
>> view. When the actual browser window’s size is large, Bootstrap tries
>> to show my large desktop view even though the portlet itself only has
>> a small area of the dashboard to work with (so it needs to use my
>> intermediate sizes instead).
>> Most of my research has indicated that "media queries are a hack”, and
>> what we really need are element queries. It looks like there are
>> several competing javascript libraries that implement a version of
>> element queries, but there’s no official solution yet.
>> Before just randomly picking one of these libraries, I wanted to check
>> with other developers on how they are handling responsive portlet
>> design. Are you using an element query js library, or did you go a
>> different route entirely?
>> Thanks,
>> Allan Jackson
>> --
>> You received this message because you are subscribed to the Google
>> Groups "uPortal Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> <mailto:uportal-user...@apereo.org>.
>> Visit this group
>> athttps://groups.google.com/a/apereo.org/group/uportal-user/.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "uPortal Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email touportal-use...@apereo.org
>> --
>> You received this message because you are subscribed to the Google
>> Groups "uPortal Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> <mailto:uportal-user...@apereo.org>.
>> Visit this group
>> athttps://groups.google.com/a/apereo.org/group/uportal-user/.
>
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Community" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to uportal-user...@apereo.org
> <mailto:uportal-user...@apereo.org>.
> --
> You received this message because you are subscribed to the Google
> Groups "uPortal Community" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to uportal-user...@apereo.org
COUSQUER Christian
Apr 22, 2016, 4:11:57 AM4/22/16
to Anthony Colebourne, uporta...@apereo.org
Hi,
Sorry for the late response. And sorry for my English - I'm French...
@allan, My opinion to add a JS lib that will emulate futurs CSS behaviors that will be implemented by browser vendor when they will be agreing on these behaviors, is that it could be a little touchy in Respondr layout with all the present JS libraries of the portal and portlets.
You will get invariably some JS conflicts : between ES3 versus ES2015 versions, lib version, strict mode/ not strict mode, etc.
@Anthony
100% agreed with your statement :
> "Neither JS solution was satisfactory, I seem to remember issues around latency on-load and browser reflows."
and I add you this statement :
"When you have a choice between a JS solution or a CSS solution to solve a problem, always prefer the CSS solution. " You won't have latency on load and you will have sometimes the help of the CSS GPU accelerated properties (much more efficient and smoother than JS engines).
But your first solution only solve Allan's problem only on maximized view not on dashboard view with more than one column.
@all
That's funny because I sent two days ago to Drew and James this mail that could perhaps solve perhaps your case, Allan.
"I have solved yesterdays a default that was result from Respondr and Bootstrap that has annoyed the community since Respondr : the CSS grid for portlets in dashboard view with more than one column, better than CSS class of James : ".bootstrap-style".
It's a simple LESS mixin (a bit complicated...), that allows you in a portlet with a top CSS class (".bootstrap-style-by-@portletBreakpoint" with @portletBreakpoint equals at choice to 2,3,5,6) to:
1) preserve the html Bootstrap's markup for compatibility and for portlets in AngularJS front,
2) preserve the natural behavior of Bootstrap's Grid for a portlet in a single column layout and maximized layout,
3) preserve the mobile and tablet view on narrow devices, it's a Mobile first solution,
4) but when the portlet is displayed in columns (2, 3, 4 columns) on normal and large desktop displays, the mixin allows you to display -your choice - a mobile view of some component or not, and to have a custom kind of "CSS breakpoint" in the grid, depending not on the Object Windows but on the width of the parent column.
Imagine a portlet grid with 2 DIV with .col-md-6 class, with ".bootstrap-style-by-6" on top it give you:
in a single column display :
DIV 1 & 2 on single row with 50% width each ;
in more than X column display (X at your choice) :
DIV 1 in one row with a width of 100%,
DIV 2 in a second row with a width of 100%.
it's a kind of reflow at col-md-6 (or .col-md-2, .col-md-3, .col-md-4, .col-md-5... your choice) in the portlet mark-up with the all recalculation of the all widths in Bootstrap classes.
5) 35+ lines of LESS mixin, protected by portlet's namespace and .bootstrap-style-by, you can extend, parameterize and customize with @variables.
I am finalizing the mixin (few tiny side effects with the gutters of uPortal grid I'm fixing this morning)
I tell you more this weekend with lots of screen captures of the refactoring of Apereo Feedback Portlet on which I am currently testing the mixin as a POC.
I'll will explain this with demos in my Apereo2016 presentation "On the road of multi -tenancy Portal at UPMC" with the refactoring of Feedback Portlet and maybe Announcement Admin.
-- Christian.
-----Message d'origine-----
De : uporta...@apereo.org [mailto:uporta...@apereo.org] De la part de Anthony Colebourne
Envoyé : vendredi 22 avril 2016 00:11
À : uporta...@apereo.org
Objet : Re: [uportal-user] RE: Responsive portlet design
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-user...@apereo.org.
Sorry for the late response. And sorry for my English - I'm French...
@allan, My opinion to add a JS lib that will emulate futurs CSS behaviors that will be implemented by browser vendor when they will be agreing on these behaviors, is that it could be a little touchy in Respondr layout with all the present JS libraries of the portal and portlets.
You will get invariably some JS conflicts : between ES3 versus ES2015 versions, lib version, strict mode/ not strict mode, etc.
@Anthony
100% agreed with your statement :
> "Neither JS solution was satisfactory, I seem to remember issues around latency on-load and browser reflows."
"When you have a choice between a JS solution or a CSS solution to solve a problem, always prefer the CSS solution. " You won't have latency on load and you will have sometimes the help of the CSS GPU accelerated properties (much more efficient and smoother than JS engines).
But your first solution only solve Allan's problem only on maximized view not on dashboard view with more than one column.
@all
That's funny because I sent two days ago to Drew and James this mail that could perhaps solve perhaps your case, Allan.
"I have solved yesterdays a default that was result from Respondr and Bootstrap that has annoyed the community since Respondr : the CSS grid for portlets in dashboard view with more than one column, better than CSS class of James : ".bootstrap-style".
It's a simple LESS mixin (a bit complicated...), that allows you in a portlet with a top CSS class (".bootstrap-style-by-@portletBreakpoint" with @portletBreakpoint equals at choice to 2,3,5,6) to:
1) preserve the html Bootstrap's markup for compatibility and for portlets in AngularJS front,
2) preserve the natural behavior of Bootstrap's Grid for a portlet in a single column layout and maximized layout,
3) preserve the mobile and tablet view on narrow devices, it's a Mobile first solution,
4) but when the portlet is displayed in columns (2, 3, 4 columns) on normal and large desktop displays, the mixin allows you to display -your choice - a mobile view of some component or not, and to have a custom kind of "CSS breakpoint" in the grid, depending not on the Object Windows but on the width of the parent column.
Imagine a portlet grid with 2 DIV with .col-md-6 class, with ".bootstrap-style-by-6" on top it give you:
in a single column display :
DIV 1 & 2 on single row with 50% width each ;
in more than X column display (X at your choice) :
DIV 1 in one row with a width of 100%,
DIV 2 in a second row with a width of 100%.
it's a kind of reflow at col-md-6 (or .col-md-2, .col-md-3, .col-md-4, .col-md-5... your choice) in the portlet mark-up with the all recalculation of the all widths in Bootstrap classes.
5) 35+ lines of LESS mixin, protected by portlet's namespace and .bootstrap-style-by, you can extend, parameterize and customize with @variables.
I am finalizing the mixin (few tiny side effects with the gutters of uPortal grid I'm fixing this morning)
I tell you more this weekend with lots of screen captures of the refactoring of Apereo Feedback Portlet on which I am currently testing the mixin as a POC.
I'll will explain this with demos in my Apereo2016 presentation "On the road of multi -tenancy Portal at UPMC" with the refactoring of Feedback Portlet and maybe Announcement Admin.
-- Christian.
-----Message d'origine-----
De : uporta...@apereo.org [mailto:uporta...@apereo.org] De la part de Anthony Colebourne
Envoyé : vendredi 22 avril 2016 00:11
À : uporta...@apereo.org
Objet : Re: [uportal-user] RE: Responsive portlet design
Jackson, Allan
Apr 22, 2016, 9:42:00 AM4/22/16
to uporta...@apereo.org
For a little more context, most of the portlets I work on are really full-fledged webapps with heavy user interaction and data entry/display. Basically the opposite of the “portlet as a little widget” mindset. Due to the complexity of these portlets, we typically switch the user to maximized mode whenever they perform an action in the portlet.
So really, our main concern is the following two scenarios:
1. The initial view of the portlet when the user navigates to one of our portal’s main tabs.
2. The view of the portlet after the user has been interacting with it and then goes back to dashboard view.
The first scenario seems easier to address because we could design some sort of “initial/widget view” that only offers very limited functionality (and then loads into maximized view after user interaction). The problem with the second situation is that the user could be on any page within the portlet, so basically every page needs to be able to display well in dashboard view.
I think where we really get the most bang for our buck is addressing the initial view more thoroughly, and then only worry about major issues on the remaining pages.
It sounds like I probably don’t want to use one of the element query js libraries, but if that ever becomes part of the spec, that’s probably the best solution.
Thanks everybody for your feedback.
Allan
So really, our main concern is the following two scenarios:
1. The initial view of the portlet when the user navigates to one of our portal’s main tabs.
2. The view of the portlet after the user has been interacting with it and then goes back to dashboard view.
The first scenario seems easier to address because we could design some sort of “initial/widget view” that only offers very limited functionality (and then loads into maximized view after user interaction). The problem with the second situation is that the user could be on any page within the portlet, so basically every page needs to be able to display well in dashboard view.
I think where we really get the most bang for our buck is addressing the initial view more thoroughly, and then only worry about major issues on the remaining pages.
It sounds like I probably don’t want to use one of the element query js libraries, but if that ever becomes part of the spec, that’s probably the best solution.
Thanks everybody for your feedback.
Allan
Reply all
Reply to author
Forward
0 new messages