Recently Gonçalo Veiga and I were asked the following question
"Have you ever developed an application according to specification given by a web designer that doesn’t known the OutSystems Platform? What are the majors do’s and don’ts we can tell them?"
Simplifying you have 2 types of designers:
1 - designers who only work with photoshop & illustrator
2 - designers who already know about HTML and CSS
Option 2 is by far the best one, as we’ll have the cropped images, fonts and some of the css for copy-pasting. I say some because sometimes the quality of the css is poor, lacking in basics like inheritance.
In those cases you should ask them
a) Not to use ID selectors (#elementname {}) in the CSS. They should use class selectors instead (e.g. .CSSClass {})
b) Not to use <UL>, <OL> or <LI> tags. Although these can be done with unescaped expressions you would loose wysiwyg in Service Studio.
c) Give them the default CSS and 3 generated HTML pages with the most important widgets and blocks (e.g. EditRecord, ShowRecord, TableRecords, Menu…). If they can build up from there it would awesome as OutSystems widgets and  Intelliwarp would continue to look good. (although designers are just like developers, they prefer to build from scratch than having to understand and integrate with other people’s code).
d) Another topic which has to be defined up-front in option 2 is who is responsible for browser compatibility. If the customer bought a full-blown design service, this should be included. The HTML mockups should be functional and browser compatible with the target browsers.
And you can also show them the Agile Platform. Some designers actually pick it up and start working with it, making your life a lot easier.
What about you, are you a designer or have you ever worked with one?
Do you have any additional tips?
I'm working closely with a designer now. Here's what we did that makes life easy:

* I started by giving a very DIV'ed designed. Almost everything of note has a Container around it. That lets the designer apply styles as he sees fit.
* He's working in Service Studio.
* I did the initial layout for him to come after me.

IntelliWarp is great for what it does, but it just doesn't cover our bases very well. We can use it to drop stuff into existing pages, but not to create new pages. As the developer, any new pages I handle (by cloning an existing one) and the designer comes in after me to make it pretty.

the #1 BIGGEST problem? Sometimes he makes a change that looks innocent but isn't. For example, he changed some of my buttons to links, which would be fine, except that Widget_Click has a bug where it won't work on links. Or a Widget will be within a Container, and the Container's Visible property is based on a variable set in logic (say, to make it invisible under certain conditions) and he will move it outside the Container so it is always visible.

Outside of stuff like this (and we usually notice the bugs VERY quickly! and they take a minute to fix), it's be going great.


It would be nice if OutSystems changes the behaviour of the listrecord widget to produce Unsorted Lists (UL) instead of tables and DIV's
Or have a new widget for UL's :-)
 That way we (and the designer as well) have far more control of the layout on the screen.

Hi Joop,

Is this what you were looking for:

(Just set List Separator to Bullets in a ListRecord widget)

Tiago Simões
Partly ... would be nice to have a UL-LI-UL constructor for dropdown menu system or other options.
Now I do it using expression ... and that's a pain as you know :-)
I am a designer who understands the HTML / CSS / JavaScript and knows how to work with Service Studio in the area thatconcerns me.
I agree in some respects, but the programmer must also be educated when it comes to compile a page. Sometimesprogrammers do not take care to structure the content, resulting a series of tables and div contained within each other, making the designer's task more difficult than it would be.
Regarding to ID sometimes becomes very difficult to apply a simple JavaScript functionality because they also serve the same IDs for CSS, and that's why sometimes we have to use them.
Regarding <ul>, <ol> <li>, I fully agree with Joop Stringer for the same reasons mentioned above.
Regarding the new generation of CSS3 and HTML5 has to be the platform to adapt to new trends and not vice versa.
Finally I think that before a programmer develops an application, he should discuss with the designer regarding the overall layout of the pages, and if the goal is to make a custom application it should be the designer how starts and prepares a template for the programmer can use.
I've had the opportunity to try version 6.0 already supports a lot of features - CSS3, HTML5, creating templates.
Greetings to all.
@Joop, yes, that would be way better

@José, thank a lot for your insights. Regarding programmers not structuring the page as they should, I belive the widget tree in 6.0 can help a bit in there:

Tiago Simões
Hi Tiago,

I'm working close with a designer now and the most thin I like about it is determining the development scope and.

I used to have the tendency to add a bulk load of features in every screen.
The designer (and your presentations ofcourse) and the default version 6.0 style helped me a lot in minimizing
the screens and the less drill-down data content.

I'm now placing drill-down 'hidden' information more into mouseovers and image titles / link titles.
The image and link titles i use to clearify the function of the link / image.

Creating sites in this manner seems to have a very good impact on the use of the pages on mobile devices too!

Thanks for the tips!


Hi Tiago,
I've worked with a customer who had contracted a company that develivered the entire UI, from look & feel to producing the actual html / javascript code. They were building a website and they didn't know the platform, but the code was clean in the way the css was built using the 950 grid system ( - alternatively some sites use the 960 grid system
They also had good inheritance overall, but since they didn't know the platform, the use of common tags like <UL>, <LI> was definitely a part of organizing list elements. Aditionaly the use of tags like <FIELDSET>, <LEGEND> or <LABEL> where also common througout the application, mainly on forms.
Initially we took the approach of having the html produced exactly as provided, because it would give us time to focus on logic essentially. The browser compatibility was also an issue that they were supposed to deliver, so the use of includes like "ie.css" or other hacks were available. In the first sprint we went with unescaped expressions, but as you mentioned we lost wysiwyg in service studio, and the screens were simply unreadable. We had two options, refactor the code or try to make them platform aware. We tried the latest, but after talks we turned out to move into an adaptive refactoring.
Things like <LABEL>, became common divs with special classes to make them look like the original tag. And while you can make them look the same, behaviour is a totally different thing. In most cases the behaviour was lost, but in special cases where we wanted to keep the same user expirience we end up using javascript to replicate the tag effect. The label example is a good one, if you define a text and a checkbox inside the tag, like <LABEL>check the box to select <INPUT type="checkbox"...></LABEL>, then you'll get a selection on the checkbox if you click on the text (or anywhere inside the label tag).
Overall, having someone produce the html with css and javascript can be a good thing, specially if it's platform oriented, but it might be difficult to have someone totally new to service studio worry about these things, if that's the case, then I prefer to have the first option, someone who gives me the images, layouts and orientations.