Design is increasingly important. But for many, breaking down application design components can be challenging. If you’re struggling to get your slick design into your Mendix application – this post is for you. In this blog post, I’ll help you lay out the broad strokes of your application.
Where to start
Like most complex problems, focusing on the big picture before diving into details is the best way forward. So before diving into fonts, color schemes, images and CSS, you need to create your applications layouts.
In Mendix, there are two levels of layout structuring: global layouts and micro layouts. Page layouts will take care of our global layouts where a multitude of ways exist for micro layouts. But before we dive into Mendix implementations, let’s first get an idea of our goal.
What to build
To come up with a sound plan, you first need to know what your design is. Let’s take the Mendix Blog as an example (simplifying it just a bit).
Start by analyzing the design to determine its structure. Creating UI elements is not that much different from coding (from a best practices point of view). We’re looking for ways to reach our goal with the least amount of work and the most efficient flexibility for future changes. Meaning no ‘code’ repetition and reusing our elements as often as possible.
After carefully inspecting the Mendix Blog three types of content pages can be distinguished:
Notice the abstraction level in inspecting a design of a page. At this point in our process, we’re not interested in headers, images or buttons, only the large functional blocks.
Having sketched out the three main page types, it’s time to translate them into page layouts. But wait, what about our best practices of not repeating ourselves? By analyzing each page type, you can find a clever way of doing less work.
Notice how each page type has the same elements and the only real difference is how content blocks are placed. Let’s translate that into a system where there is no repetition. That way, if something needs to be changed, we only have to change it in one location.
- Our top level is the main Mendix website which has a header, footer and a content area.
- The Mendix Blog is the second level, consisting of a header (including navigation) and a content area.
- The specific content layouts consisting of rows and columns is the last level in which we’ll define the application’s layout.
If we can somehow implement these three levels with proper inheritance we’ll have a very flexible, non-repetitive and solid base to build our application pages with.
Building our structure in Mendix
Now that we’ve defined our page structure, it’s time to start up the Business Modeler. The magic words in Mendix for global layouts is “Layout container.” We can create an inheriting layout architecture which the content pages can then use as a template.
The Mendix Blog Master layout uses the Main Application Master layout as a parent. Hence, every page based on the Mendix Blog Master layout will inherit every change made to the Main Application Master layout.
Notice that the Main App Footer element is placed inside the Mendix Blog layout. Layout containers have two modes of scrolling behavior: per region or per full widget. Now, our application needs the Mendix top navigation to be always visible, making the rest of its content scrollable. This requires both the Mendix Blog placeholder as well as the Main App footer to share a placeholder. The quickest way is to add this into the Mendix Blog Master layout.
With our new Mendix Blog Master layout we can create our content page layouts:
Finally, we’re ready to create our first pages in the Modeler using our freshly created page layouts. Let’s see what the homepage would look like:
And there we have it: a homepage with five content areas to fill and which inherits all its repetitive header and footer material from the same source as any other page. All that’s left now is to actually fill it with content.
If we look at a “Recent Posts” item on the Mendix Blog homepage, we can see an image on the left, with title, author and category.
A page layout with its layout containers will not provide us with a solution for implementing layouts on this level. Fortunately we have a multitude of options available to us:
- We can create a table with two cells. This is Modeler friendly, but unfortunately very output unfriendly.
- We can use CSS in the following ways:
- We can use inline-block behavior whilst wrapping our title, author and category in a container element.
- We can use floating behavior or absolute positioning.
- We can create our own bootstrap grid with a row and two columns, using Bootstrap’s class names such as “.row” and “.col-md-6”.
It’s safe to say that there are many ways to solve micro layouts, and most of them are a bit more complicated than layout containers. Fortunately, Mendix is working really hard to improve in this subject – so stay tuned for future blog posts!
Here’s my recommended workflow for transforming your design into a Mendix application:
- Analyze the design of the application and create abstract models of the pages structure.
- Analyze the page structures and create a system where we create our page layouts without duplicating elements.
- Translate your system into Mendix page layouts.
- Start building your application with a development parallel to micro layouts and theming.
But what about mobile?
Well, to be honest, the above seems to target desktop but it actually doesn’t. The exact same story applies for mobile and tablet. This is especially true when creating different Mendix pages for each device.