One of the biggest challenges we’ve faced so far in the development of the Assemble-a-Site project is that of horizontal stacking. The global layout system requires that the header and footer each contain three columns, and each of these columns needs to stack its content blocks horizontally.
Our content management system is designed to allow the user to add content blocks to pre-defined columns. The blocks stack one on top of the other, and fill the entire width of the column. This arrangement quite closely approximates the way HTML naturally stacks blocks of content on a page, so the system works easily. We decided, however, that the header and footer columns need to fit into a small horizontal space, but may need several different types of content block in each column, so the content blocks need to sit next to each other, rather than stacking one below the other. This alignment does not in any way approximate the natural workings of HTML, and we had to come up with various techniques to make it work.
On the website itself, the solution was pretty simple; we just lay all the content blocks out within a single row of a table. The table automatically calculates how wide each content block should be, and handles wrapping. We have no problems with using tables for layout, so we aren’t kept awake at night with moral issues about this. Simple.
Sizing
In the CMS, however, we hit a number of issues. The first was the attempt to present a WYSIWYG interface. This means that each content block needs to be displayed as it would on the website, with the same wrapping, and taking up the same vertical and horizontal space. This is not a problem with vertical columns because, as previously mentioned, the HTML naturally helps us to approximate WYSIWYG, even though the content blocks are structurally very different in the CMS (the CMS loads each content block into its own iframe, to allow complete isolation from the styles and formatting of the CMS and other content blocks).
The vertical columns all have a fixed width, and a variable height. The horizontal columns do not have a fixed width, and to cope with wrapping, they don’t have a fixed height either. Iframes, on the other hand, have a default width of 300 pixels, and they require a definite width to be applied to them. Irritating. The solution to this is to use off-screen measuring. We create a hidden iframe, and in that we construct the full header with exactly the code we’ll use on the website. We then measure each of the content blocks, and apply that width and height to the actual content blocks in the editor. This is a fairly complex business, and the re-measuring needs to be done every time anything changes in any of the header or footer columns, but it seems to be working nicely.
Spacing
The second issue is that of spacing. With vertical columns, when we add more and more blocks, the column extends downward, and the page scrolls down to compensate. No problem. Websites are designed to scroll up and down. Not so for left-to-right. The website, and the CMS for that matter, is designed to work within a limited width. Now, on the website itself, we manage this using the table layout, which will attempt to wrap content to fit it within the allotted space. If the content cannot be wrapped to fit, it just pushes the design out, and makes the site look ghastly. We are relying on the site owner to notice this, and make adjustments accordingly.
In the CMS, however, we are faced with the distinct possibility that we’ll have more content to manage than we have space to keep it. The user must be able to mouse over every content block in order to access its control buttons, (especially, in this case, the delete button). The easiest solution would just be to use scroll bars, except that we need to be able to access all the content blocks while dragging as well. In that case the mouse button is already being used, so it can’t be used to scroll.
My solution was to provide mouse-over scroll buttons just inside each of the columns. These simply slide the contents of the column left or right while the mouse is over the button, irrespective of whether the mouse is currently being used in a drag operation or not. The buttons only appear if there is too much content in the column.
Columns
The third issue was that of column spacing. In each of the two sections we have three columns, one on the left, one in the middle, and one on the right. Each of these columns needs to be separated and outlined, so the user can see them, and so that controls can be applied to them (eg: an “add new content block” button). Spacing these columns is no problem if the content of each column is small, because we simply place the column in their respective position (left, middle and right). Problems arise when one or more columns contain content that extends beyond their evenly allocated third of space. The other columns then need to be placed in their share of the available space.
The solution we came up with was to extend the off-screen measuring system to include measurements of the whole columns as well as just the content blocks. We then manually position each column, rather than trying to align it. We also calculate exactly how big each column can be, and calculate whether or not they need scrolling buttons.
Putting these three techniques together, we produce an editor that allows the user to dynamically modify content blocks in columns that stack horizontally. It is a slightly painful fact that nine times out of ten, this functionality will not be needed, but I hope that this functionality, and all the other features like it, will make Assemble-a-Site the best system of its type out there.
