Controlling the layout of your application

As with print on a paper page, the Web offers almost limitless possibilities on how to layout your content. While this freedom is certainly desirable it can be daunting when you first start your Web project and is faced with the decision to choose how you will layout content for your application.

Morfik provides through two very simple controls the means to create virtually any design you wish. To create your layout you will primarily work with the Container and the SubForm controls which allow you to group controls and insert other Forms into the design of the Page or Form you are currently working on.


Commonly Used Layouts

While you can choose any layout for your Web page, some layout patterns have become a sort of standard, mainly due to usability considerations and what people expect to see on a page. Most websites use some variation of a core set of layouts which treat a page as being divided into a Header, a Footer and the Content. These subdivisions are then each treated separately and may in turn be further subdivided. A common practice, for example is to split the Content portion of the page into multiple columns.

It should be no surprise that the traditional page sections have a one on one relationship with the elements of the basic structure of a Morfik Page or Form. Both Pages and Form in Morfik are divided into three bands: Header, Footer and Details. Just as any website can choose not make use of one of these elements, a Morfik Form can have any of its bands reduced to zero height which effectively removes that band from consideration in your design.

In this article we will review several commonly used layouts and see how these can easily reproduced using Morfik Pages, Forms and controls. It is important to have in mind that it is not necessary for an application or website to stick to only one of these layouts. In fact quite the contrary is true. An application or website should change its base layout if and when doing so will provide a better experience to the end user.

There are two main variations on layouts, defined by if and how you use columns in your design. The main point is which division is the outermost for your design. Most sites adopt the horizontal partitioning as the outermost, having a header that goes across the entire top part of the page, while a few others adopt vertical partitioning as their outermost division, having columns that aren't interrupted by the header. Whatever the main layout you decide to adopt in your application it will need to be configured/formatted in the project's Master Form.

Horizontal Split Layouts

Horizontally split layouts are those that divide the pages first horizontally and then, if necessary, vertically. These layouts are the most common in the Web today and take very little effort to be reproduced in a Morfik application. The website you can see in Figure 1 uses a horizontal split layout. The header that takes up all the upper portion of the page has been highlighted.

The website in Figure 1 also uses a footer which can be clearly seen, in dark color, at the very bottom of the page.


layouts_horizontal_split_01.png
Figure 1 Screenshot of Ars Technica Website which uses an outermost Horizontal split.


Websites and applications what adopt this layout will tend to follow a pattern that is graphically represented in the diagram shown in Figure 2. This pattern, as you can see quite clearly defines three areas in the page. Usually the header portion is used for branding with a logo showing and for top level navigation, while the footer is generally used to provide a top level navigation menu to pages which provide information which is not central to the website or application's functionality as well as copyright information.


horizontal_layout_base.png
Figure 2 Schematic diagram of a horizontal split layout.


Most horizontally split layouts further divide the middle or content area of the page to present specific kinds of content. One of the most common variations of this layout splits the content area into two columns generally a thin column to one side and a wider column that takes up the remaining space.

You can see in Figure 3 the two most frequently used variations of this kind of layout. You will notice that they are symmetrical. The only difference between the two cases is on which side the thin column is placed. In most cases this thinner column is used to provide navigation options.


common_variations_horiz_split_w_col.png
Figure 3 Schematic diagram of the two most commonly used variations of the horizintal split layout with columns in the content area.


The two layouts you see in Figure XX are the most common on the Web, with the vast majority of sites opting for one of them.

Implementation

There are multiple ways to implement this layout in a Morfik application or website. While what possibilities are open to you will depend on some visual design and architectural considerations, there are three options which are more likely to be applicable then most.

Option 1: Both the Header and Footer of the application are implemented using the corresponding bands of the Master Form of the project which effectively implements the layout. (The Master Form acts as the outermost form of an application.) Both Side Bar and Content are implemented as SubForms, within the detail band of the Master Form, which loads different content as appropriate, based on the user's navigation through the application or website.

Option 2: The Header and Footer of the application are implemented as separate forms and inserted into SubForm controls which are placed within the detail band of the main form used to implement the layout (Again the Master Form acts as the outermost form for the application.), along with the Side Bar and Content SubForms.

Option 3: The Header and Footer of the application are implemented directly in the details band of the Master Form which also implements the layout (acting as the outermost form), along with the Side Bar and Content SubForms. This option is generally preferred when you have content which you wish to be perceived as crossing the boundaries between the Header and the Content portion of your application or website, as that cannot happen when different bands are used.

Vertical Split Layouts

Vertically split layouts are those that divide the pages first vertically and then, if necessary, horizontally. These layouts are not frequently used in the Web today, but are used by some relevant sites such as Wikipedia which is shown in Figure 4. Sites and applications that adopt this layout are, also, easy to reproduce with Morfik. A sidebar column that takes up all the left portion of the page has been highlighted.


layouts_vertical_split_01.png
Figure 4 Screenshot of Wikipedia Website which uses a vertical split layout.


Websites and applications what adopt this layout will tend to follow a pattern that is graphically represented in the diagram shown in Figure 5.


vertical_layout_base.png
Figure 5 Schematic diagram of a vertical split layout.


Most sites that opt to start with a vertical split layout end up choosing on of the variation that is shown in Figure 5.


Another layout which is quite common among sites that opt to have a vertical split, is one that could be argued to actually be a variation of the horizontal split, but for all effective purposes it is a vertical layout. This variation which adds a page wide footer at the bottom is actually the one used by Wikipedia as can be seen in Figure 6.


controlling-layout-vertical-with-footer.png
Figure 6 Diagram of page wide footer in a vertically split layout.


You can see an example of what this layout looks like in practice, in Figure 7, which shows the footer for the Wikipedia.org website.


layouts_vertical_split_02_full_footer.png
Figure 7 Detail of the footer used in the Wikipedia.org website.


Implementation

There are different ways to implement this layout in a Morfik application or website. While what possibilities are open to you will depend on some visual design and architectural considerations, there are three options which are more likely to be applicable then most.

Option 1: Neither the Header and Footer of the application are implemented using the corresponding bands of the Master Form that is used to implement the layout (acting as the outermost form of the application/website). Both Side Bar and Content are implemented as SubForms, within the detail band of the Master Form, which loads different content as appropriate, based on the user's navigation through the application or website. Both header and footer are implemented with controls placed directly on the Master Form.

Option 2: The Header and Footer of the application are implemented as separate forms and inserted into SubForm controls which are placed within the detail band of the Master Form used to implement the layout (outermost form), along with the Side Bar and Content SubForms.

Option 3: The application footer is implemented using the actual Footer band of the main form used to create the layout. While this would tend to be perceived as a violation of the Vertical Layout, the visual impact of the footer is actually quite small leaving the user with the perception of the layout as being vertical. All other aspects can be treated as suggested in the previous two options.

Handling extra space

There are situations in which you will have a lot of free space in the browser window, or at least the possibility of it being there, and you will need to decide how to better prepare for that situation. There are essentially two options from which to choose from when considering how your application should deal with this scenario: flexible and fixed content width.

There is no right or wrong choice for which path to choose. The best choice will be that best matches the way you want you application or website to behave.


Flexible content width

When you decide to let your content resize to match the size of the browser window you are choosing to adopt a Flexible content width kind of layout. While this kind of layout offers the possibility of displaying the maximum quantity of content permitted by the end user's monitor, it can lead to some pages ending up looking decidedly odd, on some larger screens. This is especially true in situations where images and text are combined as the text will normally flow and occupy the space it is given and the images will not.

When Flexible content width is used, in very large screens it is possible to that reading a long text will become uncomfortable for the user when the browser is maximized. This is something developer should be aware of, but need not be a very influential design decision as the resizing of the browser window to smaller proportions will easily allow the user to bring the content into a more comfortable width.


flexible-content-width.png
Figure 8 Screenshot of the Wikipedia.org website using this kind of flexible content width layout. The area with flexible width is highlighted.


While this approach does transfer some responsibility for the user experience it might be a good design decision in some situations. One such situation is when you are working on website or application which displays information in several columns. In this kind of scenario one column would have a flexible width while the others will each have a fixed width. The column with Flexible width will then be able to grow and allow the user to read more information at once, while the information in the other columns retain their exact design width.

Fixed content width

When you decide to adopt a layout that fixes the width the content of your website or application can assume you are taking a path which ensures that your content will look the same regardless of the end user's display resolution. Normally you would do this when you don't want your application to stretch and contract as the browser window does, but you also want to make sure that its fixed width is such as to appear well in whatever monitor resolution the your user's system is configured to.


controlling-layout-vertical-extra-space.png
Figure 9 Diagram diagram of a page with fixed width showing in a wider browser window.


This can be easily achieved by simply setting the Page Alignment project property so that your actual design will either be aligned to one of the sides of the windows (probably the left side) or if it will be centered. You can access this property through the project options dialog.


fixed-content-width.png
Figure 10 Screenshot of the arstechnica.com website using this kind of fixed content width layout. Notice the empty dark areas on both sides of the content.


While based on a technical consideration, keeping the content to a size which will be adequate for viewing by everyone without the need for horizontal scrolling, leaving empty space around it can lead to very good visual results. A careful choice of colors for browser background color (the color around your pages) and page background can lead to designs in which the space that is otherwise left unused helps to highlight the design of the pages.

This pattern is repeated in a large number of websites and has been getting more and more attention from designers as the size and resolution of desktop monitors increases while at the same time more devices with small screens are used to browse the Web. This simultaneous evolution in different directions, with desktop monitors growing in size and resolution and mobile displays becoming ever more present, drives design towards this pattern as a sort of compromise in making a website or application look good and be easy to read in both the large and small screens.

Layouts and Navigational Structure

As has been mentioned previously in this article, it is quite common for a website or application to have pages with different layouts and designs. While in a few cases this might be the casual by product of incremental development, much more often it is the result of form following function, even if it is done at an unconscious level.

You should however, when approaching the creation of a website or application, consider the layouts of your Pages carefully as to better suit the function they will have to perform. It is frequently possible to map a certain layout to each level of the navigation tree of your application as Pages on the same organizational level frequently have similar function, even if related to entirely different data sets. You can see in Figure 11 an example of such a mapping.


controlling-layout-site-structure-level-layout.png
Figure 11 Diagram showing how the pages at a particular level of your site's navigational structure can be mapped to a specific page layout.


These different layouts can be easily implemented in Morfik 3.x with the usage of Page classes or templates that allow you to define a model for the creation of multiple pages that follow the same general layout. To implement the case that is shown in Figure 11 the a Morfik user would make use of three template or class pages. Read more...

Mapping your application's structure

Once you have thought through the first levels of your application and considered what "pages" you are going to have, you should have most of the material you need to begin mapping it out. Look over your notes and ask your self if some of the "pages" or "states" you have singled out have the same structure but differ in the content they are showing. If the answer is yes, than flag them. These might be candidates for being a single page with different parameters.

Breaking the Pattern

This does not mean that you should take such a relationship as a rule set in stone. Wherever necessary you can and should adapt a specific page layout so that it better fits the function it must fulfill. Having such a mapping of layouts to navigation levels will provide you with a starting point or guideline to consider how a specific function should be treated or handled in your application. If it turns out that the layout that is mapped to that navigation tree level is not adequate to that particular task you should adapt it and if necessary dump it entirely in favor of a layout that better suits the specific task.


controlling-layout-tree-branch-red.png
Figure 12 Diagram showing a branch of your site or application's navigational structure highlighted in red.


The diagram in Figure 12 shows how a group of pages within a project adopt layouts different from those mapped to their corresponding navigation structure level. In situations such as this you will generally see a branch of the tree which does not follow the initial pattern of layouts you had established for the website as a whole. Don't worry and don't be afraid to break with the pattern. The pattern is a useful tool to help you quickly figure out how you will probably need to handle the implementation of the interface for a specific functionality, but it should never become a straight-jacket that limits your ability to handle unforeseen situations.

The exception falls into a new pattern

When you break pattern and make some of your pages follow different layouts you will find yourself, more often then not, falling into a second pattern. You will probably identify that a new layout is a more adequate fit for a specific functionality or a set of them. In these cases you will simply have different mappings for different branches of a navigation tree with its set of "pages", as shown in Figure 13.


controlling-layout-branch-different-layout.png
Figure 13 The diagram above shows how the pages at a particular level of your site's navigational structure can be mapped to different page layouts, depending on function.


Having the map of navigation tree levels and/or of its branches will allow you to gain productivity as you have a solid starting point when starting the implementation of any functionality. You will check where it falls within your structure and see what is the appropriate layout for functionalities at that level and in that branch of the tree.

AS with the situation described in Figure 11, the situation described in Figure 13 shows that when you run into a situation where you have more than one set of patterns for page layouts they can still be handled through the use of a different set Page classes or templates.

There is not limit on the number of Page classes or templates you can have in your project or on the number of Pages either. The user should feel free to create as many Page classes or templates as the number of different Page layouts that will be used in the project.

Consistency

While using multiple layouts is proper and even expected in a well thought out Web based application or website a certain degree of consistency is recommended to help your users to more quickly become familiar with how things work in your application. Establishing and documenting the page layout patterns for your application is a valuable tool to ensure a satisfying and consistent experience to its users.

The introduction of the Page high level object as of Morfik 3.x makes the creation of templates to ensure layout consistency much easier than it was in previous versions. As a rule of thumb when working on a new project the Morfik developer should create at least a Page template for each layout he/she identifies in the application. Morfik makes it possible to derive a page class or template from another pre-existing page class or template. This can be useful for the creation of a more finely grained set of templates where a higher level of consistency assured.

Related Topics


Back to top