blog
CMS Application Development with Web Standards July 1st, 2009
No Comments Today’s Web sites and Web applications are getting more and more complex. On the front-end at least, this is largely because interactive features are getting more advanced. There’s been a jump forward in recent years in terms of Web browser capabilities that has enabled sophisticated, almost desktop software quality features. Loading external content, hiding and showing page elements, fixed positioning, animation, drag and drop, and alpha transparent layers have all become commonplace in advanced Web-based experiences.
One just has to spend some time on a site such as Facebook to see examples of many of these types of things. From Yahoo! to CNN, dynamic front-ends and user interfaces (UI) are becoming commonplace and even expected. I was just thinking the other day as I stepped through a slide show on a Web site, "why do I have to refresh this whole page just to see the next slide?" While a few years ago that was expected, now it’s a sub-par experience which is so 2000, or even out of the 1990′s.
The Risks of Building Complex User Interactions
As design and user interactions get more complicated, the server-side development gets that much more difficult with dozens or more touch-points on the server to output data. A single page could have ten different ways of looking at the same data being output many different times, just to fulfill all the different user interactions. If developers use traditional application development techniques, the effort involved in building this would be as complicated as it sounds.
More touch-points mean changes become riskier. With server-side development in particular, when something fails the entire page won’t render, escalating the chance that a user may not get their content. If a portion of a page widget doesn’t work, the entire experience may be affected, but it’s less of a dead end for the user than if the whole page doesn’t show up. That said, error handling for a small portion of the page can actually be more difficult.
As Web browsers have gotten more features, so too have Web developers, particularly front-end engineers, been armed with many new techniques that can simplify the way these requirements are fulfilled. It’s important that modern sites using these modern effects use the most modern techniques to build their sites. If they don’t, they’re doing themselves a disservice as the level of effort to build an application and the amount of risk in their applications increases tremendously. Modern techniques save development cycles for the application engineer and reduce overall complexity.
A Case Study in Modern Techniques
To illustrate what we’re talking about, I’d like to discuss the requirements of a portion of one of NavigationArts’ projects, the Wolf Trap Web site. This site features a full page-sized "Find Performances and Events" calendar of performances and events for the given and subsequent months (figure 1).
The calendar displays a month grid view with highlights from each day’s events, and the user is able to click on a date to get a pop-up layer with the full day’s events and links to the detail pages. The user can also switch, without reloading the page, to a "List View" which is a month’s worth of daily details rendered in a different way — a flat listing. Both views of data can be filtered by Venue, Type, and Genre, and the user can navigate forwards and backwards through the months with a Next / Previous set of links.
To add to the complexity, the homepage features a small version of this same calendar (figure 2), where a user can click on individual days and the performance titles appear off to the right of the calendar.
So let’s review what potentially may need to be built:
- Two calendars (large and small) need to be rendered in correct weekly format
- A pop-up layer per day needs to be positioned correctly with scroll bars so it fits well into the height of the box; each type of performance is color coded per the venue type
- A full month’s list view of the daily performances needs to be rendered on the same page as well
All of this was built in the context of the Sitecore Web Content Management System (CMS) as opposed to a fully custom Web application. Calendar event objects stored in the CMS are single entries, following sequences such as "every tuesday for three weeks at 2pm" and so forth. The CMS logic itself was complex enough without having to output the data in at least 3 different ways for the calendar component. For all these events we had no interest in creating numerous event objects in the database so the data was retrieved and merged to a calendar on the fly based on the rules. Bottom line, the programmer has a lot of work to do, so why make this more complicated by having them output the data as many times as there were views?
The Old Approach
What’s the best way to render all this data? Traditional Web development techniques might have meant the following types of approaches.
First, to render the calendar the developer might have needed to output an HTML table, complete with the logic required to output the days and start new rows as needed for each week on Sunday. He or she would need to do this twice, once for the large calendar and once for smaller version on the home page. There are a lot of formatting differences for the two HTML tables so they would need to keep track of them as well.
For each day the application developer would need to insert the correct snapshot of data for the performances and links for that day. Inline, the application developer would insert "onclick" JavaScript handlers to execute the “more” links. These would actually need to be done two different ways, once for the large calendar, and once for the small calendar where the actions taken are different.
Next, to output the pop-up layers, the developer needs to output a month’s worth of events yet again. This might be in a set of hidden DIV elements down at the bottom of the page. Each DIV element would probably be given a unique ID attribute, which has to be tied back to the "onclick" handlers that were previously inserted into the calendars, as noted above.
Onclick, the placement of the "more" link would need to be determined and top/left attributes assigned to each pop-up item. These pop-up layers also need to be displayed with some offset based on its position on the calendar. The dates’ pop-up should be aware of the bottom as well as the far right of the calendar so the layer isn’t off the right or bottom of the screen. Finally, on the homepage, everything is output to the far right of the calendar, but only the title and a ticketing link is output.
Next, the developer needs to return to their data set once again and output it all with the appropriate look and feel required for the flat, list-only view which the user can toggle to on the full calendar page (figure 3). We haven’t even begun to touch on how each event needs to look different per venue type, and all these presentation differences would need to be output at least twice.
Bottom line, the month’s data is output in at least 4 sets of HTML versions each with inline decisions about which version is being rendered at any given moment and how it needs to look. If this approach sounds reasonable, please keep an open mind and read on.
What if they could output it all once, and only once, in a single pass?
A Modern, Web Standards-Based Approach
Using modern front-end and Web standards-based code using Cascading Style Sheets (CSS) and unobtrusive JavaScript (JS) techniques on the front end, the application developer’s job is exponentially easier, and the end product is easier to build, debug, modify over time, and without question faster to develop.
First, rather than have the logic for the calendars built on the server, we output each day’s data inside an HTML unordered list (UL) as list (LI) elements, freeing the application developer up from having to build the calendar at all. Using CSS, we can make the LI’s look like date boxes on a calendar. The only calendar data they need to output is the year and the number of the current month that client-side JS parses. The JS takes this and applies a CSS class on the first day to properly lay out the calendar based on the first day of the month. This "first day" class indents the first LI from the left in the first row the correct amount. With the sizes applied via CSS, the calendar wraps the LI’s, which are floated using CSS, for each day to the next row as needed, generating a calendar. This works on both the large and small calendars exactly the same way with the same HTML but slightly different CSS.
Now, since the application developer didn’t have to worry about the calendar, they could focus only on building the rules for each event and matching them up with the current date, as the days in the month are output. Second, they only have to output all the month’s event data ONCE as opposed to 4 times with the old approach. How is that accomplished?
Each LI in the master list is output with the date, and it also contains a DIV that is hidden using a CSS "display: none" until the JS tells it to display. So, on the one and only loop through the data, all the information is output the one time. As the page loads, the JS runs through the LI’s in order attaching event handlers dynamically which adds the onclick required to show the DIV with the day’s data inside of it. The server-side developer doesn’t need to know anything about this JavaScript.
The JS also determines, based on date, which direction the pop-up should be rendered, adding CSS classes to the code as necessary, which is used to position the box when the layer pops up. The position is simply determined relative to the LI’s box. Each pop-up is positioned correctly based on the classes that have been applied and the corresponding CSS code. Each day’s events are color coded by venue name as a CSS class and the CSS handles the nuances there (figure 4).
Finally, what about that list view? It’s rendered using the same DIV’s inside each LI that are used for the pop-up layer, just laid out differently and all displayed at once in order down the page. When the user clicks the tab to switch views without reloading the page, the JS changes out a CSS class from "grid" to "list" around the whole UL for the calendar. This different parent CSS class changes the meaning of the interior CSS used to layout the boxes in the LI’s. With some effective CSS we are able to hide all the data which is not needed for the list view inside the LI’s and reformat the DIV boxes to simply appear one after the other, the full width of the content area. Data like the date and the "more" link are hidden.
So What Did We Just Build?
There’s even more going on here than I just explained. The calendar works on the homepage with Ajax, and the calendar and list view choice on the large calendar page persists with a cookie if the user prefers one view over the other. Then each type of Venue and Genre and so forth may be filtered. The programming involved is complicated enough without having to worry about all the different views of the data. Finally, we barely scratched the surface of the way the code on the homepage works, but suffice to say, the front-end code carried the burden.
In a nutshell, what was done means that the same exact HTML produced from the server powered at least three different views of data: (1) the small home page calendar, (2) the large calendar view on the interior of the site, and (3) the large list view on the same page as the large calendar. Effective use of JavaScript and Cascading Style Sheets does most of the work.
The CMS developer only had to code a way to output the data a single time, as opposed to at a minimum 4 different times with relationships being created up and down their code.
So the moral of the story is modern interactions can be helped by modern techniques which make the management of the code easier. If that doesn’t sound better, I don’t know what would.
Newsletter
Sign up to receive our monthly email newsletter about strategy, user experience, and technology.
Careers
We are looking for experienced professionals to join us and contribute to our clients’ success.