Meeting the stars

Summarising all the discussions I had during the weekend would be pretty hard, so I’m not going to try. Many non-profits in the UK are finding WordPress well-suited for their purposes, and I had lunch on Sunday with some of the many designers and developers working in that sector. It was interesting to hear their stories, having also done some sites for non-profits in Finland. Probably the biggest thing for me though was the chance to have a chat with some of the WordPress key figures, notably Nikolay Bachiysky (core committer involved in localization, and developer of GlotPress, the invaluable translation tool for non-english-natives) and WordPress UX and community person Jane Wells. There’s something really cool about meeting two people who on one hand, have made it easy to distribute the very laborious job of translating the WP interface, and on the other hand had a huge influence on transforming the admin interface into the sleek thing it is today.

WordCamp Finland?

Jane gave us some good tips on organising a WordCamp in Finland, which might still be some way off. The community in Finland is still making baby steps, but we’ll get there someday. A good point made was to start small with regular meetups, and then perhaps start to build up a group who might be interested in organising and, above all, attending a bigger event. I’m pretty sure though that there are plenty of interested parties, we just have to dig them out of their holes. To Finns reading this: do join the Finnish WordPress forums … (<em>In Finnish</em>: suomalaiset seuratkaa WordPress foorumeita)

Thank you Manchester!

Manchester was a great place for the event, and we got to see some night life too. Big thanks to the organisers and everyone else I had a chance to talk to, maybe will come back next year!

Attempting to log on to the WordPress localization service, I got this lovely error screen:

The Tampere HUB is itself part of an international network of workspaces – the concept best defined by the HUB people themselves:

The Hub is an initiative to build a network of places around the world where entrepreneurs, innovators and changemakers can meet and work together to tackle the world’s most pressing social, cultural and environmental challenges. A place is needed to inspire and support imaginative and enterprising initiatives for a radically better world.

Example HTML

At the top level, my example HTML page has a #wrapper div, which contains a #header, #main div containing all the interesting stuff, and a #footer. The main section has #content, #primary, #secondary and #tertiary divs for the different content areas of my page. The first two content areas, #content and #primary are wrapped up in an additional #container div, but your own markup may obviously differ.

[html]

 ... 


 ... 
 ... 

 ... 
 ... 



 ... 





[/html]

Prepare your styles

The basic idea here is to have different CSS styles for each width. The styles could be changed directly through jQuery, but that would quickly result in a lot of messy code. Instead, we’ll use jQuery only to change one class attribute. Initially I’ve added the class ‘normal’ to the body element to ensure a sensible default for browsers with JavaScript disabled, but we’ll also need styles for ‘wide’, ‘slim’ and ‘narrow’. This is easy to do with CSS descendant selectors:

[css]
#wrapper { margin: 0 auto; }
#header {overflow: hidden;}
#container,#content,#primary,#secondary,#tertiary
  {float:left;}
#footer {clear:left;width:100%;}

/* Wide ( over 1100px ) */
.wide #container {width:60%;}
.wide #content {width:66%;}
.wide #primary {width:34%;}
.wide #secondary,.wide #tertiary {width:20%;}

/* Normal ( over 800px ) */
.normal #container {width:50%;}
.normal #secondary,.normal #tertiary {width:25%;}

/* Slim ( over 600px ) */
.slim #container{width:66%;}
.slim #secondary,.slim #tertiary {width:34%;}

/* Narrow ( under 600px ) */
.narrow #secondary,.narrow #tertiary {width:50%;}
.narrow #secondary {clear:both;}
[/css]

Unfortunately versions 7 and older of Internet Explorer deal differently with percentage widths compared to most other browsers, and can result in some funny behaviour. I see two primary ways to deal with it: either feed IE 6 and 7 it’s own rules (e.g. a tested, fixed-width layout) or just make sure that the percentages never add up to 100 %. A nice explanation of this annoying feature can be found over at OJTech.com.

The jQuery

First of all I need to include jQuery, and perhaps the easiest way is to use Google’s jQuery for this. The main bit is a function, checkWidth() that (you guessed it) checks the width of the browser window and sets the body class attribute accordingly. The code below should be pretty self-explanatory.

[javascript]
	function checkWidth () {
		if ($(window).width() > 1400) {
			$('body').attr('class','superwide');
			$('#title').text('Wide ('+$(window).width()+')');
			}
		else if ($(window).width() > 1100) {
			$('body').attr('class','wide');
			$('#title').text('Wide ('+$(window).width()+')');
			}
		else if ($(window).width() > 800) {
			$('body').attr('class','normal');
			$('#title').text('Normal  ('+$(window).width()+')');
			}
		else if ($(window).width() > 600) {
			$('body').attr('class','slim');
			$('#title').text('Slim ('+$(window).width()+')');
			}
		else {
			$('body').attr('class','narrow');
			$('#title').text('Narrow ('+$(window).width()+')');
			}
		}
[/javascript]

In addition to this, all I need is some code that will tell the browser when to run the checkWidth() function.

[javascript]
	$(document).ready(function(){

		// check the window size when page loads
		checkWidth();

		// check on resize
		$(window).resize(function() {
			checkWidth();
		});

	});
[/javascript]

That’s it! View the finished demo.

After starting to write this post, I read the latest issue (#200) of .net magazine and noticed a mention of a very cool way to do a similar trick using only CSS media queries! Media Query demo by Bruce Lawson. Haven’t tried it out yet, but I definitely will.

Hope you liked the post, feel free to tweet it, or leave a comment below.

Fixed-width equals compromise

In the Beginning web sites were fluid, that is the content adapted to browser width. Today, most web design is fixed-width. That is, we build web pages to a maximum of about 900-980 px to accomodate the majority of screens. I’ll be the first to admit that most of the stuff I’ve made is fixed-width. Even my own blog is designed to a 700px width! It’s generally easier to design this way, especially if the design originates in Photoshop, which is essentially static. Also, fluid layout generally used to mean ridiculously wide and unreadable blocks of text.

Problem is, designing this way is a compromise. Many users today have wide screen laptops with 1280 px width or more, but their screen height may be a mere 700-800 px. Subtract from that the space taken by browser toolbars, taskbar/dock etc and you’re not left with much. On these height-challenged displays we should be using all the horizontal space we can to provide users with the information they need. But what about those narrower displays then, or people who simply choose to have their browser window at a narrower width despite having a large display? We’re not going to force them to *gasp* scroll horizontally or resize, are we? That would be silly. The answer is “intelligent” fluid layouts.

Fill that width!

On sites that have clearly separable content blocks we could be building layouts that intelligently re-arrange according to browser width. That of course does mean some more work put into the design phase, and possibly ditching Photoshop as a layout tool! The above image is a wireframe of  what a user would see on a wide screen (over, say, 1100px).

Narrowing down

On screens about 1024px wide we rearrange slightly, moving one content block (eg. recent blog posts) below the first one.

The narrower the screen is, the more we pile blocks on top of each other. This obviously requires more vertical scrolling, but all the content still remains accessible. Most importantly, we’re always using the best arrangement possible for the width of the browser.

Your thoughts?

What are you’re experiences of designing fluid layouts? Are there downsides to this, apart from the increased time needed for design? I’d like to here your thoughts, so please comment and share this on Twitter if you think it’s worth a discussion.

In Part 2, I’ll show an example of implementing the above with CSS and some jQuery, with sensible degrading in browsers with Javascript disabled.

There are many good URL shortening services around, like bit.ly, twu.rl and the WP-centric wp.me, and I’m not saying there’s anything wrong with those. However, if like me, you happen to have a nice short domain lying around that you’d like to use, why not make your own?

Install WordTwit

WordTwit is a plugin for WordPress by BraveNewCode for integrating your WordPress website with your Twitter account. I owe big thanks to Mikko Saari for telling me about it. The reason why I liked this specific plugin is it’s feature for creating short URLs using your own domain.

You can install WordTwit either directly from your WordPress admin (under Plugins > Add new) or by downloading the zip and uploading it to your server under wp-content/plugins/.

Redirect short domain to longer domain

There are different ways to do this. Because I’m running this site on a dedicated server, I created a new VHOST entry for the second domain (dani.fi) and inserted the following:

<VirtualHost *>
   ServerName dani.fi
   Redirect 301 / http://danielkoskinen.com/
</VirtualHost>

Replace dani.fi with your own short domain name and danielkoskinen.com with the main domain for your site. If you’re running on a shared web host, you can probably just create a redirect in CPanel or equivalent.

Configure WordTwit settings

Enable WordTwit, find it’s settings page and the section marked URL Shortening. Choose “Local” from the menu and save your settings. This will reload the page and reveal more options. You can now enter your short domain in the field marked “Use Alternate Domain”.

Save your settings, and you’re done!

Try it out

Go to edit any post, and you’ll find the short URL for the current post in the right sidebar, using your new nice-and-short domain name! There’s also a button to post a message to Twitter (which can be set up automatically for new posts with WordTwit).

About a week ago a submission to the WordPress trunk enabled a new mini-alert in the admin header, which reads “Privacy on” when the blog is hidden from search engines. Small addition, but very helpful when going live with a new site! I hope this feature remains in the final 3.0 release (due in May according to the current project schedule).

This is mostly due to the wonderful Pods framework by Matt Gibbs and Scott Kingsley Clark. Pods is a WordPress Plugin, but in reality almost a CMS in its own right. It allows you to create all kinds of custom post types, along with customized admin screens (with the Pods UI add-on) that blend nicely with the WP interface.

Why use a plugin?

My biggest complaint with custom post types in WP is that they’ll still all be happily together in the same monolithic wp_posts database table as all other WP posts and pages. Not very efficient, is it?

Pods is different. It creates separate tables for each post type and works the way relational databases are supposed to. Thus it’s potentially much more scalable!

Still, easier custom post types are a nice and welcome addition to WP and will probably be fine for smaller sites. You can read more about other nice things coming in version 3.0 over at WPBeginner: What’s coming in WordPress 3.0