Outsystems and responsiveness....

Outsystems and responsiveness....

  

So...

For my client, I'm creating a responsive web-application...
In dev and test, it's easy to showcase with the 'preview in devices' which 'simulates' the devices and refreshes the page.
This can all be activated in service center with a site property.
Ofcourse in production we don't want that simulation thing.. But guess what...
Is it responsive? no.
Does it scale? yes.

These are clearly 2 different things...
I'm getting confronted with my client about the fact that it's being advertised to be responsive, while it's clearly not??..
Ofcourse, when you open it on a phone or tablet it scales..
ex.If they showcase the prod application on a beamer for example or if they want to use the application in a window with 50% of the screen size it's not useable.. since it not responsive..

I saw an article where Outsystems explains why they have chosen 'this approach': https://success.outsystems.com/Documentation/SILK_UI_Framework/05_Understanding_Responsive_and_Adaptive

The only reason i can find is 'media queries are hard to understand and hard to maintain'.
It may be hard to maintaint, but atleast it's responsive...
By cutting the media queries out, you lose a big benefit, while gaining none.

Greetings,

Niels F.

Hello Niels.

Do you have a requirement to support "narrow desktop windows" as if they were mobile devices? Or is it just a demo setup problem?

I can argue that, if a site is not useable in a narrow window, a real user would quickly make the window larger or maximize the browser. So that might not be a real problem in production...

I can also argue that nothing is stopping you from using media queries, and creating your own responsive layout. You can actually override most SilkUI components and make them responsive.

Hello,

Thanks for your answer.

It's just the strength of the platform to not create everything from scratch :P

Don't take me wrong, I putted a lot of work to customize the LisbonTheme to have the expected responsive behavior.

I just wonder, If Outsystems is saying it's the 'best' solution to use server side responsiveness. Why is the Outsystems site itself not using it? :)

Greetings,
Niels F.

Responsive is just one technique to support multiple devices using a single code base, and therefore reducing maintenance. No one is obliged to follow it. You are also not obliged to use the default SilkUI themes - in fact, the London theme is responsive, so you can start with that and evolve it to create your own templates.

OutSystems web site is a good example. Does it fail to capture new clients just because it's not responsive? Maybe the technique just doesn't matter, and what matters is having multi-device support.

(I edited my post above)

Using London theme is indeed a good example.
But using any SilkUI patterns with a non SilkUI theme doesn't work that well... (for example carousel)

Why doesn't SilkUI give you more flexibility about responsive behaviour? If Media queries are to hard, why not flex boxes? ( the OSinLine class which is added via javascript by outsystems to every container makes it impossible to use in most cases)
It's just my opinion.

It is very unfortunate SILKUI isn't giving the same responsive behavior that London theme for example provides.


Greetings,
Niels F.

I'm not sure what was behind the decision to adopt RESS instead of responsive for SilkUI components. I think a one of the factors was to not render invisible widgets at all, like on the DisplayOnDevice block that conditionally renders content based on the device. That can make some difference in page size.

Regarding to flex containers, OutSystems can't use those (yet) because they support IE10. Even IE11 has dodgy support for flex containers, so I think we will need to wait a few more years before we see flex layouts in OutSystems core components.

Regarding the OSInline class, it is added on server side (not by javascript), and is only added when you have a container without width property. If the width is set to (fill parent), then it receives no such class.


I'm glad you went through the effort of customizing a SilkUI theme before posting. I know that's not an easy task, but if you do feel strongly about responsive design, that would be my best advice. You could also start with the London theme and copy a few sections from SilkUI CSS. For example, to make the carousel work, just search by the owl-carousel styles and copy the whole section from the SilkUI stylesheet.

HI Niels!

How is RESS not responsive?... the link you provide even clearly explains how it works. What is not happening is re-evaluating the device based on a browser window resize. But then again that wasn't really the goal of RWD was it? The current SilkUI approach has clear benefits in terms of performance (when accessing from single-screen-size devices) and what you can do with server-side logic, although those benefits come at the cost of loosing the ability to dynamically re-evaluate responsiveness if you're using a computer and resize the browser window... Have you checked the possibility of clearing the cookie mentioned in the documentation whenever there is a screen resize? wouldn't that force all RESS to be reevaluated?

That being said... I'm pretty sure your hard work of customizing the Lisbon theme would be extremely beneficial to people that face similar requirements, would it be possible to share more details about how you did it? Maybe even publish it on the forge for others to be able to use it?

Hi Jorge,

The benefit we are loosing is a big one in my opinion.

I will put it on the forge when i finished my whole theme.

The hard part is the menu. For example the hamburg menu in LisbonTheme is only visible/changeable on the RESS side. And since we aren't able to edit silkUI patterns (without cloning it), i created something myself.


In a nutshell what i'm doing is copy all the css from SILK/Lisbon theme, search for the .phone and .tablet (even .small) classes and putting them together in the corresponding media Query. It's actually very time consuming.
That way I can still benefit and use the .phone / .tablet esc.. classes from SILKUI
The easiest way is to create for each device(media query) a different CSS file + a global one. (to easly maintain it)


On the header web block put this javascript; (for my case)

SyntaxEditor Code Snippet

$( document ).ready( function(){
 $(".small .Menu").hide();
    $(".tablet .Menu").hide();
});

Create a hamburger icon with this CSS:


SyntaxEditor Code Snippet

.desktop.small .smallAndTabletMenu{
display:inline;
color:black!important;
}

.tablet .smallAndTabletMenu{
display:inline;
color:black!important;
}

as an extended property on the hamburger icon 'onclick'

i've put this :

SyntaxEditor Code Snippet

If(IsTablet(), "$( "".tablet .Menu"" ).toggle();", "$( "".small .Menu"" ).toggle();")






Might it be an option to enable 'Preview in devices' in production, but hide the div with css? (as a fast solution)
Or isn't it a good idea, since the page will refresh?

Greetings,
Niels Favreau

Niels,

Was just checking Silk UI's WidgetsForLayout and I upon cursory inspection of some of the JavaScript, it seems the detection of the device and subsequent setting up the cookie is being made via JavaScript (check the JavaScript/SilkUICommon web block)... maybe you could just force clearing/resetting the cookie on resize of the window? followed by a reload of the page of course.

Good suggestion. I'll look into it.
But this will work with PreviewInDevices disabled?

Well... I didn't look tooooo much into it, but from what I had read, the cookie is used by SilkUI to send the device info to the server side so... if you reset the cookie it would be regenerated (as if it was the first time you're accessing the domain). If stuff is being stored in Session you may need a bit more than this though.

Hello Niels,

Silk UI Web was created based on a server side responsive approach that also applies to the client side. This means that you can control server actions based on the device, allowing you to only load certain assets or define how certain widgets will behave.

For devices like a phone and a tablet you have all the capability to define the UI e.g. using the Silk columns where you can control the break mechanism, or use any of the other responsive patterns.

When we're looking only at desktop devices, Silk falls a bit short handling small desktop sizes e.g. similar to a tablet or a phone, although it recognizes desktop devices from small to medium, large and HD.

The main problem is not to use device classes instead of media queries, but is not handling desktop sizes properly for very small window sizes.

Having this in consideration, and I agree with your point, we're looking to improve the responsive mechanism very soon, so you can expect changes in this area.

My regards