Slightly over a week ago, I finished my fourth Cleveland GiveCamp. GiveCamp is a weekend of developing websites and other things for area nonprofits. As usual, it was a good time. My project this year was an update to Lake Erie Ink’s site. They had actually had their site built at the GiveCamp two years prior (I was not on that project, but know someone who was). They just wanted a map added to their site that showed where kids were writing or writing about. With six developers and a developing project manager, along with a WordPress plugin, we were able to get the basic functionality working rather quickly. So quickly that we had something working Friday night and started shedding developers to other projects. By Sunday it was basically down to just me and the project manager (plus the Lake Erie Ink people, of course). We added in some extra improvements in addition to the map. We brought in a couple of designers for brief stints to help us with some design issues.
For my part, I did help some with the map, but spent most of my time making their site responsive and tweaking the home page to include a callout for the map page. The site had not been designed with responsiveness in mind at all. It had nested divs with fixed pixel widths that accommodated padding of the parents’ even when width: 100% would’ve done the same thing. In addition, id’s were used a lot, even multiple times per page, there was a lot of unnecessary redundancy and extra CSS in the styles (such as repeated blocks and things like margin: 0px 0px 0px 0px), and extra heading elements were made up to provide extra heading styles (h7, h8, and h9). The templates were confusing at times and some had different versions or nearly identical related templates.
So I did some looking for other options. I found a discussion of a technique that seemed fairly elegant. I had been reluctant to use it in the past because of browser support and just being a bit uncomfortable with it. The technique makes use of the attr() expression to inject content. Since any browsers that support media queries should support attr() and I was using this in a media query, I thought it worth it to embrace it finally. I liked the results and will probably make more use of it in the future, especially since the browsers that don’t support it now have low enough market share to almost ignore.
One might contend that most viewers won’t be switching their viewport dimensions, but window resizing does happen, text can be resized (for ’em’ breakpoints), and mobile devices can be rotated. The site should not break when this happens. Also, even without changes, the correct behavior must be run.
For dealing with this, I have created a ResponsiveHandler class that listens for resizing of the window and fires an event when changing breakpoints. For each behavior that needs it, I listen for this event and run the appropriate construction and destruction depending on what the new and old breakpoints are/were. Behaviors can also simply use the class to determine which breakpoint the site is currently in and act accordingly.
I’ve been doing quite a few responsive sites since I first started into them. I like doing them. They are fun to build, requiring new techniques and a different way of thinking to handle different situations. I like the concept and I like looking at the sites. One recent fun thing was dealing with an image map (on this page). Scaling the image and coordinates would be a pain and very expensive. An alternative option is to replace the image with a select drop down when the screen is too small for the image.
I’ve been interested in the basic idea of responsive design since I first started into web development. Back then it was mainly limited to flexible widths that accommodated changing screen widths and font sizes. I experimented with that when development was just a hobby. Still, I found CSS2 and browser compatibility issues to greatly limit the flexibility. When starting to actually get paid as a developer, I went with what was already being done at the places I worked, which was pixel-perfect design. Sites had to work in old browsers and time was limited. Designs were flat images that were easy to cut up and use CSS to match exactly. I did play with some flexibility when I had more free time.
When responsive design became a thing, I thought it looked pretty awesome. It gave a lot more flexibility than what I had been playing with. Still, browser support was too bad for parts of it for me to use at work. I played with some aspects of it, adding a bit of flexibility here and there, but still kept mostly with the pixel perfect type design. When we eventually discussed it with my boss, he didn’t like the idea, particularly for accommodating his designs and the browser support issues. I started a yet unfinished remake of my own site that allowed me to play much more, but didn’t get very far towards a finished design.
Recently, my boss came up with a simple design for a simple site that he thought would be perfect for trying responsive techniques with, the annual report for the Gay Community Fund. It lent itself well to flexibility and him and the client were fine with graceful degradation / progressive enhancement. It consists of basically two layouts: the home page, with a gallery layout of boxes; and an internal layout with a heading, a possible image, a possible small image gallery, and a possible long list.
As I’ve mentioned, at Cogneato we’ve been building a new version of our CMS using Symfony on the server side. I’ve spent a LOT of time with Symfony now. I like it and will be using it for some other projects outside of work as well. We’ve been working on some eCommerce type sites that will hopefully be launched in the coming months, while building the system that all of our sites will eventually run on.
Though I like it, there have been many challenges to deal with, especially with making Symfony work with our old system. We have way too many existing sites with more than enough custom programming to convert them completely to a new system, so we’re setting it up so that both can be run side by side on old sites, while new sites will eventually only need the new system. But it has been a lot of effort to get the two working together properly. Symfony is inflexible in some ways, and not well documented in some areas. I intend to, in the coming months, write about my solutions for the various issues we’ve dealt with.