Arpia.be » Design

Tutorial: Multi-page, multi-column web pages

Peter Craddock — Mon, 01 Feb 2010 16:08:08 +0000

At some point in the redesign process of Arpia.be, I started to consider the idea of a “book-like” feel, where the content would be presented in two columns, and users could flip to the next page of content seamlessly.

The way I see it, this is something that has so far only been done using Flash, so it may be of interest to web designers & developers to see how they can achieve this without Flash, in a cross-browser compatible manner.

Our aim? To use CSS3 native support for multiple columns on the most “advanced” browsers (here: Safari, Chrome and Firefox), and to find a backwards-compatible technique for the others (in this case, Opera and Internet Explorer).

Basics: sources, …

These annotated files are used in this article:

CSS: ie_multicolumn.css (for IE), main.css (for all browsers), multicolumn.css (for Opera)
Javascript: css3-multi-column.js (for IE and Opera), pageturn.js, stylesheet.js

The web page that helped me the most with this design process was an article on A List Apart: “Introducing the CSS3 Multi-Column Module”, written by Cédric Savarese. In this article, Cédric not only explains the CSS3 multi-column module, but also the manners in which to emulate this behaviour using Javascript on browsers that do not support this CSS3 module. Cédric wrote a script in Javascript for this purpose.

There is, however, one issue with this article: the website to which it links, CSScripting.com, does not seem to respond (I’ve tried often). Using Google (or your favourite search engine), you can nevertheless easily find other websites using the script (“css3-multi-column.js”).

The HTML – containers

This may sound ugly, but the best way I’ve found to implement this trick, after much trial & error, involves as many as 4 DIVs around the content.

First, the DIV you would normally have used for the content. Second, the first DIV required by Cédric Savarese’s Multi-Column system (there must be a difference between these two, for reasons linked to the page turning effect – see below). Third, a DIV used for the transition between pages, for non-Internet Explorer browsers (this is linked to a fade effect, which doesn’t work as smoothly in IE – see below for the page turning effect). Fourth, the second DIV required by the Multi-Column system.

The HTML doesn’t look all that pretty, but I didn’t want to change the JS code too much, hence the remains of the “one” and “two” classes from the Multi-Column system:


	
	
		
			[put content here]

The CSS – all browsers

There is one major issue with the CSS3 multi-column module: so far, the browsers implementing it are Firefox (since v3), Safari (since v3.1) and Chrome (since v2). Neither Internet Explorer nor Opera support it.

- Source

We will therefore define general CSS rules for all browsers, and then add some stylesheets specifically for respectively Opera and IE, as the latter will use the Javascript method of multi-column, whereas the others will not.

The first element for you to think about is the total amount of content you want visible. In the case of Arpia.be, I wanted two columns of a height of 430px and of a width of 330px to be visible, with a separation of 60px, i.e. a total width of 720px.

In experimenting, I found it better to add some “padding-top” to the columns, for better display of certain typefaces with a higher baseline. The height of the containing DIVs therefore takes into account this “padding-top”.

Non-annotated CSS:

div.one {
	height: 435px;
	width: 720px;
	overflow: hidden;
}
div#columniser {
	height: 435px;
	width: 720px;
	overflow: visible;
	opacity: 1;
}
div.two {
	column-count: auto;
	column-width: 330px;
	column-gap: 60px;
	-webkit-column-count: auto;
	-webkit-column-width: 330px;
	-webkit-column-gap: 60px;
	-moz-column-count: auto;
	-moz-column-width: 330px;
	-moz-column-gap: 60px;
	height: 430px;
	overflow: visible;
	display: block;
	padding: 0;
	padding-top: 4px;
}
#columnified {
	margin-left: 0;
}

See the annotated CSS here.

The CSS – IE & Opera

Because of the way the Javascript method for multi-columns work (see below), some additional CSS entries are necessary for Opera and IE. In addition, IE and Opera do not handle the multi-column Javascript in the same way, so it is necessary to have different CSS for each, in addition to the main CSS file.

Opera:

#article {
	width: 720px;
	text-align: justify;
	overflow: hidden;
}
div.one,#columniser {
	max-height: 435px;
	width: 15600px !important;
	overflow: hidden;
	margin: 0;
}
div.two {
	column-count: auto;
	column-width: 330px;
	column-gap: 60px;
	max-height: 430px;
	overflow: hidden;
	margin: 0 0 0 0px;
	padding: 0;
	padding-left: 0px;
	padding-top: 4px;
}
div.two .columns, div.two .wrapper {
	width: 330px !important;
	height: 430px !important;
}
.columns {
	padding-left: 0 !important;
	padding-right: 60px !important;
}

See the annotated CSS here.

IE:

Disclaimer: I have only attempted to get this to work on IE7 and IE8, as IE6 would most probably require a whole lot more work (I found that IE6 crashed using the current, modified multi-column JavaScript – I did not seek to find the source of the issue).

#article {
	width: 740px;
	height: 470px;
	text-align: justify;
	overflow: hidden;
}
div.one {
	max-height: 435px;
	width: 15600px;
	overflow: visible;
	margin: 0;
}
div.two {
	column-count: auto;
	column-width: 330px;
	column-gap: 60px;
	max-height: 430px;
	overflow: visible;
	margin: 0 0 0 0px;
	padding: 0;
	padding-left: 0px;
	padding-top: 0px;
}
div.two .columns, div.two .wrapper {
	width: 330px !important;
	height: 430px !important;
}
.columns {
	padding-left: 0 !important;
	padding-right: 60px !important;
}
div#columnified {
	float: left;
}

See the annotated CSS here.

The Javascript – Adapting css3-multi-column.js

Now that those basic CSS properties are defined, we must examine the multi-column script, to see how it will be used in Opera and IE, before looking at how we switch between pages.

Cédric Savarese’s script is brilliant at enabling multi-column layouts on browsers not supporting this CSS3 module. However, it was made with the idea of a fluid layout in mind, and one where all the content is visible. We, on the other hand, wish to hide some of the content.

There are some issues with the multi-page adaptation of multi-columns that led me to change certain elements within the code of the Javascript I use.

First, Cédric’s script creates DIVs within an “available width” generally limited to the browser window’s horizontal length. It is our aim, however, to have all these DIVs sitting right next to each other on a horizontal line, for as long as it takes to display all the content. It is therefore to fix the available width to an amount far greater than the browser window width. In the Javascript, the line is “var availableWidth = 15600;”, but you can choose to make it far larger. In my case, it was because I did not believe I would ever go beyond 40 columns of text (at 330px for a column, 60px for the gap between columns).

A second important change was fixing the height of the columns within the Javascript. I found this to be necessary, as the reading of data from the CSS did not seem to force the Javascript to create the DIVs exactly as I wished them to be (see “var newHeight = 430;” in the script, az well as all the instances of “430″, which force the value instead of “newHeight”).

These values, “430″ and “15600″, are the two main points in my modified version of the script that you will want to change to your own values.

As regards height, another important change was to replace “findSplitPoint(elem, newHeight*i, wrapper);” in the “processElement” function with “findSplitPoint(elem, newHeight, wrapper);”, to avoid the creation of DIVs greater than the newHeight limit (430px in my case), even if there are only 10px more to complete a tag (a “P”, a “DIV”, …).

Furthermore, whereas in Cédric’s script, the containing DIV, the “wrapper”, could have a random ID, in our case it is necessary to define this ID for the purpose of sliding it in Internet Explorer (see below for the page-turning effect). Therefore, ‘if(!wrapper.id) wrapper.id = “columnified”;’. On a similar note, to allow better control of the columns, it is useful to define a class: “elem.className = “columns”;” (I also defined the wrapper class: “wrapper.className = “wrapper”;”).

Finally, at the top of the script, there is a list of “splitableTags”. I expanded this list to contain table-related elements, because I use tables in certain areas.

You can find this adapted script here: css3-multi-column.js.

The HTML – Turning pages

Now that the infrastructure is there, it’s time to work on allowing the user to go between pages, i.e. to slide the content so he/she can view the hidden columns.

We’ll be using Javascript for this effect, so here is the HTML for calling the page-turning function:


	
		Previous page
		Next page

In the function “changeColumns()”, the first value shows the direction, while the second is the title of the ID of the element clicked.

Why “-1″ for “Next”? When the user clicks on “Next”, we want the two visible columns to go left, to leave space for the next two columns. Because we’re playing on “margin-left”, as you’ll see in the Javascript file, we want the value for “Next” to be negative.

The Javascript – Turning pages

To turn pages, one can proceed in several steps. First, we must ensure that when the user clicks on the “Next” or “Previous” button/link, the content moves, and it moves to the correct place. Second, to create a better experience, we can animate this change.

The essence of the sliding of the content is that we’re playing on “margin-left” of the relevant DIV (if IE: columnified; if not IE: columniser – this is linked to the animation).

For my website, I chose to do a “fade out/slide/fade in” animation, but found that it was sluggish on Internet Explorer. This is the reason for which IE users do not need the “columniser” DIV.

Other animation choices are possible: you may choose to fade out the entire content and show a page-turning effect, if you have a book design. This is what I did for a “book” proof-of-concept design on which I worked earlier (here, it seems as though the user is actually flipping through pages of a book).

Here are the three sets of functions (4 functions in total) we shall be using:

changeColumns()

In our HTML for turning pages, we defined the function as "changeColumns()", with two values: first, a value showing the direction, and in second instance the ID of the element clicked.

animateSlide()

animateSlide(), as its name indicates, will animate the transition between two pages by sliding the content. As was seen previously, IE users are not faced with this function, because of the transition lag it causes.

setOpacity() and fade()

The two last functions relate to the fading in/out of the content. These are very standard, and work in all browsers (through the use of "filter" for IE – I have retained this here for the sake of completeness, but it is not used, as IE users do not see the fade animation).

Full pageturn.js

As the JavaScript involved is long, I have not reproduced it in this post. You may view an annotated "pageturn" script to see the functions with explanations for each step.

Serving the CSS and the Javascript

Finally, how do we combine all of this? We want Opera users to have the main CSS file and the Opera one, as well as the multi-column Javascript, but we don’t want Safari users to have the additional Javascript, given that they have CSS3 Multi-Column support.

The solution is to feed different files to different browsers, using Javascript:

if (/MSIE (\d+\.\d+);/.test(navigator.userAgent)) { //test for IE x.x;
	document.write("");
	document.write("");
	document.write("");
	document.write("

Then, the “pageturn” script must go in the footer:

Closing comments

And… there we go, a fully functional multi-page, multi-column layout, applicable to any number of web pages, without the need to resort to Flash. See a demo, without all the graphics of Arpia.be and using these files only, or a "book" proof-of-concept design on which I worked earlier.

The only issue, as far as I can tell, is that it’s impossible to determine in advance how long the content will be, and one cannot therefore avoid having the “Next” button still visible beyond the end of the content. My workaround, as can be seen on Arpia.be, is to add “easter eggs” for those who click beyond that limit.

Perhaps you can come up with another solution…

Arpia.be design refresh

Peter Craddock — Mon, 18 Jan 2010 11:30:35 +0000

As 2010 kicks off, it is time for me to unveil a new website design on which I have been working for a few months. It was a long process, involving several radically different ideas and long hours getting it all to work (especially on Internet Explorer), but here we are, finally.

I recommend trying things out, to find the hidden easter eggs and so on, to get used to the new functionality.
[Tested in Firefox 2-3, Safari 4, Google Chrome 4, Opera 9-10, Internet Explorer 7-8]

But to truly understand the design, I think a more extensive portrayal of the design process is in order.

In August 2009, I was working on a design for an online store of digital photos, based on the idea of a memory box. For one iteration of the design in question, I had the idea of scanning a paper file and using it to convey the idea of a file containing the photos. This idea was set aside for the project in question, because it did not perfectly fit the idea, but the design felt very well done (and I put some effort into it).
I therefore decided to slightly alter the design, and use it for my own website.

This “Arpia File” design boiled down to showing pages on documents linked to a file on a desk. See the design in action on the Arpia File design demo.
While working on this design, I realised that it did not fit the idea of science-fiction, so I attempted to make a specific page for the ARPIA2 plug-in, more “technical” through the use of a “blue prototype paper” pattern (click on “Game” on the Arpia File design demo).
I was somewhat pleased with it, and had the idea then of making a different page for the “Novels” section, closer to the idea of novels, creating an “old paper” effect (click on “Novels” on the Arpia File design demo).

Still, the Arpia File design didn’t feel right, not for my website.
I then had another idea, inspired by my last touches to the Arpia File design: to create a book-like experience, through the use of a “multiple column” layout.
This was the “Arpia Book” design, on which I poured yet more time and resources, making it look like an old book, with classical typography.
Getting this effect to work on CSS3-capable browsers, such as Firefox, Safari and Chrome, was easy. Getting it to work on Opera and, worst of all, Internet Explorer, was a true challenge. See the design in action on this webpage.
Once I had worked on it for some time, my enthusiasm was yet again damped by the realisation that it did not fit the website. I adored the layout, but most people visiting Arpia.be itself do so for the ARPIA2 plug-in and the iTunesque Mac themes. Why present them with an old book?

The latest version of this website is an attempt to reconcile the feel of a book with the science-fiction (and therefore more modern) setting of the Arpia universe.
It tries to look like a tablet, and with the constant rumours about an Apple tablet about to change the computing landscape, I hope the “Arpia Tablet” design brings an appropriate look to Arpia.be for 2010.

Of course, I’m sure it will undergo refinements as the year progresses.
And if you want to have a hand in that, just let me know what doesn’t work, what should be changed, what you like, what you don’t. After all, without feedback, a design is not worth anything!

PS: about being able to click beyond the last page, that is unfortunately a limitation of the design. Why not take a look at what it leads to?

Design change

Peter Craddock — Wed, 05 Nov 2008 21:40:40 +0000

It’s kind of obvious, but arpia.be just underwent a change in design. The main goal is to make it cleaner and more… “professional”.

To whomever reads this, all positive & negative criticism is welcome (as long as it is constructive).

Lessons of web design

Peter Craddock — Fri, 16 May 2008 10:34:52 +0000

I could have easily titled this "What I learnt while making this website" (yes, "learnt" – British English, my friends), but it felt a little long.

The website has only been truly complete for a few hours now, because I now believe no more changes are needed (though the past week has been just about tweaking). This means I haven’t yet received any real feedback (except from a couple of friends), and so I cannot say I’ve learnt anything from the potential users.
But as a web designer (an amateur, really), there are so many things I’ve learnt over the past month that I feel it necessary to write down the most important of them.

First of all, the default font.

As I started this website thinking about the design, I soon realised I had no idea what the best fonts should be.
See, when I designed the original Arpia website, I just tried to find information on what fonts would exist on all computers. This means the default fonts were as follows: Verdana, Arial, Helvetica and finally the generic sans-serif (for non-webdesigners, the browser will first check if the first one exists, and if not, move on to the second).

But those aren’t the best. Really. Some people made a movie about Helvetica, because it’s ever-present, but when asked why Helvetica was still so popular 50 years after its creation, type designer Erik Spiekermann asked "Why is bad taste ubiquitous?" (source). I think it’s ugly, but that’s just me.

So in the end, based on lots of research (and notably this webpage), I decided to go as follows: Lucida Grande, Lucida Sans Unicode, Lucida, Verdana, Arial, and the generic sans-serif. Perhaps it’s because I’m on a Mac, but I truly feel Lucida Grande to be the greatest font designed for the screen. I’ve tried to replace my OS X system fonts, but never found one that felt better than Lucida.

Next, the general layout.

Header

I designed the header and background early on, and though I believe I could still make the "R" in the "PETER" logo slightly nicer, I haven’t changed those elements in a while.

What really changed is the whole "buttons" section.

A friend, upon seeing the website, asked why on earth I was using Javascript for the very basic "Hover" effect. If you want to see what kind of effect it was, go to the old Arpia website and hover above the sidebar buttons. It’s an immediate change of status (from "normal" to "hover"), and it’s not really enjoyable. I started looking for "Pure CSS Hover" tutorials, and found none that explained it well enough. Plus, they still looked clunky.

And then I stumbled upon a website whose hover effect I really liked: PixelResort.com, the webpage of an icon designer (with some nice articles & tutorials). I realised that this "fade-in/fade-out" effect was much more powerful and enjoyable than my old "mouseover" technique.

Main body

Until I decided to add a WordPress blog (after a comment by a friend who basically said "Nice website. More content?"), I had a darker colour scheme for the text backgrounds, and it never felt perfect. The text was near-white, and the text background was dark blue (so dark it looked black).
At first, I had a really ugly gradient effect between the text background and the main background, and when a friend suggested I make it more "Web 2.0", I took a look Jonas Rask’s website (another icon designer), because I knew it to be one of the sleekest websites I knew.
The design got much better, but it still wasn’t perfect.

Then came WordPress and a shift of perspective.
The default theme for WordPress is the epitome of "cleanliness" in webpages, and it went so well (in my opinion) with the header and background that I decided to adopt it for the rest of the website.

Finally, browser support.

Back in the old days of designing the Arpia website, Safari for Windows didn’t exist, Safari 3 for Mac wasn’t even an idea, and the same went for Firefox 3. IE6 was still very much the norm in the Windows world, and so I had to take it into account. All the same, there was one thing I still couldn’t make cross-browser compatible (the Arpia logo, if you look at it in IE6, still isn’t well positioned – I can’t remember if it does place it well in IE7 or not).

Today, however, IE6 is nearly seven years old. And after reading a number of articles on the web, I decided that I was not going to support it. Turned out that PixelResort.com didn’t either, so I took a look at the code used.
And here is the result.
However, this webpage does not say why I decided not to support IE6 and older versions.

Reasons for dropping IE6

Over the past seven years, web developers have found and implemented a number of "hacks" to force Internet Explorer to render websites "as they should appear". IE6 has a number of shortcomings in terms of standards support, even image format support, not to mention the security problems for Windows users.
Paradoxically, this continued use of hacks has made users unaware that there are alternatives to IE, and that IE itself is outdated, which means few users moved to better browsers.

However, Microsoft seems to have finally understood that IE6 is a plague, and therefore introduced an automatic upgrade system in early 2008 to get most users on Windows XP to upgrade to IE7.
I therefore believe that it is time for all web developers to start giving some serious thought to dropping IE6 support (among those who visited arpia.be in the past two years, the percentage of IE6 users has dropped significantly – but perhaps this is due to an increase in traffic from students, who usually haven’t even heard of IE6 in years).

There, I believe this is a summary of the most important things I’ve learnt from this experience.
And I’m satisfied with the result.

The quest for the perfect non-web font

Peter Craddock — Mon, 12 May 2008 20:54:47 +0000

At university, I write down most of what the teacher says during a lecture, and given that I do so on my MacBook and was feeling generous at the time, I decided to make these lecture notes available to all 400 other students in my class, by putting them online and putting a link to them on the class webboard. Turns out my notes were downloaded over 3300 times during a three-month time-span, because over here in Belgium, lecture notes are the way to go if you want to pass an exam. Especially if the teacher doesn’t provide you with a syllabus.

So I decided I would do the same this term, though this time, we had far fewer courses in common. And at the end of the term (a week ago), I was thinking about how I would make the notes available: Word .doc and Adobe PDF, as usual, or just PDF? I work in Pages ’08, so converting to .doc is always a bother. At the same time, I noticed that the course titles were in Times New Roman. And I thought: “Eugh.”

So began my quest for “the perfect font”.

I’ve amassed a substantial collection of “quality” free fonts over time, and Leopard, along with a number of other applications (probably many I’m not even aware played a role), has provided me with a great deal of “quality” commercial fonts too. But flipping through my font collection, I stumbled upon a font that rendered my titles really nicely: Avenir. I can’t believe I never used that before, because it is very, very pretty.

Anyway, following this “discovery”, I decided to compile a list of my favourite fonts, in the hopes of finding the best among them. And here are the results:

for titles: Avenir* and Gentium Basic**
for smaller titles: Baskerville* and Fontin**, along with the two “title” fonts
for text: Anivers**, Avenir*, Bitstream Vera Serif**, Bookman Old Style*, Century Gothic*, Fertigo**, Fontin**, Gentium Book Basic**, Gentium Basic**, Legendum**, Linux Libertine** and MgOpen Cosmetica**

Legend: * = commercial; ** = free

Indeed, you won’t find any “classic” ones among this list. Times New Roman, I feel, is outdated (and I get the impression I’ll change my default font soon enough). Lucida Grande is great as a system font on OS X, and it’s the “perfect web font” right now, given that it’s the most elegant widely-used font, but it’s not the best for printing. And well, I won’t even mention the others (except Calibri, Microsoft’s new font, which almost made this list, and is the first positive thing I’ve seen from Microsoft in a while).

So there, you have my personal choices. If I can find the money, I’ll seriously think about purchasing part of the new “Avenir Next” typeface, because Avenir seems to have made it into every single category mentioned (and it’s my personal favourite, despite the very limited version I have of it).

But yes, there are high quality, very readable fonts out there. And many of them are free.