Re : OutSystems Application's Web Design implementation guidelines

Back to Forums

Post Closed

Gonçalo Veiga

Discussion

JavaScript

CSS

How-to

Here are some guidelines for OutSystems development teams to consider when implementing the interface, and in particular when working with a Web Designer.

You can find the full content in the document attached.

Starting a new Web Design

♦ Conceptualize the Application – the project team has the most knowledge about the business goals and technology potential, so it must develop the initial design artifacts.
♦ Provide good inputs to the Web Designer – submit examples of HTML page layouts and respective CSS to serve as basis for a Web Designer's work.
♦ Start from an Application Theme – when starting a new application in OutSystems, a set of CSS classes is generated. This is a good starting point.
♦ Web Application design is iterative – a Web Designer's should be an integrant part of the team from inception to delivery.

Choosing a Layout

♦ Liquid page – expands horizontally to occupy all space available, which can be a problem, but makes good use of viewport space available.
♦ Fixed page layout – can be a poor use of space available, but controls the final user experience.

Mandatory Guidelines (pass these ones to your web designer)

♦ Do not use Id selectors – HTML element Ids are generated dynamically by the Agile Platform, so their usage in CSS is not possible.
♦ Avoid using lists for page structure – lists can be generated and added to pages in the platform, but complicates development and future maintenance.
♦ Do not use HTML5 html tags for page structure – HTML5 tags like <section> or <nav> are not currently natively supported by the Agile Platform, but can be added in snippets, when required.
♦ Use alphanumeric characters for image file names – image filenames can only contain alphanumeric characters and underscore.

Screen Implementation Recommendations

♦ Tables are not for layout – tables are intended for tabular data. Avoid using tables to structure content in pages, as it is slower to render by browsers and makes it nearly impossible to work with across devices (responsive design).
♦ Avoid HTML within expressions – sometimes you’ll need to add some HTML in an expression. You should NEVER use this ability to inject HTML into your pages, as it is a nightmare to maintain.

CSS Implementation Recommendations

♦ Include built-in classes – the Agile Platform uses a number of CSS classes for its internal widgets.
♦ Minimize the number of CSS files – every additional resource the browser has to fetch for a page has a significant performance cost, so keep your CSS files to a minimum.
♦ Avoid inline styles – all the styling content added in the extended properties of elements in the web editor will be rendered as inline styles on the web page.
♦ Organize your CSS – to keep CSS under control, use contextual naming and group rules by section, widget, feature, etc., avoiding duplications and inadvertent overrides.
♦ Make efficient use of CSS inheritance rules – correct use of this mechanism makes maintenance and development a LOT easier.
♦ Avoid CSS hacks – if you do use them, be sure to document them.
♦ Be careful with CSS3 rules – although the support for CSS3 is becoming mainstream, Internet Explorer still lags behind.
♦ Implement Graceful Degradation – adopt the new CSS3 selectors to provide an enhanced experience to user in modern browsers, removing some of the edge as older browsers are used.
♦ Reduce browser differences – browsers have different styling defaults for HTML elements, which produce rendering differences for your web pages.

Normalize.css makes browsers render all elements more consistently

Image Recommendations

♦ Include images with relative paths – use relative paths to reference the images in your eSpace - /MyApp/img/header.png
♦ Prefer the PNG format – it supports both transparencies and wide range of colors.
♦ Prefer image sprites – recommended for applications requiring high front end performance.
♦ Beware of image sizes – images with large sizes (> 50 KB) are the easiest way to damage the performance of your application.

Have we covered the essentials? What do you think? Leave your considerations and experience.

Cheers

OutSystems Application Web Design v1.0.pdf

20 Jan 2013

Robert Chanphakeo

Gonçalo Veiga,

Useful information

Additional recommendation for High Traffic websites

Reduce HTTP request

-Use content delivery network, make javascript, css, media files external.

-Combine files into a single file (i.e CSS into a single stylesheet file, Images used on website into a single sprite image file)

-Put stylesheets on top of page

-Put scripts at the bottom of page

-Minify Javascript and CSS

-Reduce Cookie size

21 Jan 2013

Gonçalo Martins

Staff

Well done Gonçalo...
Nice work and very useful information.

Kind Regards,
Gonçalo Martins

21 Jan 2013

MVP

Very nice. Love those guidelines.

do you see a "however" coming?.... I am :)

Tables are not for layout
Care to explain why the default "Layout_Normal" is using tables for layout?

Keep up the good work!

21 Jan 2013

Gonçalo Veiga

Statler & Waldorf wrote:

Nice catch. I'm not aware of the decision behind it, but I can only assume it was motivated by the difficulty of having a consistent and solid experience across browsers, including problematic ones like IE6 and IE7.

Also bear in mind, this layout was built a few years back, when the term responsive design wasn't even coined. I'm sure we'll be taking some steps in right direction.

Thanks for the feedback

21 Jan 2013

2 replies

Last reply 22 Jan 2013

Show thread

Hide thread

Paulo Ramos

Staff

Gonçalo Veiga wrote:

Hi Gonçalo,

It's not a perfect world. Unfortunately, when working with project teams (with the most diverse backgronds), it's (more or less) frequent to see that they lack enough knowledge about CSS for doing a good job avoiding tables for the basic design. In these situations, either you (and them) have enough time to coach them through the basics, or when you leave the project, maintenance done by them will be a nightmare. And if you get in touch with the project months later, you'll probably see a lot of dirty workarounds making it much more difficult to change and comply with all browsers.

So, I understand why tables are a bad design decision - but, in the end, perhaps the decision should take into account the background of the team that will be responsible for maintenance. After all, in one way or the other, the ultimate goal of these guidelines is improving maintenance, not just just following standards - someone is paying for the project.

Anyway, with your experience, you probably faced this situation before, I just wanted to know your 2 cents on this. :)

And nice work on these guidelines, by the way!

22 Jan 2013

Gonçalo Veiga

Paulo Ramos wrote:

Hi, Paulo. Actually, the full content is inside the PDF, the post is just an appetizer. So, the full guideline for this topic is:

Tables are not for layout

Tables are intended for tabular data. Avoid using tables to structure content in pages. These are slower to render by browsers and make it nearly impossible to work with across devices (responsive design). With that said, sometimes a table is just an easier solution for small pieces of your page.

So, I'm with you. Sometimes a table is just a better solution, easier to work with and maintain. Just don't build pages with table in table in table in table in table...

Cheers

22 Jan 2013

Gonçalo Martins

Staff

Just to add another item here, we could also talk about the eternal discussion related to the usage of the ListRecords inside a span..
Never understood that decision too..
And also the possibility to have a feature that enable us to get more layout templates from the network, would also be very nice, since we could share them with the community and see the trends, having a larger sample space about the current client needs and a way to include some designers more and more in our projects.

Kind Regards,
Gonçalo Martins

21 Jan 2013