Releasing: Comatose WordPress Theme

This has been in the pipe a long time, it started simply as a set of experiments playing with HTML 5, layouts, responsive design, page structure, typeography, displaying images on mobile screens, the mobile web, minimalism, and my own dislike with the previous design(s) of my site. Finally, I decided to turn it into a full fledged WordPress theme. This is the result. It powers my site, and the InterKnowlogy development blogs where I work.

So here is the low down:

  • HTML 5 layout with CSS 3 styling
  • Responsive Layout
  • Clean, minimalist design
  • Print style
  • Clean, readable, and consistent text styling.
  • Clean and readable typography.
  • Clean display of code.
  • Beautiful images
  • Images display at native resolution on Regular and High Density screens
  • Widget enabled sidebar support
  • Nested comment support
  • Gravatar image integration for comments (High resolution images for High Density screens)
  • Custom menu support
  • Nested sub-sub-sub menu support
  • Graceful degradation in older browsers

But don’t take my word for it. Download links, versions and release notes are all on the project page:
http://www.paulrohde.com/development/comatose/

And all of the source code is hosted on GitHub.

Desktop Screenshots

Comatose Windows with Chrome showing Sidebar

iPad Retina Screenshots

Menu

Comatose iPad Retina Menu

See more screenshots

Designing for code: Copy & Paste

As a developer, I’m constantly on the web. Learning, reading, finding solutions to problems or looking up odd bugs. There is a great community of developers that are constantly publishing solutions / fixes / workarounds / techniques for the benefit of their fellow developers. Being developers, you would expect to find that the sites they run are easy to use across the board! For the most part they are but every now and again though I run across a site that makes me want to bash my head against the monitor. Why? Because it breaks the simplest feature:

Copy. Paste.

If you EVER post code on the web on a site you control, or if you are in charge of a site where you or others post code. Make. Sure. Copy. Paste. Works. Period. I’m not just talking about ‘I can select it and paste it’ functionality, I’m referring to those ‘code highlighting’ plug ins that add line numbers to EVERY SINGLE LINE of a code snippet when you paste.

Don’t Do It.

There are lots of good highlighting plug ins out there, sites that will format your code for you, and so on. Whatever method you chose, test it and make sure you can use the code from your site without having to modify or do anything to it. If you can’t, abandon it. Find something else. Use raw text. Whatever it takes to get the basics working well.

In addition, make sure your code works well when the site is scaled up or down. If you have a site that doesn’t change width as the browser size changes, ignore this, and read this post on fluid layouts: http://www.paulrohde.com/on-modern-layouts-and-semi-fluid-grids/. Now IF your site changes width, your code should ALWAYS work on whatever size the visitor is looking at the site on. Check it on a smart phone. Check it on a tablet. Stretch your site across two wide screen monitors. If it ‘breaks’ (as in becomes unreadable or inaccessible) fix it. Go back to the basics. Remove / alter / don’t use a plugin. Again, do whatever it takes to make the basics work.

Don’t underestimate the importance of the small supposedly insignificant details. In all honesty, users aren’t going to come to your site and praise you for what an elegant job you did on making your code easy to copy and paste, or how nice the content looks, or how readable the article is. Its similar to the way people will notice spelling and grammar. If your sentences are well formed and correct and the article is well structured the person reading should never have to mentally think about it. On the other hand, if an article is not well crafted, that person will have to wade through the mistakes and mentally jump between what was actually written and what the author intended. In same way, whatever type of content you present to a visitor, it should always be presented it in such a way that the person consuming it can do so without ANYTHING getting in the way of them doing so effectively.

Think about it. Go check your site. Make the net a better place.

Baseline Grid Script

As I’ve been working on the comatose theme, I’ve been doing my homework and some research into typesetting and vertical rhythm (http://24ways.org/2006/compose-to-a-vertical-rhythm and http://www.alistapart.com/articles/settingtypeontheweb/). Similar to how a lined piece of paper works, I want to get the styling of my content to line up as closely as I can to those lines, in most cases. To do that, I went looking for something that would overlay a simple, custom spaced ‘lined piece of paper’ if you will over my site.

For once, I wasn’t able to find something suitable for what I wanted. Annoyingly, almost all the solutions I could find were some variation of ‘make a grid image in photoshop and tile it on an overlay’. While quaint, I wanted something I could easily tweak the baselines on without making several different images. So, my quest resulted in a little script that uses HTML5 canvas drawing and jQuery to build up a baseline grid, a little magic to figure out the baseline and font size, and a button easily switch it on or off for whatever site its put into. I’m considering turning it into a chrome plug in at some point to allow me to use it on any site, but for now you can use it as is.

For your perusal and tweaking pleasure:

http://gist.github.com/1270673#file_type_setter.js

To use, include the following lines in the header of your html, make sure jQuery is imported somewhere before this:

<script src=”typesetter.js” type=”text/javascript”></script>

Fluid Grids (Part 2)

As promised, I’ve pulled in scans from the paper diagrams and notes for the layout of the theme I’m working on. Realize that these are raw notes, brain dump on paper. You can read the previous post here.

Layout Snapping

Golden Grid Layout


Designing interaction like this for a site is really similar to the way someone might put keyframes into an animation. The frames you see are the key transition points, even if there may be more in between as the site scales from large to small. As I was brainstorming on paper, I decided the site needed to hit the following key stages:

A) This is the tallest and most minimal your site will ever be. Your user is most likely on a mobile device, a small screen, or is just tinkering with your site. Regardless, these are the key points:

  • Header and footer span the screen. Always.
  • Content has a small horizontal margin. Even on a small screen you don’t want to lose ALL your space and make it feel cramped. Your goal is to make it readable.
  • Ever section, subsection, aside, and floated items are all in order, in line.
  • Navigation is vertical.
  • If the theme were to have ads, this would be the time to hide / remove all but the lightest weight and least intrusive.

B) This is slightly wider. Your content has more whitespace along the sides, the content is wider. You may be on a tablet, or possibly a phone in landscape. You don’t know.

  • Header and footer span
  • Content has a slightly wider margin
  • Most sections and subsections, asides, etc are still in order
  • Navigation is probably still vertical (this will depend on how many items you have)
  • The sidebar, which was stacked vertically in A, is now floated into two columns of items

C) Similar to the same pattern, Your content has slightly more whitespace along the sides, and the content is wider. A good percentage of your desktop browsers will be hitting your site at this stage, along with tablets, smartphones are probably not this wide.

  • The sidebar, is now 4 columns instead of 3
  • Asides are probably floated
  • Navigation is probably horizontal

D) At this point, the sidebar flips up and is now alongside your content. Most of your content is at its largest width and you probably don’t want your paragraphs growing much wider than they are right now since long lines makes reading difficult. This transition from C to D was interesting since originally I had the content area scale until the sidebar had room, and then it snapped down to be narrower than before. To avoid that, Between C and D I fixed and centered the main content area, and when the sidebar could be moved up alongside the content, I made the switch, and allowed the content to grow from then on until C.

E) Finally the width of the site is maxed out and centered. All your content is stretched out as wide as it can be, this’ll usually be someone with a wide-screen monitor with the browser maximized. Usually.

Conclusion: One of the key benefits to designing a fluid theme is the instantly correct look you get when you open the site. Its not something people will or should consciously expect, it should simply BE the correct size the instant it appears, regardless of size, screen, or orientation. (Censored discriminatory jokes about size and orientation here). Its like walking into a store. A well designed store is easy to navigate, spacious, and consistent across all the stores you visit regardless of its size. You don’t ever think about it because you’re not there to analyze the layout of the store. Your there to buy groceries. Anything that gets in the way or makes it hard to find what you’re looking for will stick out, and if it’s bad enough, you’ll go somewhere else. Its the same way with a site or blog. Users are there for a reason: For information, or to read, or to consume whatever content your serving up. They’re not there to analyze your site and how it’s designed, but if there’s any difficulty in getting to what they want in the form they want it, 5 seconds later they’ll be somewhere else.

It’s important to be intentional about the decisions your making and how they will affect the final layout of the site. The more you reduce the complexity of the interactions, and the better defined the interactions are, the better the final end result will be. Use what you design. Do what your users do. You’ll know best what you do and don’t like and what feels right. Go with it, but don’t be afraid to stop, backtrack, or even completely scrap good ideas if they are not up to your standards.

Using less.js Locally with Chrome

There’s been an issue plaguing me for the last week or two where chrome refuses to load and run less.js and .less files, but yet works just fine in Firefox or IE.

Here’s what I found: Turns out this the problem is caused by a security feature in chrome that disables any script that loads from file:///[path to script] from running. If you edit the shortcut for chrome and add this switch on the end: -allow-file-access-from-files Chrome will load and run your local scripts when it’s launched from this shortcut. It fixes the less.js problem and makes it actually usable for testing and debugging local sites.