456 Berea Street

Eric Martinsson from the Swedish Apple blog AppleMac.se recently sent me an email with a few questions, including the following (translated from Swedish and edited):

1. For how long have you been a Mac user, and what Macs have you had through the years?
2. Which Apple and Mac products do you currently use?
3. In your opinion, what makes the Mac such a good computer?
4. Are you a gadget freak who always has to have the latest gizmos?
5. What do you think of the iPhone and Mac OS X Leopard?
6. What do you think will be the next Mac to be released or updated?
7. Name five free Mac OS X applications that you have to have.

If you know Swedish, you can find my answers to those questions and a few others in Intervju med webbexperten Roger Johansson från Netrelations och 456 Berea Street. If you, like most of my readers, don't know Swedish, well, you can always try one of them online translation tools for some hilarious fun ;-).

Add 456 Berea Street to your Technorati favorites.

Posted in Interviews.

In September 2005, Tommy Olsson posted Good-Bye, an article in which he explaind his reasons for giving up blogging.

Fortunately Tommy did not disappear off the face of the Earth just because he stopped blogging. Since then he has written a bunch of excellent articles (including one together with me, published here on 456 Berea Street: Barrier-Free Web design, a.k.a. Web accessibility 2.0) that have been published on various other sites.

Signs of Life, the first post on The Autistic Cuckoo in over a year and a half, lists some of Tommy's articles. All of them are must-read stuff, so make sure you check this list out.

Here's hoping that Tommy fully resurrects The Autistic Cuckoo in the near future.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility, Web Standards.

The layout model of tables differ from that of block level elements in that they will normally expand beyond their specified width to make their contents fit. At first that may sound like a good thing – and it often is – but it makes it possible for oversized content to make text unreadable or completely break a site's layout, especially in Internet Explorer.

This happened to me recently when a client's legacy content, which contains some layout tables, was injected into the CSS-based layout I had built. It worked well in most cases, but some of the old documents have very long URLs that the browser can't break. I needed to find a solution to that problem.

View Example 1 to see what I mean. Not very pretty.

Your first instinct is probably to do what I did: start hacking away at the CSS. How about giving overflow:hidden a try? Nope, nothing happens. What if I give the table a different width? No, it doesn't budge. But there is a solution.

The trick is to use the CSS property table-layout. It can take three values: auto, fixed, and inherit. The normal (initial) value is auto, which means that the table width is given by its columns and any borders. In other words, it expands if necessary.

What you want to use is table-layout:fixed. Bam! Now the table is as wide as you have specified in the CSS. No more, no less. And to my great surprise this seems to be widely supported by browsers. The only browser of any significance that does not support it is IE/Mac, and the significance of that browser is rapidly approaching zero. Check it out for yourself in Example 2.

Next is deciding what to do with the content that doesn't fit in the table anymore. If the table only contains text, word-wrap:break-word (word-wrap is specified in the CSS3 Text Effects Module) will force the browser to break words as necessary to prevent overflow. The result can be seen in Example 3.

Unfortunately that currently only works in IE/Win, Safari, and Shiira (imagine that... IE/Win, even version 6, is ahead of Firefox in supporting a CSS property).

A compromise is needed for the browsers that don't support word-wrap. The choices are to either let the content overflow and collide with the other stuff on the page, or to use overflow:hidden to hide it. Which solution is more appropriate will vary from case to case. I went with overflow:hidden, the effect of which you can see in Example 4.

Sorry if this is old news to some of you, but since I only recently discovered this very useful property I thought it would be worthy of a quick write-up.

Translations

This article has been translated into the following languages:

• Brazilian Portuguese: Tabelas quebrando layout (Translation by Maurício Samy Silva)

Add 456 Berea Street to your Technorati favorites.

Posted in CSS.

Vitaly Friedman from Smashing Magazine asked me and 34 other designers (though I don't really consider myself a designer, and definitely not a graphic designer) five questions.

Everybody's answers to those five questions are revealed in 35 Designers x 5 Questions, a long, long article (because 35 times 5 = 175).

I was kind of overloaded with work when I answered the questions, so in comparison to many of the others my answers may seem short, abrupt, and grumpy. Oh well :-). The article is still a good read that contains a lot of useful tips.

Add 456 Berea Street to your Technorati favorites.

Posted in Interviews.

If you're looking for a Web design book that you can put on your coffee table without feeling like a geek, look no further. In Transcending CSS, Andy Clarke combines technical expertise with graphic design skills to create a book that is as beautiful as it is inspiring.

This book is a bit hardcore with regards to progressive enhancement. The principles of Transcendent CSS include going all the way with CSS 2.1 selectors and the parts of CSS 3 that have been implemented in browsers. Yes, that means using them now instead of waiting for all browsers to catch up. These are the principles of Transcendent CSS:

• Not all browsers see the same design.
• Use all available CSS selectors.
• Use CSS3 where possible to look to the future.
• Use JavaScript and the DOM to plug the holes in CSS.
• Avoid using hacks and filters.
• Use semantic naming conventions and microformats.
• Share your ideas, and collaborate with others.

These are all great principles to follow when designing or developing for the Web, and the entire book is focused on these principles.

I have a couple of quibbles, as always. First, I do not agree with Andy's statement that element id:s like header and footer are presentational. At least they aren't the way I think when I use them. To me, "header" means "the first thing in the document" and "footer" is–you guessed it– "the last thing in the document". My second quibble is that Andy suggests using absolute positioning to create columns, and to use JavaScript to make sure whatever comes next gets cleared properly. That's fine, but I didn't see any mention of how you would make sure that users with JavaScript off would not get a page that is partly unreadable.

Don't let my nitpicking stop you from buying Transcending CSS though. It is very refreshing to see a book that is mainly aimed at graphic designers focus on content and structure first, and visual design later.

Transcending CSS: The Fine Art of Web Design

Author: Andy Clarke

ISBN-10: 0321410971

ISBN-13: 978-0321410979

Add 456 Berea Street to your Technorati favorites.

Posted in CSS, Reviews, Web Standards.

Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible.

There are usually two problem with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options.

I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat.

The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups.

The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility, JavaScript.

When I posted my recent poll on Web browser window size I was expecting at the very most a couple of hundred comments. I obviously underestimated my readers' willingness to participate, because when I finally closed comments the count was 1070, with the total amount of setups reported landing at 1385. 1070 comments. Wow.

Huge thanks to everybody who took the time to post info about your setup. And thanks to Frode Danielsen for helping me out with a script that parses the responses and creates a CSV file, and thanks to everybody who posted tips on how to turn this data into something usable when I asked for help in Statistics help needed.

You may be wondering why I posted this poll. So do I ;-). Seriously though, I was just curious. I realise the results aren't valid for the Web browsing public as a whole, and not even for the people who visit this site (since only those who participated are counted). But it still shows something, and I was a little surprised by a few things:

• Only 50.4% maximise their browser windows. I thought that percentage would be higher.
• 20% of Mac users maximise. I thought that percentage would be lower.
• 65% of Windows users maximise, which is far lower than I thought.
• There are many more Linux users here than I thought – 12%. That doesn't match what my statistics apps tell me though, so it may not be reliable. The same goes for Mac users, who provided 32% of the answers.

Some numbers, then. I have edited the data quite a bit, consolidating operating systems and resolutions to get something that is manageable.

Disclaimer: I am no statistics expert, so my analysis may be wrong. There may also be better ways of presenting the data.

An even split.

Here's a chart that may help visualise that table:

Windows and Linux users maximise to a similar extent, while Mac users are much less likely to maximise. I expected that, but I did think fewer Mac users and more Windows users would maximise.

To make it easier to handle the large amounts of screen resolutions, I have looked at width only, and consolidated almost similar widths.

At higher resolutions, the percentage of maximisers drops. I expected that.

I could show many more tables and charts, but that is all I have time for right now. In case you feel like playing around with the data, you are welcome to download the cleaned and consolidated CSV file.

Add 456 Berea Street to your Technorati favorites.

Posted in Web General.

Well, it seems I bit off more than I can chew with my recent poll on Web browser window size. I now have, thanks to the help of a clever Ruby script Frode Danielsen sent me, a CSV file (results.csv) containing information about 1385 different setups. But I cannot for the life of me figure out how to get anything useful out of it.

I am a complete spreadsheet illiterate, but I gave it a try. Opening the file and getting the data into three different columns is easy. But what then? How can I turn that into a few nice pie-chart diagrams? I have spent (too) many hours on this, looking through the completely useless help in Excel, googling for help, and throwing things across the room in frustration.

I just don't get it, and am about to give up. Are there better applications than Excel or OpenOffice Calc for this kind of thing?

If you know how to turn the data in the CSV file into something useful, feel free to do so. I would also really appreciate some pointers to help with this. Not understanding how to do something that should be really simple is extremely frustrating.

Update: Thanks for helping me out, everybody! I think I have what I need, so I don't want to occupy any more of your time with this :-).

Update (2007-04-15): I have published the results of the poll in Poll results: 50.4% of respondents maximise windows.

Add 456 Berea Street to your Technorati favorites.

Posted in Usability.

I've mentioned several times here that I feel writing markup (or any other code, for that matter) is a craft. I take pride in writing as lean and clean code as possible. From the looks of things there aren't a whole lot of other Web professionals that feel that way, but we do exist.

One of them is Garrett Dimon, who has touched upon this subject before, and in Markup as a Craft (published at Digital Web Magazine) provides twenty-one guidelines that will help you create better markup. That's a lot of guidelines, but they are all relevant and contain very good advice. Highly recommended reading.

After reading Garrett's article I couldn't resist creating a list of what I think are the six most important guidelines for writing better markup:

• Keep it simple. Keep your markup as simple as possible, which is often simpler than you may think at first.
• No layout tables. This is obvious to anyone who has not been living in a cave for the last several years. Unfortunately, the caves seem full of Web developers. Tables are meant for marking up tabular data, not creating layouts. Use CSS instead.
• Avoid classitis. Does every element you want to style with CSS have a class attribute? They almost certainly do not need to. Use descendant selectors instead.
• Structure and meaning first, presentation later. Focus on semantics and document structure while you are writing markup. Save the presentational thinking for when you are writing your CSS.
• Know all HTML elements and attributes. Go through the Index of Elements and the Index of Attributes in the HTML 4.01 Specification. You will probably make some new acquaintances. Read up on them and learn when to use them.
• Validate, validate, validate. The markup validator is your friend, not your enemy. Anybody can make typos or mistakes. The validator will help you catch them and improve your markup.

What would your most important guidelines for writing better markup be?

Add 456 Berea Street to your Technorati favorites.

Posted in (X)HTML.

As Jeremy Keith states in The language of accessibility, accessiblity is something that is an inherent part of Web documents that make proper use of semantic HTML.

Far from being something that is added to a site, accessibility is something we need to ensure isn't removed. From that perspective, the phrase "making a site accessible" isn't accurate.

Very well put. The only sites that need to be "made accessible" are those that are badly constructed to begin with and those that once were accessible but have had too many accessibility-removing additions grafted on.

Jeremy also notes that the German word for accessibility is "Barrierefreiheit", which means "free from obstacles". To me that perfectly describes what accessibility is about – not creating barriers that will make it difficult for people or machines to access your site's content. The Swedish word for accessibility is "tillgänglighet", which just like in English is a bit problematic since saying that a site is accessible can also be interpreted as "Yes, the server is up and running, so the site is accessible." Hardcore server-side people seem to be the most easily confused by this, probably since keeping the server running is one of their most important tasks.

To get back to the issue of making vs. keeping a site accessible, I will follow Jeremy's lead and use keeping from now on. Most of the time, anyway. In many cases sites really do need to be "made accessible".

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility.

Rant time. I need to vent some built-up frustration I get from some of the people and attitudes I encounter in my dayjob, in comments on this site, and when reading articles elsewhere. What frustrates me is that the Web industry is overflowing with lazy, ignorant, incompetent people who do not seem to have the slightest interest in learning how to do things properly.

If you don't like rants, don't read this. On the other hand, if you do like rants and have an interest in creating websites that work for as many people as possible, you might enjoy this. Especially if you're also feeling frustrated by the following excuses that some people have for not always striving to do the best they can.

Visual consistency

Ah, the top graphic designer excuse for making the user's job harder. Coloured scrollbars anyone? Unidentifiable form controls? Non-recognisable links? Unreadable text? The list goes on. This excuse is normally used by visually oriented Flash designers or ad agency art directors that create design profiles which simply do not work on the Web. Instead of adjusting their design when they are made aware of the problems, they stubbornly push ahead and make users think and work harder than they should have to in order to use the site. If your design - or you as a designer - cannot handle the fact that the Web is the Web, please do everybody a favour and stick to the safety of your printed brochures.

Engaging user experience

Whenever you hear someone mention "engaging user experience", run. All too often "creating an engaging user experience" on the Web means filling the site with enough pointless Flash bling-bling and/or library-based JavaScript effects to completely ruin any chances of the user actually getting anything done. People who talk a lot about creating a good user experience are more often than not completely clueless about usability and interaction design. Ironic, isn't it?

Target audience

Having a good grip on the demographics of the people you are trying to reach is obviously a good thing, but every time I hear someone mention "target audience" my spider-sense starts tingling. "Target audience" is a very dangerous weapon when it is put in the hands of the wrong people. It is way too convenient to use it as an excuse for excluding pretty much any group of users. Things you might hear include "Our target audience doesn't use Macs.", "We have no disabled customers.", "Nobody in our target audience will have JavaScript disabled.", and "Everybody in our target audience has a fast computer, broadband, and Flash." These claims are, of course, almost never backed up by facts.

Optimising your design choices to make your site appeal to and work well for your main target group(s) is one thing, but you need to have a very - no, extremely - good knowledge of exactly who will visit your site, with what, and under what circumstances, to let those design choices make the site hard or impossible to use for other groups. This is the Web. The only thing you know about who will come is that you do not know who will come.

Statistics

This excuse is very closely related to the "Target audience" excuse, in that those who use it tend to be looking for ways of making the number of people their bad design or development choices turn away seem insignificantly small. This is accomplished by dividing the total number of people who cannot use a site properly into a number of small groups that each may be seen as acceptable collateral damage. Using the statistics defence is letting your (bad) design and/or technology choices determine who your target audience is.

HTML-challenged IDEs and frameworks

Many back-end developers for some reason I cannot understand seem to be completely dependent on having an IDE or a framework create all front-end code for them. It seems like HTML, CSS, and JavaScript are all way too complicated for most back-end programmers. And that is really unfortunate since the IDEs many of them use create front-end code that is nothing but pathetic.

Look, it's very simple. You're a programmer. You should be smart enough to learn HTML, CSS, and JavaScript. If your IDE or framework produces rubbish for front-end code, don't let it. Twist its arm to make it produce sane markup.

This is the reality we live in at my dayjob. One of the content management systems we use is based on ASP.NET, with all the sloppy front-end code that brings into the game. We simply work around it. If we couldn't, we would use something else. So should you. Don't just accept that your IDE/framework/CMS creates junk by default.

The real world

Some people like to shoot down arguments from people (like me) who want to improve the Web by insinuating that we don't have real jobs, and don't build real sites used by real people. Well, let me assure you that I, and everybody else that I know who pushes the same ideals I do, have real jobs with real clients and real deadlines. The difference is that we (ok, make that I - I don't want to put words in anyone's mouth) regard what we do as a craft and have an inner drive to always deliver top quality stuff.

It gets the job done

"It gets the job done" really means "It works with the default settings in my browser, my manager's browser, and the client's browser. That's good enough for me. I want to go home and watch TV now."

Why are you working in the Web business if you're not interested in it? Go flip burgers instead.

Some excuses may occasionally be valid

Most of these excuses may occasionally be valid, but only in very special circumstances. The disturbing fact is that in the vast majority of cases when I encounter somebody who is using one or more of these excuses, they are just using them to hide their laziness and lack of knowledge.

One more thing: I know that there are highly skilled Web professionals who sometimes use some of the phrases I have mentioned here. Please understand that I'm not picking on you.

What other lame excuses are there?

Add 456 Berea Street to your Technorati favorites.

Posted in Web Standards.

Do you find reading the HTML and CSS specifications a bit boring or uninspiring? Do you think the W3C could have done well to include just a little bit of humour in those documents? Then this book is for you.

Way back in 2003, the book's author Patrick Griffiths launched HTML Dog, a comprehensive resource containing tutorials, references, articles, and examples that promote best practices for (X)HTML and CSS. This book is, as you will have guessed by now, based on the site.

HTML Dog consists of three parts. The first part is the normal chapter based book that walks the reader through the various aspects of using XHTML and CSS. Yes, XHTML, not HTML - the book is entirely focused on XHTML. Some may see that as a problem, but I don't. After all this book does teach best practices and sticks to XHTML 1.0 Strict.

The ten chapters of part one explain how to make proper use of XHTML and which element to use for what as well as how to style the result with CSS. Structuring and styling text, creating links (and making sure they are accessible), CSS layout, how to use lists, and how to create accessible and usable tables and forms are some topics that are covered.

At the end (well, the last third of the book) are two extensive appendixes. The first appendix lists and explains the attributes and elements (with a few exceptions) included in XHTML 1.0 Strict, while the second one covers the properties of CSS 2.1. Both are handy references for working offline.

There are a few minor problems, such as a slight misuse of the word "tag" and a couple of incorrectly named selectors, but overall this is a good and entertaining book that does its job at encouraging best practices. Recommended.

HTML Dog: The Best-Practice Guide to XHTML & CSS

Author: Patrick Griffiths

ISBN-10: 0321311396

ISBN-13: 978-0321311399

Add 456 Berea Street to your Technorati favorites.

Posted in (X)HTML, Reviews, Web Standards.

While reading Dean Edwards' post Yet Another JavaScript Library Without Documentation I felt something connect inside my brain. That was a really nice feeling ;-).

The JavaScript library Dean talks about is his own base2.DOM, which is the first library I've looked at that feels completely right to me. It feels right because:

• It uses standard DOM properties and methods
• It lets JavaScript look like JavaScript
• It doesn't use the weird (but popular) "$"
• It doesn't contain any visual effects

What it does is make all supported browsers behave the same way when using standard JavaScript, and implement stuff like the Selectors API and getElementsByClassName().

Great stuff, Dean. Thanks for creating this.

Add 456 Berea Street to your Technorati favorites.

Posted in JavaScript.

With the new W3C HTML Working Group launched, you may feel interested in helping shape the future of HTML. You might also be asking yourself how serious the W3C is about the following statement in the press release:

W3C today invites browser vendors, application developers, and content designers to help design the next version of HTML by participating in the new W3C HTML Working Group.

Speaking from my personal experience, that seems to be for real.

I followed the instructions for joining the Working Group that Ian Hickson posted in W3C restarts HTML effort. My application was accepted, so I am now an "invited expert" (self-invited, mind you), along with all the other Participants in the HTML Working Group. So if you are interested and think you can contribute, do join the WG.

I haven't posted anything to the mailing list yet, as I am trying to get a feel for how things work there before I put my foot in my mouth. I also find it a little difficult to keep up with the amount of email on the list. I haven't been subscribed to any mailing lists with that kind of volume in a while, so I guess it will take some time to get used to it again.

Add 456 Berea Street to your Technorati favorites.

Posted in (X)HTML.

In a surprise move, the W3C today (April 1, 2007) announced the Final Recommendation of the long-awaited new version of its Web Content Accessibility Guidelines, WCAG 2.0.

I don't have any more information than that at the moment, but I am told that those who are interested in learning more about the new version of WCAG should keep an eye on WCAG 2.0 - Finally Here!.

Well, who could have imagined something like this. After years of work and much controversy and discussion in the community... bang, it's done. We all have quite a bit of reading ahead of us.

Update: Gez Lemon provides a little more info in WCAG 2.0 Becomes a Candidate Recommendation.

Update (2007-04-10): Yes, this was an April Fool's joke. No WCAG 2 yet.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility.

It seems like every time somebody mentions browser size, screen resolution or fixed/fluid/elastic width, there will be a side discussion going on about window/application maximising. It happened here a few months ago when I posted Resolution vs. browser size vs. fixed or adaptive width.

I thought it would be interesting to know the habits of people visiting this site, so if you have a minute or two please post a comment with answers to the folllowing questions:

1. Do you normally maximise your browser window, i.e. make it cover the entire screen? (Your answer should reflect what you do during normal use, not while holding presentations or similar.)
2. What is the resolution (in pixels) of your primary screen?
3. Which operating system do you use?

My own answers are as follows:

1. No.
2. 1600 by 1200 pixels.
3. Mac OS X

After a couple of weeks I'll disable comments on this post, evaluate the results, and post a follow-up.

Add 456 Berea Street to your Technorati favorites.

Posted in Web General.

Russia based Erigami have recently released a beta of the new version of their accessibility, privacy, and quality validation tool Truwex Online.

I've been trying it out a bit and think it is a pretty useful tool since it is a little different than most other similar accessibility evaluators. The major difference is that Truwex checks the generated source, not just the raw HTML source. That means checking all the ugly HTML that gets injected into the page by JavaScript. Like the Google Ads on this site. Plenty of accessibility issues to be found there, which of course is no surprise.

Another nice feature is that Truwex creates a "Page Map" that highlights any issues it has found. Great for finding text with insufficient contrast, for instance (yes, I'm aware that there are a few borderline cases of that here).

As with all software tools that try to "validate" accessibility, the results Truwex provides have to be carefully analysed by a human. There's no getting away from that. But still, it's good to have another tool to help produce high quality sites.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility.

Once you've learned the basics of CSS you need some help to advance your skills to the next level. That's what the authors of this book – Jeff Croft, Ian Lloyd, and Dan Rubin – intend to do by sharing solid, practical techniques that you can use in real, professional Web projects. And they do it well.

The book starts with a quick recap of why modern, well-structured markup is important and what CSS is, and then moves on to cover CSS syntax, specificity, the cascade, browsers, CSS management, plus a chapter on hacks and workarounds. After that the actual techniques promised in the title start appearing.

The techniques cover areas such as CSS layouts, typography, and examples of how you can style tables, lists, and forms (form layout, not form controls), and how to use CSS to control what your site will look like when it is printed. Everything is explained in a clear and structured way, making the book easy to read.

Since it is so well-structured, and thanks to the CSS reference, the CSS specificity chart, and the Browser grading chart provided in the appendixes, I think this book actually will work quite well as a reference guide, though obviously not as complete and detailed as Eric Meyer's CSS: The Definitive Guide.

All in all, this is a very solid book. Despite that I do think it could have been even better. First of all, in the book's introduction the authors state that the book is not intended to be an introduction to CSS. Well, perhaps it isn't the very first book to pick up if you are completely new to CSS, but before reading it I thought it would contain slightly more advanced CSS techniques.

Second, I don't know why the authors felt the need to explicitly state that the book is not "a preachy bible for web standards". I didn't find anything in the book that goes against best practices and the spirit of Web standards, so I think that part of the introduction would have been better left out. Just my opinion, of course.

The third nitpick I have is the lack of information about who wrote what. This is a multi-author book, after all, so stating at the beginning of each chapter who wrote it, like in Blog Design Solutions, would have saved the brain cycles I spent on trying to figure out who wrote the part I was reading.

Don't get me wrong–this is a very well-written and solid book, but in my opinion the "Pro" in its name is slightly misleading. "Intermediate CSS Techniques" would have been a more appropriate name. Nevertheless, unless you're already a pro CSS designer, Pro CSS Techniques is well worth its place in your pile of Web books.

Details for Pro CSS Techniques

Authors: Jeff Croft, Ian Lloyd, Dan Rubin

ISBN: 159059732X

Add 456 Berea Street to your Technorati favorites.

Posted in CSS, Reviews.

Just a quick reminder that Connection07 is next week (March 27). If you missed it or need a reminder, my original post about it is Connection07: a conference about the modern Web. I think there are still places left, so register if you haven't already done so.

On a related note, I finally managed to set some time aside for preparing my slides. For this presentation I am using a new tool. I normally use S5, but wasn't quite happy with the format since it doesn't really work that well for presentations that contain more than just basic bulletpoints. And when you want to insert some audio, well, I decided not to go there. And using PowerPoint is out of the question. It is almost as good as IE at making me throw things across the room in anger and frustration.

What I did instead was buy myself a copy of Apple Keynote, and I don't see myself using anything else for presentations from now on. It just works, and it works very well. Keynote really makes Powerpoint look and feel like a cheap toy created by somebody with no sense of aesthetics or usability.

Add 456 Berea Street to your Technorati favorites.

Posted in Conferences.

If you're fed up with all the geeky Web design/developer conferences, how about visiting the Swedish city of Malmö in June to attend a usability conference? From Business to Buttons is a two day conference arranged by usability specialists inUse in cooperation with Malmö University.

Among the speakers at the conference, which takes place on June 14-15 2007, are well-known names such as Brandon Schauer and Ben Saffer from Adaptive Path and and Kim Goodwin from Cooper. There will also be a case study of the New York Times redesign, a chance to learn some secrets from the Yahoo! User Experience Design team, and much more. Full details are available in Keynotes, Seminars & Workshops.

If this sounds good, register now while there are places left.

Add 456 Berea Street to your Technorati favorites.

Posted in Conferences, Usability.