This first phase will guide us through breaking down the comp to analyze the logical structure of the content and realize the grid system in place.
This will give us plans for both simple, semantic HTML and for how to lay out the page with CSS in the following phases.
We don't want to assume that having a design comp in hand is the same as understanding the content in it and its structure. So before creating an HTML document or writing any CSS, we should first analyze what is in front of us. First the we examine the overall hierarchy of elements, and then we look at the grouping and logical ordering of those elements.
First, we can analyze the overall hierarchy of the headings on the page. In doing this we should be careful to analyze the structural hierarchy of the content as opposed to the visual hierarchy.
Use the following as a guide:
<h2>, identifying each one's direct subheadings and marking them as
<h4>on down to
Note that some prominent content might not have an explicit heading over it in your comp. In such cases, note a label could be used for such a group, and note where it would be organized in the content's hierarchy.
Next consider which sets of content should be grouped together. Work through your comp, perhaps by making a quick wireframe sketch on paper, and outline each group or unit of content.
Only mark the significant groups or those that are worth distinguishing in order to keep the overall analysis from being too detailed. Too many details may be difficult to parse in upcoming stages. This approach facilitates moving from the outer-most layout down into micro-layouts, so feel free to keep it simple for now.
Finally, we determine the order in which to code our groups. In an ideal world this would be a matter of following the hierarchical structure and groupings we've determined in the order they're presented, from top left to bottom right.
Unfortunately, its not always this simple. It is quite common for designers to use the space available to them to present elements visually and not necessarily structurally.
So keep in mind that this structural ordering should focus on the structure of the content despite the elements' physical location in the traditional reading order of a visual layout. Mark the elements, or groups of elements in the order you actually would expect to encounter them as a reader. Many times this will not be an issue at all. But when in doubt, we must favor the logical order over the visual presentation.
Two key considerations arise at this point:
Anyone with a little experience building out pages has probably faced the temptation to code elements in presentational order, since, frankly, it is has been simpler to build out a layout in this fashion. But thanks to flexbox and the CSS Grid module we can finally really let our semantic analysis shine. We can now create our structure 100% for the sake of the content without any blurred lines for how this will be transformed and presented later. This also allows us to shuffle the presentational order of elements from mobile to desktop without extra markup or other fancy tricks.
However, this is can be a rather subjective part of this process. Where we're headed is to identify the following in our comp:
Consider the following process:
<body>tag the outermost container unit.
The bottom line here is to identify the key groups of content and the order in which they should be coded. Identify and number these in your comp before moving on to consider their visual positioning.
With the content thoroughly analyzed—structured, grouped, and labeled—we can move on to think about how the layout is set up. We need to move towards identifying any grid systems that we can later translate into CSS. We will look at each container unit first and later move inwards to identify micro-layouts present in any compound units.
Sometimes such a grid is explicit and obvious thanks to a existing markings in the comp; other times we need to extract one by analyzing the alignment of elements in the comp.
Regardless, start by looking at each primary container unit you labeled earlier one at a time, investigating the layout units inside to identify a grid.
Explicit grid systems may be in play in a design comp if you can clearly see rows and columns marked in the comp, or if a straight-forward analysis of the alignment between elements shows a system is in use. On one hand, software aids such as planning guides or layover boxes might be in use. On the other hand, a clear vertical and horizontal rhythm might be immediately obvious.
Regardless, identify the vertical column grid lines and the horizontal row grid lines based on explicit markings or clear alignment of elements. Disregard any grid lines that are not used as an alignment point by at least one element.
A grid might not always be explicitly used or immediately obvious. Sometimes a designer has an overall grid system in mind, but has been a bit liberal in exacting the system. Other times, no grid was used at all, and there is some work to do to extract one.
Use these steps to extract a system from a less-than-obvious situation:
Be careful not to overthink this or get too detailed. We'll investigate smaller grids or micro-layouts in the last analysis phase. Stick to the layout units directly inside of each primary container unit.
With this initial analysis in place we can now extract the applicable grid to use later in our CSS. If any layout unit contains a series of elements that are coded in the same order they appear and no elements are presented side-by-side—they're all stacked on top of each other—then you have no need for flexbox or the grid.
Otherwise, before we assume the grid system is the best solution, consider the following:
In either case flexbox might be simplest unless you prefer the centralized setup of the grid system. If you have anything more complex the grid will be a nice solution.
Once you've determined that the grid is the best solution, use this process to sketch the grid separately for reference later:
grid-template-columnsand, when necessary,
grid-template-rows. Keep in mind that you have several options:
frunit. In this situation you can either imagine the ratio of the size of one item compared to another along the same axis. Or, you can imagine the ratio a given track occupies out of the whole space, such as 1/3 or 3/4. If an explicit grid system is in play this might be more obvious. If it is not easy to deduce you can first determine the percentage each unit occupies, and then simplify these into fractions. While this seems to be the most work the result is a much simpler and very flexible ratio system moving forward.
autoas the dimension for the track. This is most commonly used for grid row tracks since height is typically fluid in web design.
grid-template-areasand assign content to them with the
grid-area. Keep in mind:
The end result here should be a sense of the overall grid that is applicable to use as the page is reconstructed with CSS. We now also have a stronger sense of the overall visual structure of the layout.
Many contemporary web layouts involve some more detailed areas that should be built as micro-layouts. You should have already identified such areas as compound units. These will implement a nested grid system in the context of that particular compound unit.
You can use the same process you did for outer container units to analyze the nested grid in these compound units. Similar sketches and labels will help you quickly set these up.
Bear in mind that some elements that appear beside others can be accomplished with a simple
float:right setting and might not warrant being treated as a whole grid layout. Likewise, elements that simply stack side-by-side might be best set up using flexbox.
Also watch for microlayouts that repeat throughout a comp such as thumbnail items, each containing several elements laid out using a grid. You will be able to set up this microlayout easily using classes or nested selectors, so only one sketch of the overall microlayout is necessary.
This site has a straight-forward hierarchy that is clearly indicated through the way the elements are designed.
When considering the logical order in which to code this content, most pages are also pretty straightforward, with the content logically running from top-left to bottom right consistently between mobile and desktop.
But the homepage presents an interesting variation for which our method will prove particularly beneficial. The mobile layout presents the masthead followed directly by the location and hours, then the banner, the menu section, orders section, and about section. This would be a logical order to code the page, considering a mobile-first approach: user research suggested that users wanted most of all to check the store's hours and location, and were least interested in a short statement about the store. Therefore, we have numbered the elements according to this priority.
When we transfer these numbers to the same elements in the desktop comp we can see a situation arises that would be challenging to create quickly with traditional CSS. The grid module should make this a snap, but will get to that later in our process.
Turning finally to consider the overall grid at play, we note the following observations on each page:
Overall: The masthead would be logical to set apart from the details of each page. So we'll establish a grid for this apart from what we do in the main content area of each page. Here we simply have two "rows" where the only fancy thing happening is lining up the navigation list item side-by-side. We'll note this as being simpler to achieve with flexbox and move on.
Home: Thanks to the variation in presentation order from mobile to desktop, we'll likely benefit from the grid module here. Looking closely at the boundaries of each group of elements, we can create a sketch of where grid lines could fall. This creates a grid that is three rows wide and three rows tall.
Each of the 9 cells can be numbers from top left to bottom right. We can also note that each column is equal in width, so our flexible
fr unit could be very helpful to make them fluid. Each row should be automatically sized based on the contents inside it. While most of the groups span just a single cell, the banner will span an area filling the cells 1, 2, 4, and 5, and the about will span an area filling cells 6 and 9
This page also include one microlayout in the "Come visit" group. Here three pieces of information are laid out in a simple grid. While we might be tempted to just use a table to mark this up, a simpler structure would be a definition list, and a simple CSS grid would make short work of layout this out. We simply identify three grid row tracks and two grid column tracks. The size of each track can be auto-generated based on the natural size of the text in each cell but with a healthy gutter between the label and corresponding data.
Menu: The thumbnails featured here could be implemented with either flexbox or the grid module. We'll opt for flexbox, since it would be a much simpler implementation, especially for the stuttered second row.
Product category: Likewise, the thumbnail layout here is simple enough that a flexbox solution would be simpler than one that uses the grid.
Order form: This page is straight-forward and could be accomplished with traditional float or CSS table styles as well as with flexbox. But its also a good example of a layout that the CSS grid layout makes simple with consolidated styles.
In this situation, we'll keep a semantic list-based approach to marking up the form fields where each "row" in the grid will actually implement its own microlayout based on this sketch. This way we keep a semantic grouping for each form field set, but can look at a common grid implemented by the overall form. We also set ourselves up for very simple responsive adjustments too. At the desktop size, each row in this form has a label set off to the left beside the field or set of fields that is approximately one third the width of the overall row. Four of the fields are single-line text input fields and are not as wide as the text area field; they're approximately half of the overall width of the overall row (leaving the remaining one sixth of the row as white space). The radio button set has two items that are positioned side-by-side and each takes up about one fourth of the overall row's width. Last of all, the textarea field occupies two thirds of the overall width of its row. With an overall mixture of halves, thirds, fourths, and sixths at play in this grid, we could use 12 as our base for flexible ratio widths for each grid track (since 12 can be divided evenly into halves, thirds, fourths, and sixths). With this in mind, we'd have four tracks set at
2fr respectively. We can then set up three sets of grid area configurations. Each one will place the field's label in cell 1, but one grid area set to be applied to the single-line fields will merge cells 2 and 3 while leaving cell 4 empty; another for the textarea will merge cells 2, 3, and 4; a third for the radio fields will place a radio field in cell 2 and cell 3 and leave cell 4 empty.
As we consider the markup to use for this application, we can start by thinking about the heading structure. Like many other applications we don't have many headings here to work with for structure. We can at least identify the text of the application branding as the primary heading and plan to mark it with an
<h1> element. In the main task list we have the option to organize tasks by their deadline categories, in which case a subheading will be used to label each group. It will make the most sense to mark these as
<h2> elements. Other than these headings we will need to rely more on the overall grouping to determine the core structure.
We do have a few lists in the application:
<form>. Each should be marked with a
<label>alongside the most appropriate input widgets.
Most of the elements that remain will be treated as either paragraphs or buttons.
Shifting to think about the overall organization in order to determine the structure in which to mark this content, we can quickly distinguish the primary elements of the application thanks to the distinct box-like presentation of these areas. Rather than just a masthead, body, and footer, we have four elements that will be best to present in the following order:
<header>element. This comes first in the source order as it is very simple and provides the context for all the content that follows.
<nav>element. This comes next so that the user can navigate to the desired category or project. Since this application will be a single-page application we don't expect many refreshes or new page hits. Yet this could still be a long list for a person using accessibility tools to move through. Therefore we'll provide a shortcut hyperlink to the task list at the top of this group.
<main>element, containing the content that is the focus of the application.
<aside>and placed last in the source order. They are important for the application to function as planned, but they're not as important to place earlier. Thanks to the CSS Grid Module we can place this at the end of the source order and easily position it where we want it with CSS.
With these groups and overall structure of the application in mind we can move on to consider the grids at play. First, the overall application can implement a grid in order to smoothly make the transition from the mobile to the desktop comps. My analysis suggests two columns and three rows for the mobile version, and two columns and two rows for the desktop version.
The mobile grid will fix the first column track at
60px but leave the second at the flexible
1fr. The first row track will be fixed at
40px, the second set flexibly at
1fr and the third set to auto in order to allow the option bar to control its size as it expands and contracts. We'll place the
<nav> in the first cell on the first row and the branding in the second cell. We'll then merge the cells in each of the other two rows in order to hold the task list and application options, respectively.
The desktop grid keeps a simpler layout with the first column track fixed at
300px and the second at
1fr. The first row track will be fixed at
80px and the second at
1fr. We'll then be able to shuffle the presentation order, placing the branding in cell 1, application options in cell 2, navigation in cell 3, and task list in cell 4.
Next we look at each of the four main areas and consider whether flexbox or grid is needed. The branding and navigation groups are simple enough to accomplish with basic content styling. Yet the other two areas need further consideration.
The task list itself is laid out in a simple tiling grid. Here we could use either the grid or flexbox. Due to the overall simplicity and desired flexibility from mobile to desktop, flexbox will be simplest, and no further analysis is needed. However, looking closer at each individual task a grid could be useful. On one hand the elements are laid out rather simply with the status checkbox placed neatly beside the due date and the task content. On the other hand, we chose to mark each task by placing the content first, due date second, and checkbox third in the source order. So while traditional techniques or flexbox could be used, we can instead make great use of the source order independence the grid affords and analyze a grid structure here. We find a two-column and two-row setup:
In order to enforce the layout concept while also allowing flexibility later we'll fix the first column and row tracks each at
30px but leave the other tracks at the flexible
The application options bar is another area with more complexity to consider. Thankfully, the source order matches the presentation order from left to right on the desktop display. Yet on the mobile display things are more complicated with some content hidden by default, and, when expanded, laid out in several rows. My analysis below shows this group's grid and the resulting template with the source order labeled on each grid area. The result is a four-column and three-row grid. We can leave all tracks set to
auto to allow the elements inside them to control their size.
This layout flattens into one row with five columns in the desktop view, placing each component in its own cell and hiding the expand/contract button.
Last of all we can analyze the modal window and its contents. Here we have an outer grid that allows us to center the modal window in the overall application frame. In both situations we'll have a three-column and three-row grid. The center cell alone will contain the modal content while the outer ring of cells will be empty.
On mobile it will have fixed
10px tracks on the left and the right but leave the center track at
1fr to flexibly fill the space between. The row tracks will be set to
1fr for top and bottom but leave the center track set to
auto. This way the modal content box's height will control the center track and the top and bottom tracks will evenly divide the remaining space.
Overall this simplifies at the desktop size as the modal content box should now be completely centered in the frame. Therefore, the grid columns shift so that the center track is set to
auto while the left and right tracks change to
1fr. Now the content's width will control the size of the center track and the remaining space will be evenly divided between the left and the right (see Figure 20).
Finally we consider the inner layout of the task editor modal window. Thankfully we've done some of the work for this component already, as it contains a very similar layout to the task cards in the main task list. Here there's just a little more space for the date and content editing fields, but we can actually reuse the same grid as we planned for standard task cards. Below the task editing fields there is a set of options to select the task type, save the task, and delete the task. This is the preferred source order for the elements so a simple three-column grid should allow us to alter their order. We'll place the delete button in the first cell, the types in the second cell, and the save button in the third cell.
Inside the second cell, the type options can be most simply accomplished using flexbox so no need for further analysis.
Content-out analysis for this site could begin on any page. We'll start with the student's "home" page, the "All My Work" page. Here we see the standard elements of a website including the branding, navigation, main content area, and a footer. All four of these elements are common among all the different pages of the site with some minor variations so work we do here will carry over to the others. Thinking first of the headings our content contains, we can easily spot the primary heading the branding, in the upper-left corner. A short tagline paragraph follows it.
Next, hierarchically, we notice the text, "All my work." Its prominence and bolder style suggest it is another heading in the page, very like the secondary heading. If we compare this to other pages, we see a similarly-styled line near the top of most of the other pages. It is likely that this should be the secondary heading on the other pages as well.
Back on the "All My Work" page other candidates for headings could include the bolded items in the sidebar navigation. However, these form a list of different categories of collections. So despite their bold styling I might instead take note of these as an outer list of collection categories and then the blue items underneath each could be a nested list of specific collections. Seeing no other headings in the page, let's solidify our decision to mark the sidebar items using a list and move on to look for other lists in the page.
Next we take note of the tiles of sample work items in the comp. These work well as a list of student work, each item having a name, date, and image of the work in question. Scanning around the rest of the page the remaining elements can be marked as paragraphs but with classes that might help us adjust their styling, such as the line directly under our secondary heading that is styled larger as lead-in copy.
If we look at the "Sophomore Review" sample collection page we notice many common elements as we identified on the first page. The same branding, navigation and footer are in place; the same secondary heading style and lead-in paragraph is also in place although the text content is different. We can also see similar thumbnail tiles. We have different kind of list here that the enumerated elements indicate—a list of categories in the portfolio. Each category has its name, description, status, and nest list of thumbnail tiles. We can also consider the names as our third-level headings on this page. The thumbnail tiles also two buttons or indicators that show the work items' review status and comments.
An identical heading and list structure is at use in the faculty view for the sample collection and in the collection manager. Yet the collection manager omits actual student work, showing instead options to edit and rearrange the categories and the collection as a whole.
The faculty view of a student's collection allows for one further step, where the professor can see a single work for a more detailed review. This page uses the same branding, navigation and footer and implements a similar secondary heading but there are not third-level headings. There are several paragraphs showing the date and description of the work. There is also a set of images of this work; students can provide up to five images showing different aspects of the work. We can mark this as a list and realize that the first image in the list is the feature image and presented larger than the others in both the mobile and the desktop arrangements.
This analysis completes all the faculty and student views of the application. The public view of the sample collection shows a very similar structure as in the faculty and student views of the same content. Yet here there is no sidebar navigation since this portfolio is to be viewed in isolation from other work. While it might appear that we no longer have a primary heading, we should note that there is still a very subliminal masthead that says, "Work by Student name." This truly fits as the new "branding" or primary heading for this page, so while it looks more like a paragraph, we'll choose to mark it as the new primary heading and simply style it accordingly. Therefore, the collection name is still the secondary heading and the category names are third-level headings. We have the same nested thumbnail lists that we marked in the other views of the sample collection.
Finally the public view of a single work also uses the same revised content structure as the public view of the main collection page. Yet here the secondary heading is the name of the work being viewed and we have a similarly-styled list of images as we had in the faculty view of the single work.
Now we can step back and think about the organization. All student and faculty views include four major components: branding, main content, navigation, and footer. I'd suggest that we mark them in that order. Here we choose to place the navigation after all the content as we expect users navigating this site using assistive technology will prefer not to wade through that navigation every time the land on a new page, but rather, get to the content sooner. Across these pages, the variation occurs primarily in the main section, and this is where we'll also find most of our grid analysis. We'll cover the organization of each of these chunks as we survey the grids we need. Note that the public views use three of these main components, but omit the navigation.
After sketching and analyzing the layouts and microlayouts through our site, we have can identify the following grids:
Overall: The overall layout for the four main components of the site at the mobile size will implement a grid with two columns and three rows. The navigation will be placed in the upper-left cell and the branding in the adjacent cell to the right. The two cells in the second row will merge to hold the main content and the two cells in the last row will merge to hold the footer. The first column is fixed at 60px while the second should be flexible and implement
1fr. The first row is fixed at
40px but the other rows should flex as needed using the auto setting.
The desktop arrangement for this layout simply resizes this same grid and repositions the components. The branding now occupies the upper-left cell and the navigation is placed in the first cell on the second row. The main content area spans the cells on the right side of the first and second rows and the footer spans the two cells in the last row. At this size the first columns is fixed at
300px while the second column is once again the flexible
1fr. The first row is fixed at
240px high but the other rows are left to a setting of
Finally, the public screens drop the navigation and implement a slightly different setup for the remaining three components. In the mobile view they're stacked on top of each other in the same order as the source order and fill the full layout, so no particular grid is needed. Yet at the desktop size the top two components are set in from the sides by an equal amount of space. Therefore, we'll identify a three-column and three-row grid at play here. The first and last columns will be set to the flexible
1fr while the center column will be fixed at
800px. All rows will have an
auto height. The branding is placed in only the middle cell on the first row, the main content is placed in the middle cell on the second row, and the footer spans all three cells on the last row.
Footer: The only component of the outermost components that has a microlayout directly inside it is the footer. Here we can observe two groups of content. The first group is the attribution that marks the Folio application as belonging to Cedarville University and show both entities' logos. The second group is the copyright statement for the application. The mobile version of the footer has these two groups stacked on top of each other in standard order. The desktop view simply presents them side-by-side. Therefore a single row with two columns should be used. The first column is fixed at
300px and the second is
Work tiles: Moving on to the details of specific pages inside the main content area, one of the most common recurring microlayouts is the tile presentation using for the work samples. This is used with small variations on desktop and mobile for the sample collection view for students, faculty, and the public. This will be simplest to implement using flexbox, so no further layout analysis is needed. We simply note the size of the tiles for desktop versus mobile.
Individual tile: While the overall thumbnail presentation is straightforward each individual tile implements a mircolayout as well. On the desktop comp the image is presented first followed by the title and date side-by-side. Yet we'd noted the source order should first enter the title, then the date, and last of all the image. The grid is perfect for this kind of setup. We identify two columns and two rows. The first row contains the image with its two cells merged. The second row places the title in the first cell and date in the second. We'll let the first column be flexible with
1fr but set the second to
75px. This way the more controllable set of data, the date, is contained while the title, which could grow in size from item to item, is given room to flex and wrap if needed. TO control the size of the thumbnail image the first row is fixed at
175px but the second is left at
The mobile arrangement of these elements appears simpler but still alters the presentation order from the ideal source order. We can use the grid just as easily to accomplish this. Instead of two columns we'll just have one set to
1fr. Yet we'll have three rows. The first, holding the image is fixed at
175px and the other two holding the title and date, respectively, will be left set at
Progress indicators: On the student view of the sample portfolio and when a professor is viewing a student's portfolio we have comped a small status progress bar component. This contains two paragraphs: one states the status, specifying how many of the required works are submitted. The second states the same information as a percentage. While the percentage piece is altered to present a progress bar, the two elements can be laid out together using a simple flexible grid with two columns. The first column holding the status text is
auto so it will grow with that text. The other cell is
1fr, which means it will fill the remainder of the row, allowing the progress bar to fill the remaining space.
Thankfully this component is implement exactly the same way on the mobile comp, since these flexible settings allow for the component’s container to control its overall width.
Introductory options: On the collection manager available to professors the introductory section includes options to edit the collection and navigate between student portfolios through a dropdown list. These two components can be presented side-by-side using a simple flexbox setup. They'll each have widths that adjust between mobile and desktop arrangements but flexbox will easily set them up.
Category layout: On the same page we find another simple microlayout that flexes from mobile to desktop with the same basic arrangement. The first of two columns will hold the details for the category and be set to
auto. The second column holding the options will be
160px on the mobile layout and
260px on the desktop layout.
Single work introductory block: When a professor views a single work the block near the top would benefit from using the grid. Here we find the title of the work, the date it was created, and a description. We also see icons that allow the professor to change its status and to add or view comments. These options should come last in the source order, but they're presented next to the title in both mobile and desktop arrangements. If we group the date and description together the title and options can be place in two cells side by side. The title cell can stay flexible with the
auto setting but the options should have a fixed width of
100px across all devices.
Work images: Also on the single work view, for both the faculty and the public presentations the images of the work in question are arranged in several different microlayouts. In all arrangements the first image is larger while the others are tiled up either below or beside it. In fact, we can plan ahead for an intermediate arrangement to make the best use of space for a responsive stop between mobile and desktop. The result is three different grids that rearrange the same five elements as needed.