Given that we want it or not, Web design world takes a lot from the print world, and so does the Web in general. Think of the simple fact that we talk about Web pages, not using some other word to describe what you’re looking at, this very moment.

I find this thing to be fairly logical, but also quite a bit disorienting, and the metaphore is, eventually, kind of misleading: if you read a book and its pages (proper paper pages!) you instantly and clearly have physical indications about how big it is (tactile, with weight, or visual, how many pages the book has), a rough indication of how much content is stored in it (eg. the type size), and a number of other things that may include graphic aspects regarding the edition of the book.

This isn’t true for Web pages. With search engines often pointing straight to Website’s sub-pages, even the symbolic link between a book’s index and a Website’s home page is lost, and with it another orientation tool inside of a site. Visiting one only page, we have no way to know how big a Website is, nor how much content. Again, the metaphore isn’t working.

On the design side, in print looking for pixel precision is a legitimate thing, while on the Web, due to its ever variable nature, it is not, because we browse it through very different setups (browsers, resolutions, operative systems, mobile phones, and so on).

I tend to think that the two key actions that take place in a browser are the resizing of the viewport and the manual changes to the text size, and when designing taking them into account is mandatory.

No layout should break upon a resize of either the browser window or the text. And with this fact, comes another consideration that occurred into my mind the other night.

I was designing a column based layout with the text leading set at 20 pixels, and I really wanted the spacing between columns to be 20 pixels as well: it’s easy to do it with percentages widths, and even more using ems, but I realized that using a fluid approach, this wasn’t possible if not for the default layout width.

The moment the browser window was resized, the 20 pixels could become 18, or 16, and there went all my good plans for a consistent grid.

What matters

Then I realized that my plans were actually not that relevant.

It’s actually much more important to ensure that the layout doesn’t break, that the contents are still fully accessible by everyone, than focus on little not-so-important things like being pixel perfect concerning the spacing between columns.

Maybe one should create a default version (eg. a default layout width) that has that kind of precision, but in the end we can do nothing but accept that we cannot possess the full control over how people will browse our website.

Hence we must work with what we have (using CSS at their full power in this sense is very helpful), sharpening our wits to preserve the only thing that counts in Web design: flexibility.

Now, since the Internet is such a vast place to search something in, and since we usually give our browsing of the Internet a limited amount of time, if you find yourself in the condition of searching something, speed is many times a preferrable quality to have than the accuracy of the research. That’s the logic behind Google’s “I feel lucky” button.

When it comes to searching stuff, Google does a good job: it not only offers a whole lot of sources of content, but also provides the means for that content to be consumed by the user who queries the World.

This product that burst with simplicity and polish, is actually a very complex process that involves a huge number of resources, computing power, and a fairly decent amount of statistics math.

Google’s approach is what makes the difference: Google displays a limited set of results (pagination, that is), it sorts them by popularity, and generally helps people to find what they want in the shortest amount of time possibile, also thanks to its essential interface.

There are cases, though, clearly not Google-related, when the ability to have a very high amount of options all shown at the same time is regarded as preferrable.

Of course, ideally speaking, more choices mean a higher probability of finding what one wants. Also, having more choices is a situation that is perceived as a sign of intellectual liberty.

Given this, one could be lead to think that more choices are always preferrable.

Wrong.

Most of the times, when facing a situation where multiple options are available, the more alternatives we have, the less sure we are about what choice to make. For this very reason, given we actually pick one of those options, it’s very likely that we’ll feel an underlying sense of doubt and dissatisfaction.

It’s called the *paradox of choice* and it’s proved by a lot of studies concerning human behaviour. For more on the subject, Barry Schwartz’s works are mandatory.

But how a thing like that can affect our webby world? In other words, how can a Web page lead to that sense of indecision we’ve talked about a while ago?

It’s all about how you organize information, correctly evaluating the grade that measures how cluttered your page is, and most of all, what are the *specific* needs for the *specific* task you’re trying to offer an interface for.

Limit the entropy

There’s one thing that I like to call *cognitive entropy*, that is a way to measure the amount of cognitive efforts one must make in order to complete a certain task.

In physics, entropy represents the grade of disorder of a specific system, and can only increase as time progresses.

Just like the real entropy, cognitive entropy increases as the amount of information we have to deal with increases: in fact, many times the confusion of an interface is directly proportional to the number of options available.

Lots of choices, despite being regarded as the epitome of freedom, usually do nothing but get the cognitive entropy higher and higher: the end user undergoes several different mental phases to define a particular filtering condition he intends to apply.

The best thing we can do is try to *limit this process*.

So, when facing a situation when a lot of different choices are present, you can basically move in two directions.

One of them could be making choices so that they are not mutually exclusive: the act of researching will be more polished, to the detriment of the overall entropy of the process, not to mention the time factor.

Luckily we’ve got an alternative.

Divide et impera

British psychologist William Edmund Hick conjectured that it’s easier to choose twice from two equally sized lists of elements, than picking just once from a double sized list (Hick’s law).

So, a preferrable situation would be to limit the filters to a carefully *selected set of macro categories*.

Making use of what some guys would call *empathy*, you can look at the problem from a different perspective — in this case the user’s, and act accordingly, focusing on the filters that actually make sense in that specific context.

The joy of comparison

A good example of this last example is Threadless.

Threadless’ catalogue is huge, but instead of going with several filters at once, they offer just three very common conditions that can be freely combined: size, gender and price.

This three categories of search are the result of a very careful consideration. What could a visitor look for on a site that sells shirts? Let me try:

I want to buy my girlfriend (gender indication) a Small shirt (size) for around $10 (price). Let’s see…

Of course, one could always be willing to look for a specific color, for example, but that’s not as probable as the combination mentioned above. So that filter is perfectly tailored on the majority of the visitors’ needs.

You get a lot of results, but somehow you feel like you’ve restricted your options well enough, hence a general sense of satisfaction which lays the ground for the goal of the site, that is to sell its goods.

The secret for browsing happiness

Browsing the Web should be such a relaxing activity that should be perfectly natural and free from most of the cognitive load we face in our everyday lives.

As cognitive entropy increases, you need to do whatever you can to keep it low, organizing information accordingly, making large portions of content to be easily digestible by the users.

An effective way to do so, is to divide the content and the annexed burden of decisions in a reasonable amount of little parts, each one of them small enough to almost not overload the user’s brain: doing so, the end user will be less concerned about useless details, and more focused on what is his specific goal.

This is the primary condition for effectiveness, and, eventually, a *happy* browsing experience.

First off, let me give a public thank to the guys who organized the event: Alberto Mucignat, Andrea Resmini, Dario Betti, Luca Rosati, Emanue­le Quintarelli.

A huge thankyou also to my buddies Simone Economo and Piotr Fedorczyk, who I have been very pleased to meet in first person, and who have been two great companions for this wonderful experience.

I’d also like to thank all of the people who organized the summit, and all of the guys I have talked to, especially Francesco Casale, Elia Contini and Giacomo Neri.

So what have I learned? I’ve learned that Information Architecture is a science that can be quite hard to describe, as several different disciplines are somehow involved and connected together. This implies that serveral people, each one with a different academic background, can be gathered and still talk about the same things. Architects, psychologists, developers, visual designers, interaction designers, user experience experts, etc.

Such a plurality of opinions and points of view form the basis for something that exalts the social aspect of our lives as they are today, more and more connected by that thing we call the Internet.

In describing what the meeting has been all about, I’m going to quickly run through some keywords that I’ve chosen.

#### Context

The Web is a medium that constantly evolves. The fact that we use it on a daily basis has changed many rules in many games. Besides the obvious game of communication, there’s a new simple aspect about the Web that has become not only relevant, but crucial: we now access the Web with different devices, not only computers. Expecting to be able to accomplish the same tasks on different devices in different *contexts* is the primary corollary to this statement.

Different contexts mean different methods and methodologies to do stuff. This substantial difference among various devices and the way each one of them is used *must* be perceived by all of those people that somehow create things on the Web. The overall user experience that connotes a service is now the sum of all the individual experiences related to the specific devices that service is delivered by. I think that’s what defines the *Ecosystems* Leonora Giovanazzi (slides), and later Gianluca Brugnoli, referred to.

If the design and development phase is able to intercept this need, by developing softwares and interfaces tailored on the device that will host them mantaining the brading aspect of the service, then the same service will truly offer a global and, most of all, enjoyable experience of use: an example of that could be what Maria Cristina Lavazza talked about in her speech—about organizing goods in a grocery store, with the hope of a technology not only more user friendly, but also more efficient, really helping the people that make use of it.

And speaking about context, I’d like to cite Luca Mascaro’s presentation, concerning adaptive interfaces. It has been a great talk, both innovative and sharp, and really got me thinking about many things I didn’t take into account before. But, this is a vast topic, way too complex to be exposed here and now, so as soon as I’ll have elaborated something deeper, I think you’ll find a new article here on the subject.

#### Collaboration

Collaboration is strictly connected to that game we’ve talked about earlier, that is communication.

Collaboration can happen in different ways, at different levels, in different circumstances and for diffe­rent purposes.

Collaborative tagging, for example, is something we deal with and contribute to it almost every day, and I’m pretty sure many of you will have noticed some intrinsic problems with it. The case study made by Renata Durighello about collaborative tagging done by kids has surprisingly pointed out that those issues are transversal through different ages. Having common issues is a good start to find solutions for at least part of those problems like normalizing keywords, correcting typing errors with a smart interpretation of the tags based on thesauri and frequence of occurrence.

Of course, it isn’t *that* easy. In fact, smart interpetation will never be as smart as we want it to be, and human control will always be the best way of ensuring quality tagging. Still, those workarounds, combined with education towards the act of tagging, especially working in order to find shared conventions, are the best chance of reducing the tagging noise.

Always speaking of collaboration, the talk delivered by Søren Muus introducing an european community of information architects, together with the idea of sharing opinions and experience, not being limited or stopped by differences and cultural boundaries was *truly inspiring*. I got to talk to Muus for a couple of minutes the day after, and he was very nice towards me, and I think this explains better than anything else a serendipituous attitude towards others we should have.

#### Participation

One word that rhymes well with collaboration is participation. I was particularly impressed by the concept of participative design applied to the building of an airport, well exposed by Davide Potente and Stefano Bussolon. Very clever.

In the closing keynote of the Summit, Jim Kalbach introduced the concept of Commercial Ethnography, pointing out that a new approach towards commerce should be user research, not product research. It’s all about User Centered Design: the customers are seen as a resource. If you get into their shoes to study their problems, their needs, the conditions they live in and how these (and more) factors affect the way they behave, you can get precious new perspectives.

#### Evangelization

I want to sum everything up with one word: evangelization. It’s a vague term, I know. But one thing emerged from this meeting: we are not alone and, as Bussolon said, we need to keep communicating with each other. Also, I’d add, we need to spread the word evangelizing the people around us not only to a higher degree of technology awareness, but also introducing what we’ve talked about this weekend in our daily working lives.

It’s gonna be hard, OK, but it’s damn worth the effort.

P.S. If you’re interested, videos of the presentations are available, and so are my photos from the event.

I started looking at things in a different way, trying to analize what were the strenghts of objects, and where those objects could be improved. One could do that with anything, really: from websites to lamps, from cars to elevators, every object, device or tool that we use every day has passed through a phase when some people got together, thought about its possible uses, and then produced it.

What I like about design is that it’s a never-ending process. You learn from your previous experiences, you learn from other people’s experience, and you strive to create something better.

Design is hard as hell. Creativity can lead to great ideas, but also to miserable failures. I’ve found that failures are often associated with simple things, like you wouldn’t expect that object to fail at such an easy task.

Take my elevator, at work. We have this elevator, that isn’t particularly slow, or small; instead it’s well illuminated, it has a marble floor, and a big mirror. So it’s visually attractive, but it fails at two simple things. The first one it’s the control panel that is placed on every floor of our building: it doesn’t display what level the elevator is currently at, and neither gives you an indication whether it is going up or down. The control panel is only good to summon the lift.

We’re talking about lack of feedback, here. Every user makes an action, and wants a clear signal that the action has produced some kind of effects, otherwise he/she gets confused. A red light that indicates that the elevator will eventually come at your floor simply isn’t enough for me.

The second mistake about my elevator is about the sensors that prevent its sliding door to close, when someone is entering. That’s a needed feature, of course, but what I’m questioning is the implementation — geeky term, I know — of that feature.

Since we stick to the floor when moving, and since we tend to move more the upper part of our bodies than the lower part (legs are supposed to be steady in an elevator), why do we need sensors for all the door’s height and not only the bottom of it? It happens many times that the elevator is crowded, that people is carrying bags and accidentally move their wrists, activating the sensors. The door opens and people mumble.

Those are simple things, right? You could have had both feedback and effectiveness of use at a very low price. Too bad.

The Web side of the Moon

A couple of days ago I happened to think about how could I apply a similar reasoning to my web-related design and development work and so I started thinking about wrong solutions that I’ve found through my experience on the Web.

Deduction number one: the speed thing is confirmed. I work with several kinds of interfaces, and even when I know what’s going on with the app I’m using (gotta love text consoles), I get frustrated too when the system doesn’t give me visual indications about its activity. That’s one of the usability problems that AJAX brings with itself.

Speed and feedback, the two keywords to a successfull interface. But there’s more. JavaScript in general gives you the ability to interact with the DOM, and to associate many kinds of events to the elements that compose your page. Now, with events you can create almost everything, even duplicate the functionality of desktop applications controls. Here lies a subtle threat: not every control is suited for a Web context, and not every control is good in general.

If you use sliding on your touch device, that doesn’t mean that you should find the same kind of control on a Web page too. Sliding with a mouse is a complex motion, that involves a lot of muscles, unlike what happens with touch devices. Still, I’ve encountered this kind of control in wrong situations: who wants to execute a dragging motion to, say, download a file or confirm a choice?

According to my own personal taste, using dragging for those two specific tasks is deeply wrong. Since we’re lucky enough to have alternatives for the problem, as far as downloading/confirming goes, just provide a hypertext link to the download page or the file itself, or simply use a checkbox, respectively.

Banal, right? Well, it may be. But the fact is that links and checkboxes perfectly satisfy the conditions of simplicity, speed and received feedback we’ve talked about earlier. In the end, on the Web, while we must not desist in researching new and better ways to do things, there’s one dogma that shouldn’t be violated: keep it simple, keep it fast and give the user some clues on what’s going on.

The question is: can we drop support, or at least strongly reconsider the way we look at that “old cousin that nobody likes but you can’t avoid inviting for the Christmas dinner”?. IE6, that is, and that quote should be from Zeldman, I think.

As you might guess there are a lot of different opinions on the matter, and none of them can be considered as the ultimate truth. My opinion is, as the title to this article suggests, that we can’t cut off like 20-25-30% of visitors that each day come visiting our website. Many many times, the fact that they’re using this dinosaur of our days’ technology isn’t their choice at all.

Some (not sure what percentage, though) of them are forced to do so, or aren’t geek enough to know alternatives. So, they’re good guys, after all, many times they’re not guilty of anything, and so they deserve to get our juicy contents just like other people do. For those who stick to crappy browsers, ignoring the fact that they’re basically stealing precious hours of web developers’ even more precious lives, because they’re too lazy, I can’t help. Also, browsers are free: why the hell one shouln’t be willing to switch to a better thing that won’t cost a penny?

So, should we surrender to a jurassic way of styling? Again the title of the article helps us: nope!

I’ve always thought that designing for the Web is all about making compromises. There’s some stuff out there that would be ready for prime time, if not for IE6 (and 7, don’t forget v7!), sure; but we are supposed to be smart and skilled enough to overcome this obstacles.

For instance, IE is both providing the problem and the means to the solution: conditional comments. They’re ugly, they’re proprietary, but in a situation like this I feel like they’re our best weapon. With that technique we can target specific browser versions, and ensure that the content is OK every time.

So, my advice is to always design and build stuff using a modern browser as reference. If you’re extreme enough, you can even use WebKit, which usually implements advanced stuff first. Then, when you’re done with your hyper-cool layout with all the fancy stuff in it, you can turn the IE spotlight on, and make the needed corrections.

What does that mean? It means that you’re wasting time, in the short period, because you have to write two, or three different stylesheets. But writing one good main stylesheet is priceless, because in the long term, when newer, and supposedly better, browsers will come along, your work will be already done and you won’t need any more fine tuning.

So, it’s a matter of time and since you’re wasting it, when designing your master stylesheet, you should take as many shortcuts as you can, whether they are advanced CSS selectors, or rounded corners, or even revolutionary ways to lay things out.

Then you go on and fix stuff for IE, bearing in mind that things must not necessarily appear exactly the same, that little imperfections may be acceptable, as long as the content and its message are preserved. It’s not the visual look of the website that should be pixel perfect, it’s the branding aspect of it, the overall feeling, the stuff that connotates a service or a product you’re selling, that needs, this is mandatory, to be delivered as it is, no matter what the device.

At this point, one might note that this very site doesn’t feature an IE specific stylesheet. Yet. So, for now I’m not practicing what I’m preaching, and while I’m not sure when I will actually find the time to do that for this site too, I’ve been pondering about the problem for quite a while.

I came to the conclusion that not to exclude IE6 users, we could do like we do for mobile phones: it might not be great, but why not a single-column layout? Dead simple, and worries-free. OK, that might be too simple, but you get the point, right: simplify things! The content would be there, the overall theme of the site would be mostly preserved, and the site would end up to be just a simplified version of the real one. That’s just an idea, anyway, a banal one perhaps, but I’m probably go that way to kinda offer a basic support for legacy browsers.

So, what?

While we’re no superheroes, we have a mission. In early 2000’s it was spreading Web Standards. Right now, what we gotta do is harder and more subtle. By targeting specific browsers, intentionally producing worse-looking versions of our sites, and by displaying messages only to users of those browsers, we need to get them, especially the lazy ones, aware of the fact that browsers doesn’t differ much from the rest of the technology we use.

So if generally we’re conscious of it and we accept the fact that, say, a cell phone (or a television, a radio, a computer, you name it) bought five years ago has less features than one that will come out tomorrow that is generally better, we must make it so that people apply the same thinking to browsers too.

This is true, to a certain extent, in the sense that it’s a matter of cause and effect: technology is spreading all over, more and more people get to use the computer in a more conscious way, word processors are easy to use and they offer the option to save a file with an .html extension. That’s it. This small list leads to the fact that anyone can publish something on the Web. Then they say, ‘Hey, I know a little Photoshop too!’, and there you go with the general opinion that doing websites is a fairly easy task, that doesn’t require a deep knowledge.

Now, publishing stuff is easy as pie, but doing websites, and making them well, is a whole different story.

Anyway, this belief to me is the key to understand why, in my opinion, our work is underestimated.

For example, I don’t think I’ll ever find someone who, say, believes that doing the work that architects do is an easy task. That’s because doing stuff in the architecture field requires a proper education, knowledge of materials, physics, aesthetics, and so on. So they get the respect they deserve, as they have notions that you don’t and that are essential to their work.

This goes for Web-related professions too, like usability experts, or information architects and so on. And it’s for the very same reason. They have what we don’t: a proper, formal education on those particular fields.

With us people who make websites, things are different. First of all it’s because there aren’t real certifications about our work, nor proper college classes that teach what we do. I think that the vast majority of us self-teaches stuff, by reading books and articles on the Web.

Then, it’s because, just like Zeldman said at some conference, there are a dozen different terms we use to identify our work. That’s not gonna work.

Two little considerations:

1. I don’t think that certifications are needed, for us. The main aspect of the Web is its ability to allow people to communicate, interact, share informations. Being social, that is. So to me it’s not about degrees, or titles. It’s about getting a good reputation. It’s about people knowing you do some work, and you do it well. There couldn’t be a better certification than that, and there couldn’t be a better reward for your working efforts.
2. Concerning classes. Colleges and universities should have them, and they should teach them right. Formal education should give students a direction towards concepts like Web standards, and so on. But the thing about our work, is the fact that we constantly have to sort of update our knowledge. Day by day. Reading books and stuff. So self-teaching is still the best way to get to know things.

OK, so what? I think I can close this one quoting a comment I’ve made on the subject, over at Meagan Fisher’s blog.

This [whole situation, the fact that our profession hasn’t much respect from people] is why, and I back this up with my personal experience, sometimes clients simply refuse to pay the right amount of money required for the job.

It’s not that we’re greedy or something; we’re asking that amount of money because you’re not only buying a site, you’re buying my knowledge as well, the hours I’ve spent reading books and talking with colleagues about the stuff we do.

A website, to me, is still perceived as something optional, something we can live without even if we’re running some sort of business. So while one would pay more to, say, get a better car, that doesn’t necessarily imply that the same guy would do it as well for a piece of furniture or a watch. They’re not so important, compared to a thing that could affect your safety while driving. Perhaps, this is the case for websites too.

In this kaleidoscope of options and possibilities, I sort of get lost when it comes to judge what it’s good and what it’s not. What does it mean the adjective good applied to websites, anyway? Does it mean good-looking? Or good at ease of use? Nah, we need a higher degree of specificity.

We need an example too. The print world comes to mind. You’ve got a piece of paper, say, you paint, write, print your artwork, and the result it’s there, right before your eyes. It is not influenced by external factors. For the Web this is not true.

Every content is accessed via a third party application: the browser. So it’s not a direct connection between the author and the reader. Software gets in the way. And this is good, as software provides the means to avoid the kind of unevennesses we’ve talked about right at the beginning.

Pick a short-sighted person, for example. He/she might not be able to, say, read or distinguish a little detail you’ve so lovely put in your printed handcrafted artwork. No problem: he/she puts glasses on, or makes use of a magnifying glass. The gap between his/her problem and you, the author willing to convey a message, is filled.

A similar, yet more subtle, situation happens with Web pages. Now, the same short-sighted person fires up his/her computer and loads a website that he/she cannot read, as it’s written too small. The deus ex machina role is played by the browser that (should) provides a robust shortcut to bump up the text size for the whole page.

It happens sometimes that this simple and absolutely ordinary and necessary action, kind of messes up the page layout. When it does, that’s not a good page by any means.

So what is a good page, for me? To me, good is something that ensures that its content is kept accessible, yet is able to present it in a nice and appropriate to the context way.

Technically speaking, I love em-based websites because they nicely adapt themselves to different browsing situations. Em-based layouts are spreading more and more, these days, even at corporate level, which is extremely cool, but still too many times I see websites that are just gorgeus when viewed at default text size, but that fail miserably otherwise.

I came to realize that the goodness of a website had very little to do with its graphic look. Or, at least, a lot less than what one could think.

So what? During these years of constant development, I sort of came up with a quick testing routine that gives me a rough clue of how scalable and flexible is the layout I’m designing.

1. Constantly check your code. XHTML validation is essential, and we should not debate over that topic. A slightly different story applies to CSS validation and the use of non standard properties (such as browser specific implementation of rounded corners). With CSS we can experiment a little bit more. For example adding text-shadow where needed could be possible scenario: browsers that already support it will display it. Others won’t, but that’s fine and acceptable, because it won’t cause much harm to the end-user, right?
2. Again concerning CSS, try not to use hacks. For as ugly and proprietary as they might look, use conditional comments to load up additional browser-specific stylesheets.
3. Turn off styling — This will give you a perfectly clear indication of how good your markup is, and will also give you a hint of what a text browser will read. My rule is: ensure that your website is perfecly readable and understandable even without the fancy graphic stuff. This is called graceful degradation, I think.
4. Repeat the above procedure, this time turning off images. Page size is day after day less a concern, with fast connection speed spreading all over, but there definitely are situations where it does matter how much data you’re downloading (think mobile phones). Browsing with no images to reduce loading times it’s a respectable choice by the end-user and should be honoured, hence the end-user should not be penalized by a imageless layout that’s completely messed up or significantly damaged.
5. Bump up your text a couple of times — There’s a nice shortcut that works in most browsers that is ctrl/cmd++. If your layout stays OK after this, you can sleep quietly tonight. If it doesn’t, you should fix that as soon as possible. Always ensure that your layout is flexible enough to accomodate this not-so-rare situation.

Now, there would be a whole lot more to say on this topic, but for now I think I will leave it like this: if a website is able to pass that little checklist above, then it could well being judged as good. It also has a killer look? Then it’s a winner, to me.

What about you? Which criteria come in play when you judge how good a website is?

This time it was different. I still liked the idea behind my design, and its implementation, for the most part. I just felt like there was something I didn’t get right. I perceived it as sort of messy and somewhat distracting, which is for me the epitome of what a design shouldn’t be. So I decided to rethink about it.

Special thanks go to my friend Simone, who helped me in identifying a series of little things that I had missed, and even some usability inconsistencies.

Most of the times it’s the little details that make the difference, and being much more painstaking this time, while striving to maintain the ensemble feeling — the old book type-of thing — surely helped me a lot in developing a more solid design.

The biggest change from the very first release, was the column system. Boom. It seems like an obvious thing, but it changed my judgement completely.

I’m surely not reinventing the wheel, but, really, sticking to a well defined grid gives your product a whole different kind of feeling (even if you can break out of it, but that’s another story).

For some reason I’m not inclined to use any kind of CSS framework (even if some of them are cool, and handy for sure); I always build stuff myself, with only Eric Meyer’s reset stylesheet as a base. Of course, this implies much more thinking and calculations.

Now, since difficulties might lead to laziness, perhaps this was the reason why the first version of this website wasn’t that accurate, in terms of spacing (both horizontal and vertical).

Sticking to a four column layout, each one of them equally spaced, helped me in achieving a kind of balance that simply wouldn’t have been possible, otherwise. I also adopted a 16px base unit for vertical spacing: I’ve tried to stick to that rhythm as much as possible, that means (almost) always ensuring that the sum of leading and text size would be 16px or a multiple of it.

This is my version of “Typography for Dummies” perhaps, but it really is something that I completely ignored just a few months ago and that it is absolutely essential (talk about developing knowledge, I will write something about my Web-related lectures soon).

For those of you wondering, this place still hasn’t IE support. I’m not sure IE6 will ever have one, but I’m definitely planning a testing session with IE7.

Speaking of browsers, this website is OK on Google Chrome too (thanks Webkit). Of course by saying OK I’m referring to the layout, and I’m not considering the uglyquestionable Windows font rendering.

Among other goodies, I’ve created an Elsewhere page, where all the stuff coming from the different pieces of me scattered on the web is collected. Feel free to add me, if you want: I won’t bite.

Why am I saying this? The labels found on every showcase at the National Museum in Prague were written in czech only. That was disappointing. Instead, at the Museum of the History of Medicine, in Vienna, the labels were both in german and english, with different fonts and colours used too. Pleasing, so thumbs up all the way.

I so much liked the typographic stuff in both cities. Prague, with its gothic flavour, has some amazing signs and emblems, really. Vienna too was great from that point of view; in particular the city’s subway signs are all perfectly readable being written in beautiful bold Helvetica.

I loved some of the stuff I’ve found at the MUMOK, Vienna’s museum for modern art, and some great manuscripts and letters at the aforementioned museum of medicine history, which unfortunately I wasn’t able to photograph.

A last thought that is actually an advice. We visited the Schönbrunn castle, right? Beautiful park, really, with amazing colours and ornaments. Inside the imperial apartments, instead, I felt like they were way too glitzy, and somewhat overdone. This is something I did not felt, for example, when I was in Versailles, a couple of years ago — and that’s quite remarkable since Schönbrunn was actually built to sort of compete with it.

While I’m not sure about the causes of this entirely subjective feeling (tiredness, weak light inside the rooms, the summer heat), and while I should reckon that my taste is different from other people’s taste, especially if those people lived centuries ago, one thing is for sure: overdoing things is never good.

Now, setting the list to start counting from a value different than 1 (or, if you prefer, a., A., I., whatever) it is not possible anymore, if you care about XHTML validation. Before XHTML 1.0, there where two options to do that, one being the start attribute of the OL element, and the other, less obvious yet more powerful, a value attribute for the LI element.

Between the two options, I would rather go with the first. It’s the list that starts counting from one particular value, so the semantic information should belong to the list, not its items.

I understand the choice of removing those attributes. From an XML point of view a list that does not start from value 1 it is not the same list as the list that precedes it and that actually starts from value 1, as you need to have them in separate OL elements.

But this choice leaves my quite confused all the same. This, the fact of having an ordered list to start from a value different than 1, is a common typographic and logical need, so what I’m asking with this post is Was it really necessary to get rid of both attributes, since this behaviour isn’t replicable with any other technology we have at disposal, and since any alternative would lack semantic meaning?.

From an author perspective, my answer is no. My two cents: it would make more sense to retain the start attribute, so that this ability is somehow preserved, and add another attribute, such as role in XHTML 2 to semantically link lists that would otherwise be separated entities.

<ol role="toc">
	<li>item</li>
	<li>item</li>
	<li>item</li>
</ol>
<p>...</p>
<ol role="toc" start="4">
	<li>item</li>
	<li>item</li>
	<li>item</li>
</ol>

Does that make at least little sense to you too?