Responsive, it’s how the web should be, it’s how the web was. Not everyone is a convert though, which is fair enough. It’s tricky, and some of the advocates aren’t being as helpful as they think.

Designing the browser is a terrible solution.

Designing in the browser. It’s the next big thing! It’s essential to responsive. If you can’t do it you’re not a real designer. This attitude doesn’t help responsive at all, it’s divisive, unrealistic and hampering design outcomes.

- One person doesn’t scale

The first issue I see which this approach is it’s scalability. If RWD is the future of the web, then it’s going to have to apply to more than just web designer blogs and agency sites, sadly these two categories are disproportionately represented in RWD. In these cases, you can have one person responsible for both design and development, however once the project gets bigger than this, it doesn’t scale.

Having a good working knowledge of HTML and CSS is good for designers. An appreciation of UX, design and typography is good for developers (which is not acknowledged often enough). However it seems like designers have got sick of working with developers so are now trying to do everything themselves.

Responsive should force the process to be a lot more collaborative than that. Designers need to work a lot closer with developers, the process needs to be less waterfall, more agile, in order to produce something beautiful and possible. While I’m advocating separate teams for design and development, the other extreme, when separate companies are responsible for design vs development, is no longer acceptable. Design companies need to realise that front-end development is part of their remit, out-sourcing this will only lead to poorly implemented designs, dissatisfied designers and underwhelming web design.

- Design is being hampered

While some argue designing in the browser is how the design process needs to be, there have been some reactions from the design community which need to be listened to. Knowing too much about the tech limits the design possibilities, it’s too easy to fall into doing the same thing we’ve always done. Creating boxes and then rearranging those boxes on smaller screens is not design. I believe the push for designing in the browser contributes to this problem. Is responsive to blame? No. This is a natural reaction of designers and developers attempting to get to grips with new tech, however we must get back in control.

Tech is our servant not our master, when we put tech first, rearranging boxes is a natural symptom. Separating the design team from the development team is good for everyone, especially design. I believe it’s better for the designers to try to create something without too much thought about how it’s actually going to work, as that pushes the tech further than starting with the tech and working back. Designing in Photoshop or Fireworks does produce constraints (notably fixed width), however it also gives some independence to the tech, which puts design back in control. The question designers should be asking throughout the process is “Can we do this?” not “What are we allowed to do?”.

- Mobile first isn’t for everyone

Another part of what’s holding responsive design back is the mobile first philosophy. Its the right development philosophy but it’s the wrong design philosophy. When you start with the simplest version (small screen) it seems like the desktop design suffers from being too similar to the small screen design, which then ultimately looks like rearranged boxes.

- Reality is…

Now let’s not throw the baby out with the bath water. You can’t make every design decision in Photoshop or Fireworks. However, that doesn’t mean you make no decisions there either. This is a team process. Developers, it’s time to step up, learn some design, become pedantic, and stop trying to make your job easier (read boring). Designers don’t let the tech limit you, push it, and then be prepared to step outside of your toys and negotiate in the browser with developers, they’ve got something to add too.

The false economy of responsive out of the box

There’s so much talk about new CSS libraries, grids, frameworks etc, it’s not helping. In fact it’s sending us down a dead end street. They’re great for prototypes, not for prime time, none of them allow for the inherent flexibility of responsive. I was an absolute convert to using utility styles, ever since seeing a Nicole Sullivan talk I’ve loved the idea of OOCSS. I spent two years working on my own set of utility styles which project by project got better and better, faster and faster. I’ve thrown that work away. It’s doesn’t work for responsive.

- Utility ain’t the future

While I used to have have a .grid_4 class, when I’m using responsive I have no idea whether that item will still be 4 columns wide at a different breakpoint. Or f_left (float:left), will it be floated at a large screen or a small screen? Assuming both isn’t going to work. The only reason this approach may be working for you now is that designers have yet to really push how different each breakpoint can be.

- Let’s be helpful

The problem with a library or framework is that by definition it’s not responsive. It’s not responding to the design, it’s dictating the design. This approach won’t last. I’m all for helping make things easier for people to start doing responsive, however not if it’s a dead-end street. Context styles not utility styles seems like a better approach, which means less code re-use but more flexibility between breakpoints.

Context styles: div class=”nav_secondary”

Utility styles: div class=”f_left grid_3”

Bad browsers are the past?

We’re all very happy that browsers like IE6 and 7 are slowly melting away like a bad dream, but utopia isn’t here yet. We’re still in the wild wild west, the web has yet to stabilise. We all know that testing on real devices is good, however trying to find answers about how to debug all these new browsers is going to take time.

- The old has gone, the new has come

I’m loving that clients are now dismissing IE6, and some of mine are starting to think the same way about IE7, the reality is testing isn’t getting easier. We have more browsers and more versions to test in. Testing each browser, in each version, at each size, takes time, significant time. I had IE7 and IE6 testing down to an art form, I knew the bugs, I knew the fixes. Now I have phones to contend with, Android I’m looking at you.

- In theory it’s good…

The last responsive project I worked on, the site didn’t have enough Android traffic to justify spending the time to test and fix any issues (they’re monitoring this, it will change), and testing was a breeze. I’ve loved testing iOs, every now and then it throws up a wee gotcha but overall an absolute pleasure. The project I’m now working on has significant Android traffic. So I got some Android devices, 3 of them, one Android 2, one phone Android 4, one tablet Android 4. What a debacle. I know feature detection is the way forward but quite frankly Android browser lies, it’s supposed to be CSS3 ready, it’s not. Android is my new nemesis, I’ve had to revert to user-agent detection in order to work around the issues, it’s IE7 and 6 all over again. It’s still the wild wild west, browsers aren’t ready for what I want to throw at them. This isn’t our fault, we’re pushing browsers manufacturers to do things faster than they can keep up. One of these days testing is going to get easier, but we’re not there yet.

- Lets be honest

It’s nothing to do with responsive per se, perhaps more about mobile as a whole but getting complex navigation working on such a wide range of devices is tricky. Adding touch support and not screwing up all your click events is tricky. Animating linear gradients while animating their container is tricky. I could turn around to my designers and start telling them what to do, but I’m not going to. Getting a design which you have no idea how to build and figuring it out is the best part of this job.

Pumped

I hope you get that I love this, I absolutely believe responsive is the best thing since sliced bread. I love it when a designer says “Not good enough, lets try again”. I love challenges. Sure I’m going to hate moments of it, like when I have to revert to user-agent testing in order to get something working consistently. However, in some ways I think it sorts the men from the boys, anyone can throw some CSS together, there’s 12 ways to do anything. However managing the complexity of multiple breakpoints, complex design and more browsers, means that planning, best practice and experience are needed.

So let’s not dumb it down, libraries don’t solve stupidity, they encourage it. Libraries aren’t the future, they’re just helping us cope with the present, but as soon as designers catch up, we’re in trouble.

Designing in the browser really has nothing to do with responsive, it has everything to do with team size, stop encouraging people to be a silo and start encouraging people to communicate, get better at their craft and work successfully with others.

Let’s stop kidding ourselves the web is mature, things are still pretty ugly, browser testing for one isn’t easy.

I love that this isn’t set in stone. I love that there’s not one way to do stuff. I love that the way to do stuff now won’t be relevant next year. We live in a pretty exciting time, so lets embrace it, warts and all. Let’s keep pushing things until one day some kid you work with has no idea what zoom:1 does.

On a side note, to all the people who complain about the maths!? Quit your job and become a gardener, this isn’t the career for you.

Here’s what I do, probably doesn’t make much sense with explanations, but that’s all I’ve got time for at the mo.

• Tag styles should be designed for content area not .content tag
• Font-size and line-height should always be paired
• Line-heights should match vertical grid, font size does not need to
• Use contextual styles as little as possible (.thisdiv p = bad)
• Don’t have empty tags for stylistic elements, use pseudo elements instead
• Don’t have non clickable areas between nav items
• Don’t put logos in h tags.
• Logos should be clickable
• ul ol, and inline tags should not have font-size declared
• Inline tags should always exist inside a block level tag
• Do not style the div or span tag, use classes
• Don’t over specify (div.someclass), forms are sometimes an exclusion
• Don’t use IDs unless for form elements or JavaScript selectors
• Don’t use CSS hacks
• Order rule sets alphabetically
• Use shorthand carefully
• Use images frugally, progressive enhancement is better
• Minimally style form elements
• Keep descendant rules as simple as possible (td vs table tr td)
• Nested ul styles are hard. Keep tag type styles together, all ul styles (ul, ul ul and ul ul ul), li styles together, and a styles together
• Only use sibling selectors for typographic niceties (h1 + h2)
• H1-6 styles should be done assuming a p will follow and precede
• Use padding (not margin) on h1-6 to get font on grid, padding combination   needs to match vertical grid

1. Reset stylesheet
   
   • HTML5 boilerplate in my goto
2. Horizontal grid
   
   • Double the number you think you need cos the designer is definitely gonna sneak in a 2.5 size grid
   • http://grids.heroku.com/ is my goto, sometimes without gutters so that my utility stylesheet can handle that, with more flexibility.
3. Typography based on content area, style tag elements
   •  p,
   • h1-6
   • ul
   • ol
   • br
   • a
   • table
   • th
   • td
   • blockquote
   • pseudo tags (.p, .a, .h1 etc)
   • Don’t do .content h1 (more about this in another post)
4. Vertical grid
   
   • This one is a doozy, odd pixel vertical rhythms are hard, but not impossible.
   • Line-height is important not font-size
5. Forms
   
   • I normally have a starting point for this for my favourite CMS Silverstripe.
   • Don’t try style inputs, although height for text inputs works quite well
6. Utility (OO)
   
   • Stubonella inspired, pre-canned
   • Alignment
   • Borders
   • Colours (text and background)
   • Display
   • Font display
   • Float
   • Margins/padding (t-shirt sizing => s, m, l, xl, xxl, xxxl)
   • Overflow
   • Position
   • Effects (border radius, drop shadow etc)
   • Z-index
   • Misc (clearfixes, image replacement etc)
7. Shell
   
   • Do this after forms and typography are done or you’re gonna rework a bunch.
8. Standard content page
   
   • Do this before homepage
9. Homepage
10. Other pages
11. Browser Testing

This is the way I understand tags in HTML. It’s not right (by right I mean symantic), by any means.

When I say ‘Styled’ I mean ul {} should be styled whereas div {} should not. I’m not saying div’s shoudn’t be styled I’m just saying don’t style the tag as a whole.

By typographic I mean these are the only tags that should get font, line-height properties.

Unstyled block
Div
Section
Article

Styled Block
Ul
Ol
Table
Tr
Hr
Header
Footer
Blockquote

Typographic block
P
Li
H1-6
Th
Td

Styled inline
A
Em
Strong
Sup
Sub
Small

Unstyled Inline
Span

So been working with a couple of contractors recently and trying to get them to do CSS how I like. Turns out I’m picky. It’s not that I didn’t know that, I just hadn’t needed to explain what I like and don’t like before so hadn’t totally consciously created rules.

The following posts are some thoughts. Largely incomplete.

A couple of times on Silverstripe builds I’ve run into the issue of wanting a DataObjectManager to be able to handle sub-classes. For example, a page has tips on it. There are tips which are a table of data, a tip which just has an image, a tip which is editable, a tip which isn’t. In the past I’ve put all the properties I’ve needed onto one tip object plus a type enum.

This means in the DataObject popup you only show type until the DataObject isInDB(). Once it’s in the database then you check the type and show only the fields appropriate for that type.

It works, but it feels nasty. 

It isn’t an issue if you have distinct objects which belong to a page but have no relationship with each other, however if you want a bunch of different things to be sortable then you have to do something as above.

What I’d like to have is one object which handles the relationship and then subclasses which inherit this and only have the properties which they need.

Until now DataObjectManager has been able to have two classes in two different manages but not two (or more) subclasses in the same and it seems a few people would like it.

http://www.silverstripe.org/dataobjectmanager-module-forum/show/12028

http://www.silverstripe.org/dataobjectmanager-module-forum/show/18264

Turns out it’s not too hard.

InheritanceDataObjectManager class
http://pastie.org/3182207

InheritanceDataObjectMananger template
http://pastie.org/3182209

How to add a InheritanceDataObjectManager to a page in the CMS:
http://pastie.org/3182218

And then the class structure should look like something like this:

http://pastie.org/3182234
http://pastie.org/3182235
http://pastie.org/3182239

You can extend the MyWidget class as many times as you like the InheritanceDOM will pick up the sub classes automatically (after you’ve done a dev/build of course) and add a ‘Add SubclassName’ button above the DataObjectManager.

Thoughts?

In this post we’re going to cover how silverstripe’s caching works. There are two ways to cache, both have pros and cons.

Static caching
Quite simply static caching saves the HTML output via php to a static HTML file. Silverstripe then monitors (via some functions you create/edit) when content is updated so that if an HTML file in the cache becomes out of date it can be regenerated. As the cached file is a complete HTML page it means performance is incredibly fast. Rather than hundreds of milliseconds or even seconds of php execution the page now the site will respond is less than 20 milliseconds. Fast.

There are drawbacks though. There is one cache per page which means dynamic data can’t be used. This means things like random quotes ( = no longer random), member details, or ajax requests aren’t gonna work.

Controlling what is and isn’t served via the static cache is relatively easy. There are three functions, allPagesToCache, subPagesToCache and pagesAffectedByChanges. The first function controls which pages to cache, the second two control which other pages to re-cache if this page changes.

http://pastie.org/2090183

Notice in the allPageToCache function I’m not caching form pages. This is because Silverstripe generates a unique code for each form to check whether the form request has been generated from a form, or if the page is being accessed via a CSRF attack. If the page is cached the code stays the same and Silverstripe thinks every form submission is a CSRF attack.

The subpages to cache is normally pretty straightforward as you know which pages these are and how and if they will be affected by their parent changing.

The third function can become very complex. Especially if you pull content from one page into the next. For example if a parent contains it’s child’s content, like a list of child pages with a summary. This means as opposed to the second function when the child changes the parent’s cache must be updated. Another example would be a homepage with a news list. Every time a news page is created or updated we need to re-cache the homepage.

So it can become tricky but for some pages very useful. So how do you turn it on? Firstly in mysite/_config.php add Object::add_extension(“SiteTree”, “FilesystemPublisher(‘cache/’, ‘html’)”); then in your .htaccess file change the redirect line from RewriteRule .* sapphire/main.php?url=%1&%{QUERY_STRING} [L] to RewriteRule .* sapphire/static-main.php?url=%1&%{QUERY_STRING} [L]. This will now re-route all requests to first look in the cache directory for the page and if that fails go through the normal request director.

Partial caching
Unlike static caching which caches the entire page, partial caching on caches a certain part, like a header, or a footer, or the sidebar of the page.

This does not have the same performance benefits of static caching. It continues to go through the standard request director however when the request comes to render the page, partial caching allows it to render chunks of html without having to access variables in the model or extra objects.

So which parts make the most difference to how long if takes to render a page? Menus. While the page you’re currently on is already loaded, menus must find a bunch of other pages and load them from the database, this is an overhead that partial caching can reduce and speed rendering up.

http://pastie.org/2095038

Above is the partial cache code I put around my navigation. As it’s only part of the page each partial cache piece must have a unique name, which also controls the when the regeneration happens. So this partial cache piece starts with ‘Navigation’, nothing special, I may also have a ‘Header’ one or ‘Footer’ one, call it what you like. The next parts after that tell the template renderer on which conditions it can use a pre-existing cache and when it needs to generate a single new partial cache piece.

Firstly ID parameter makes sure I have a partial cache for each page, so that the menu’s current/section states are correct. Without this every page would use the same piece and the menu states wouldn’t change to the current page.

Aggregate(Page).Max(LastEdited) tells the template renderer to check when ANY page was last edited. Surely we can just search when the top level pages were just edited? Yes you can, however as Silverstripe caches the result of queries for a request this query can be used over and over again in different partial caching pieces without needing slightly different queries.

Aggregate(SiteConfig).Max(LastEdited) makes sure the SiteConfig hasn’t changed since we generated the last cache. Particularly useful if you’ve extended SiteConfig, using variables from it like SiteConfig.Title or want to cache your head tag (do it).

If you have other DataObjects which aren’t pages and you’re using their properties in a page makes sure you add an aggregate with their class name. Aggregate(ClassName).Max(LastEdited)

Last but not least unless CurrentMember. This may need to be more complicated if you have a member’s area, however if the only members you have are CMS users then this saves your arse. To explain this let me tell you what would happen if you don’t include this. Your partial cache piece is created. Your CMS user logs in, changes some part of the page which is used in your partial cache. They click on ‘View draft site’, they would see NOTHING had changed. This is because they haven’t published the change so the cache still thinks it relevant. Adding it removes this issue.

You need to really think about how to write a partial cache key, if you get it wrong (excluding something that could change) then it will result in the page’s output not being updated correctly. Take your time, go through and check all the things you’re accessing.

Adding a partial cache to a page will actually make the page slower, as it has to do extra queries in the partial cache’s key. However this is only true on the first time a page is viewed, after that the partial cache has been created and will save on render time.

So as I said earlier use partial caches around menu’s (header, subnav, footers etc). Your html head tag is a nice thing to optimise. Lists of child pages or objects can also be sped up without too much difficulty.

Just a couple of tips here.

1) While you may be tempted to create lots of partial caches for small bits of content. Don’t. It’s better (read quicker) to have a slightly more complex partial cache key than 2 partial caches.

2) Don’t put partial caches around bits of HTML which contain no controls or $variables. The thing that partial cache is saving you is accessing those functions. It will not help static HTML at all.

3) Don’t nest partial caches. Keep it simple. It can be confusing when something hasn’t updated correctly as to why and what is responsible. It some cases <% uncached %> can help you remove complex bits from your cache.

4) When you testing your caches change <% cached ‘Navigation’ … %> to <% uncached ‘Navigation’ …%> to disable this cache.

I think you can get a 33% improvement in performance in less than a hour on a typical silverstripe site.

Firstly most of the clients I have won’t pay more than that anyway so I think 1 hour is a pretty good target.

There are three areas for improvement:
1) Files
2) Silverstripe caching
3) Apache setup

Files
To improve performance of files you need to start thinking about page requests like conversations on a cell phone. The more efficient the conversation the less it costs you. The efficiency comes down to two factors: less transactions and smaller transactions.

Less transactions
The easiest way to have less requests is to combine your CSS and JavaScript . Silverstripe makes this really easy. In your Page->init function you can use the Reqirements class to include CSS and JavaScript. You can also tell it to combine these files very easily.

http://www.pastie.org/2090172

Notice I set the combine directory to the themes folder? Normally silverstripe puts combined files into your assets so that it’ll stay out of any versioning. The issue with this is that if you do background images with syntax like URL(‘../images/myfile.png’) then it’s going to break. So an easy fix is to tell your version control system to ignore any files in these folders called combined.

I’m of the opinion that you should include all the CSS you’re going to use at this point. I used to have a combined CSS file which covered generic stuff and then I would include page specific stylesheets page by page, such as homepage.css. There is two things wrong with this. One, you really shouldn’t have page specific styles, I’m a big advocate for OO CSS. Second since the user is most probably going to visit the homepage first you might as well just combine with your other files.

JavaScript is slightly different. It would be nice if you could include everything up front but sometimes that results in worse performance. Firstly because you gave code that isn’t needed. Second because your may have code looking for things that don’t exist. So combine the stuff you use on all or multiple pages and leave page specific stuff out.

Now if you’re afraid its going to make your debugging harder, don’t worry silverstripe won’t combine the files until you put silverstripe into live mode.

Smaller transactions
So now we have less files we also want smaller files. The nice thing about the previous step is that combining files will reduce filesize. CSS will get slightly smaller and due to the fact silverstripe uses jsmin when combining JavaScript your overall JavaScript filesize should reduce. The downside of using jsmin is that it sometimes introduces code that older browsers like IE6 spit the dummy about. Make sure you always test your site in live mode if your combining any JavaScript.

Images
The other files you want smaller is your images. Firstly make sure you’re compressing the images when exporting from photoshop or fireworks. Second use smush it. Smush it is an image compression tool developed by the yahoo performance team. It strips out extra bytes from your images, however it will not change how your images look. It comes as a tool in ySlow, but normally I use the uploader. Don’t do this too early in your development, wait until your template images (logos, background images, icons etc) are almost ready for launch. Running these images through smush can save some easy Kbs. I’ve run some 450kb homepages through smush and seen 45k drop off. That’s the easiest 10% you’re ever going to see.

Part 2 coming soon, it will cover Silverstripe caching.

Update
As it turns out google has done some more performance testing and due to some changes in how resources are loaded newer browsers can load up to 6 smaller files quicker than 1 large file. See here: http://pagespeed-velocity2011.appspot.com/#14

I’ve been thinking. Web apps are not websites. Well they are websites but there’s a line between information websites (structured content) and web apps (structured functionality).

It’s not a small difference. In fact, they are poles apart. While they contain the same DNA (html, css, database etc) the way they are created, the way they grow and change, the way they die are entirely different. They are entirely separate metaphors.

The Family (Structured Content)

The family is an interesting metaphor. Every family starts somewhere, it grows, it’s connected. There’s a distinct hierarchy. Tags and clouds and the like seem to disagree with this, but really it’s just like labels. Cousins. Aunties.

Families are easy. You can start small. Then you can grow. Add new children. Adopt siblings. Some people become more important, some less, some die.

The best part is that the people don’t need to know anything about each other. The need to know the hierarchy or perhaps the other way around. However Uncle Jo is not affected when Auntie Carol has another kid. He also doesn’t care if she disowns one and Auntie Margaret takes them in. The hierarchy informs him if and when he is disowned, killed off, moved, or god-forbid has another child. Largely he exists unaware of the others, sometimes when he feels like it, when he’s particularly well rested and in a good mood he can ask the hierarchy and it will tell him.

The Ecosystem (structured functionality)

While Uncle Jo lives in relative isolation, fish are not. Eco systems are different. They, like families, can start small, however with every addition, change, deletion, the entire system is affected. You introduce rabbits, they’re a good idea, great as pets, won’t kill anything, good for food. They however, breed like… rabbits. Which now means crops are affected, which until this point were perfectly balances with other forces. OK, so now that we have have rabbits everywhere, we need dogs. Every change affects everything.

Now when a client informs me they need a new page, I mildly annoyed, they’ve had the content planner for ages. They’ve had an IA working with them to make good decisions. If they want to throw that out and decide they want pictures of rabbits on the homepage, then good for them. It costs a little more time, it shortens that buffer for launch date, but it’s their problem.

However when a client informs me they’d like to add some functionality. It’ll be easy. Just tack it on the side. It seems like a minor development to them. This is the moment I take a deep breathe. I sigh. I take another deep breathe. I sigh, in an attempt not to murder anyone and rub my temples. I take another deep breathe.

Then I explain:

“We have no idea what aligators will do the fish population.”