Archive for the ‘Web Design’ Category

« Older Entries

Fonts and font-family

Wednesday, February 3rd, 2010

Yesterday, on Twitter, I watched a discussion emerge as one person I follow pointed out that another person's hosted wordpress.com blog was illegible on her computer, with all of the content appearing in ugly bold italics.

While we never got to the bottom of that issue (I couldn't reproduce it), it's worth backing up and examining font use on the web.

Fonts, unlike any other aspect of web browser rendering, depend on the platform, not the browser version.

The reason is simple: fonts are not bundled with the browser, but with the operating system, or installed with some creative applications.

If you select fonts based on how they look on your computer, they will look different on another computer with a different set of fonts installed. Also, fonts are matched by name in CSS, so when you write

font-family: "Helvetica", "Arial", sans-serif;

you are requesting a font named "Helvetica", then one named "Arial", then the default sans-serif fonts. This is a very common thing for people to write, because Helvetica is a popular choice on Mac, Arial is a popular choice on Windows, and sans-serif is a catch-all. The intention is to select a nice sans-serif font on each platform.

Unfortunately, "Helvetica" can exist on Windows and Linux as well as Mac. Helvetica has been around as a typeface since 1957, and there are different versions of it around – by what route, or with what degree of intellectual property infringement, I do not know. There are also a fair number of variants that your computer might also consider, if they are installed.

On Linux, Helvetica was historically an X bitmap font (ugly, impractical things that are now effectively dead). These days it is generally an fontconfig alias for a free sans-serif font, but renders with iffy hinting and kerning, perhaps to conform to the original font's metrics (ie. it has been shoehorned into exactly the same space, so that printed publications don't come out wrong). I actually find this font quite uncomfortable to read.

On Windows, you may occasionally find Helvetica exists, perhaps even as the same font, installed on its own, or with some software suite, but if you do you'll find several browsers on Windows render fonts with Microsoft's ClearType renderer optimised for legibility, not the Mac's quality-optimised renderer, also used in Safari 3 on Windows. Microsoft own fonts have been tweaked to work well with ClearType – others may not. Linux is (as ever) more flexible: it's possible to configure the amount of hinting to use through fontconfig, although most users will keep their distribution's defaults.

Ultimately it's an impenetrable picture – you cannot be sure that the fonts you list will give anything like the browsing experience you were expecting. The same overall picture applies with serif fonts and monospace fonts.

The best solution (unless you want to try downloadable fonts, which I wouldn't recommend for body fonts) is to side-step the specifics of fonts entirely and delegate to the user/browser/operating system. There are three suitable aliases for font families: sans-serif, serif, and monospace. These will reliably give you a good font of that category. There are two other aliases, cursive and fantasy which are too poorly defined – you could get practically anything.

Is this really the only option? If you're prepared to go to the enormous lengths required, can you not pick a list of named fonts, test broadly and claim it works? Well, yes, if you test broadly enough you can get say 99.9% coverage. Unfortunately, that's not always good enough.

The topic of a site turns out to significantly affect the statistics of users that visit it. For example, a site about Linux will get more Linux hits. A site about using Photoshop will get most hits from people with Adobe Creative Suites installed, and that comes with fonts. So as a theme designer, what was 99%+ for you could be 90% for some of the people who use your theme.

So, in summary, stick to the safe fonts: sans-serif, serif and monospace. Fonts that are ubiquitious and designed for the screen are also quite safe – Arial and Verdana. You might be able to find some other safe places by consulting statistics if you are feeling creatively hemmed in. But please, don't make font assumptions.

Posted in Blogging, Web Design, Web Standards | No Comments »

Bubble Background Animation

Saturday, October 11th, 2008

I was pondering concepts for interesting web designs when the idea occurred to me that an animated bubble effect might lend a peaceful ambience to a webpage. I experimented with placing a Javascript-controlled SVG animation into the background of a page. You might like to judge for yourself whether this is successful or not (SVG-enabled browser required and a reasonably fast CPU recommended).

If you were around at the dawn of dynamic HTML you will probably have stumbled across amateur websites who thought it was really rather stylish to add a Javascript snow or bubble effect over the top of the page content.

Fortunately, those days are gone. By and large, it seems that amateur webmasters today know that just a nice colour scheme and a consistent, simple style trump a jumble of styles, javascript effects and stock animated GIFs that we all remember too well. Nice graphic design is done for you if you just install a blog and browse existing themes. Some may not even remember effects like this (Warning: Not safe for work or indeed any other time you require functioning eyeballs).

It's well-known that animations draw the user's attention in webpages. That doesn't mean we always want to avoid them: sometimes we want to direct the user's attention in one direction or another, particularly when the page is being updated dynamically with Javascript. This is not one of those special cases. Since the goal of this experiment is to build a fully-animated webpage, we will have to ignore that inconvenient little fact. However, this suggests we need to keep the animation as unintrusive as possible. Keeping it nice and slow may help, and it should certainly be in the background and not the foreground.

SVG is useful for this kind of effect because it has a feature (<svg:use>) for manipulating independent clones of a symbol. It is therefore simple to draw the original shape using an SVG editor, and the Javascript merely needs to manage instances of the clones.

Using Inkscape, I drew up a bubble looks like this:

Bubble

There's a certain knack to drawing bubbles like this, of course. Air bubbles in water are colourless, but they are reflective due to total internal reflection. The amount of reflection increases as the angle of incidence increases, up to the critical angle, at which all light is reflected. At a water-air boundary the critical angle is 48.6° so actually the bubble should appear totally reflective from about 75% of the radius.

If this sends you into a bit of a panic as you struggle to remember your school physics lessons, don't worry. I'm not recommending a mathematically accurate implementation of Fresnel's Equations. With a lot of art (not just on computers), an appreciation of the physics can go a long way towards adding realism. But a 100% accurate simulation is not necessary for an effect to seem convincing – trial and error is much easier. The gradient as I've drawn it is not accurate but looks alright. Similarly, bubbles have two specular highlights corresponding to the water-air boundary and the air-water boundary.

As an aside, one day it may be possibly to depict fully reflective and refractive bubbles. Using SVG's incredible feDisplacementMap filter, you could distort the background using a pre-computed "lens" image. But that is unlikely to run at interactive speeds today, even if the filters required were fully and accurately supported, which they are not. The bubbles I've drawn are intended to be a compromise between rendering simplicity and attractiveness.

The bubble system (really just the SVG on its own) animates 20 clones of the bubble symbol. Again, this is based on some physical principles. The smaller bubbles are subject to less drag so have a higher terminal velocity, bubbles grow slightly as they rise and the pressure decreases and so on. One of the most effective things is that the bubbles drift with a random walk: they can randomly drift to one side or the other. They don't go straight up nor do they oscillate sinusoidally like the classic DynamicDrive script. For the most effective animation, bubbles would drift with the currents but this is simpler and reasonably effective.

I am quite pleased with the results. To really rid ourselves of the legacy of Javascript-animated GIF images, it would be important for this effect to tie in with the graphic design of the page, which I haven't shown.

I don't think this is realistically ready for production websites: Internet Explorer cannot display SVG, for one thing, and the intensive CPU requirement is also a problem. But I do think that sharp SVG graphics allow us to produce a wholly better standard of animation than what was possible before. With this, I think it's possible to make a bubble animation complement rather than detract from a web page.

Posted in Artwork, SVG, Web Design | 1 Comment »

Tip: Rectangles With Rounded Corners

Sunday, February 17th, 2008

When in 1981 Steve Jobs said that "Rectangles with rounded corners are everywhere" he began a trend which today sees dozens of rounded rectangles on millions of PC screens almost all the time.

On the web the situation is even more desperate. Bound by the available technology, and aiming towards intuitive and usable HCI, designers often draw on rounded rectangles to make functional layouts appear more friendly and personal. More than that, using rounded rectangles is perhaps the simplest way to design a site that isn't just boxy and dull.

In CSS, there are two well-known approaches. The fluid-width approach is to stick small graphics of rounded corners into each corner of a box – these cover up the box's corners and make it appear round. The fixed-width approach is to have top and bottom images that comprise the corners, and a tiling background to blend between the two. CSS3 offers an improved background model that will render these hacks unnecessary.

Rounded rectangles in CSS2

Of course, it's not necessary to stick to plain rectangles: using the above approaches, it's possible to decorate them with drop shadows, highlights, stripes, cutouts or whatever else you'd like to. These aren't just techniques for cutting corners – they generalise to techniques for decorating web-based boxes.

There are some caveats with nested rounded rectangles that you should watch out for. This is how nested boxes with rounded corners should appear.

Rounded rectangles done right

The arcs for all the nested rounded boxes that share a corner should be arcs of concentric circles. In practice, this just means tweak the radii until they look right – so that they appear to focus on a point. Any square boxes should fall inside that focus.

Notice in the diagram below how square corners don't work unless they are inside the focus. Nesting rounded boxes inside square boxes is an absolute don't. A more common mistake is to use the same corner radius for an outer rounded rectangle as for a nested one. Most tools preserve the setting for corner radius, and that's not what you want. Notice how the outer box appears proud in the diagram below, right (cf. above, left)

Rounded rectangle mistakes

Notice below how when the boxes don't share a corner, you can use the same corner radius, but the effect is slightly different. Using the above rule-of-thumb throughout will keep the design a little more down-to-earth.

When you can use rounded corners with the same radii

Posted in Tips, Web Design | No Comments »

Tip: Mock up your designs

Thursday, January 3rd, 2008

A lot of hobbyist web designers start by creating the content for their web pages, then try to add graphics to "spice it up". This is a mistake. It's very hard to make a page look appealing in retrospect.

Start with a high-quality vector graphics tool – I recommend Inkscape – and properly design the website. To represent where to put content use Lorem Ipsum or simply rectangles to represent individual paragraphs. Once you are satisfied with a design, recreate it in HTML, exporting any graphical elements you need from the mockup.

You can use this approach even for sites that don't need graphics; it is beneficial for choosing colours, fonts and layouts as well as for creating fully graphical sites.

Be careful though – you need to design a mockup that you can successfully convert to HTML. Graphics programs are WYSIWYG but the web is not and this places constraints on what you can successfully produce. Beware in particular of how the site changes as your browser window or text size changes.

Posted in Tips, Web Design | No Comments »

Misconfigure your browser

Saturday, October 20th, 2007

Most mistakes web designers make stem from the assumption that the way they are seeing the site in their web browser is the way everyone else sees it. By using uncommon defaults in your web browser, you can ensure that you have left to the default only those aspects of a page which you had intended. I call this "misconfiguring" because it is intentionally configuring a web browser to display pages wrongly. If the page looks correct with such settings it is probable nothing has been left to chance.

It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:

  • Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
  • Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
  • Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
  • Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
  • Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
  • Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.

The browser defaults which you may want to change include

  • Character set
  • Background colour
  • Text colour
  • Font style
  • Font size, although in theory you should avoid specifying this for accessibility reasons.

Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn't wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.

Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I'm experimenting with ISO-8859-11 (Thai) as my default character set, because this isn't compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don't specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.

So my default browser settings look like this. If I ever see these styles on a page, I know I've failed to specify something.

Posted in Browsers, Web Design | No Comments »

The Accessible Calendar

Thursday, October 11th, 2007

For most of us, visualising date and time comes very naturally. I'm sure if we surveyed how people visualise date and time there would be some similarity among a plethora of different answers. However, one form stands alone for its ubiquity: a year-planner-style calendar. Twelve grids of numbers, each seven columns wide, four to six rows deep. Click on a number to do something with that date.

Calendars are so simple for me and – statistically – you that it's easy to forget that a server-generated calendar like this is actually not accessible at all. The issue here is linearisation: flattening out the days of the calendar to a script that can be read – aloud, in braille… or by a search engine. A calendar in this form linearises to a script that reads like this:

January. One. Two. Three. Four. Five. Six. Seven. Eight. Nine. Ten. Yawn. Zzz. Snore… February. One. Two…

And so on. It's not useful to read out 365 numbers (366 next year) and expect users to just wait to respond when the day of the year they are looking for comes up.

What is the accessible version? Well, the approach to take is to work out the linearisation we would like first. For example,

The following periods are currently available: the fifteenth of October to the twenty-ninth of November, then the eleventh of December to the seventeenth. Which date are you interested in?

Now, for a web page we might not expect to follow this pattern exactly, but the model is clear: list the calendar information, then query for a date. It looks something like this:

Periods Available

  • 15th October – 29th November
  • 11th – 17th December

This is not bad even in a graphical user agent; describing calendars as schedules is not hard to visualise. Note that it would be perfectly possible to use Javascript to convert this calendar to a visual representation. Whether using Javascript in this way is accessible is open to debate. There is no reason screen readers can't execute Javascript. Some, I believe, already do. But there is a trend for graphical browsers to provide Javascript and for non-graphical browsers not to.

I'd suggest if you are willing to forgo an approach that caters ideally to non-visual users, it's possible to do better. We can cheat the system, almost, by using alt attributes in images and image maps to provide the schedule version as above, but for the images and maps to supply the visual layout. In my latest project, I'm also using line boxes full of images rather than a table. This allows a single <a> tag to span a whole month worth of dates. But what it saves on the semantics, it loses on file size. A cheaper approach might be client-side image maps, especially of the lesser-known form involving <a shape=""> tags rather than <area shape=""> elements, or similar features in SVG.

However, even with the approaches I've explored above, this is one area where I suspect there may not be a very solution that does equally well for visual and non-visual users. 365 dates worth of information is difficult to represent in a concise form. That's why we use calendars.

Posted in Web Design | No Comments »

Big World Travelog

Wednesday, January 3rd, 2007

I finished updated my brother's blog over New Year, and I'm now quite happy with it. I spent ages on a graphical title block in Inkscape. I'm not totally satisfied with the caricatures who are a little more cartoony than I would have liked. The new theme is based on K2, which I do think is pretty.

I had a strange bug with the Google Maps on the gallery which I found after a bit of searching was caused by Google Maps not supporting embedding within XHTML. But I'm pleased that the thumbnailing/unthumbnailing works so well. Previously the map enlarged and reduced; this is much less intrusive in either state.

I did have to disable all of K2's shiny Javascript features to make it work with my Javascript (for map markers) :( But they were a UI disaster anyway. One of the advantages to JS over Flash is that it allows us not to create horrific new UI paradigms. So going to great lengths to do so is missing the point.

Posted in Artwork, Blogging, Javascript, Web Design | No Comments »

New Theme Ideas

Monday, November 13th, 2006

The other day I doodled some ideas for themes for this blog. Not really based around web design. Just interesting concepts, hopefully.

Chocolate Tentacles Chocohellic

Posted in Artwork, Blogging, Web Design | No Comments »

Data mining with AJAX

Friday, October 27th, 2006

Just had an idea: how about using Javascript to record client-side usage of your website?

The principle is this:

  1. Register Javascript listeners which construct a list of events, particularly mouse, scroll and click events, along with the time that the event was fired.
  2. Register an unload event which posts the information as XML with AJAX to a script on the server when the user leaves the page.
  3. Browsing sessions can be collated on the server using cookies.
  4. Create a player, which reads the events as XML and renders them using a DHTML 'cursor' and/or by firing events within the DOM. Could have a time slider and fast-forward controls, etc, depending on how complex you want to get.

Voila – see exactly what people are doing with your site. I have knocked up a test which implements the first two steps, for mousemove events, and that much works, so the whole concept would be workable. I can imagine it would break down if your site uses plugins (or Javascript navigation, depending on how easy it is to replay the events accurately) but that's a limitation you would have to live with.

There are obviously privacy concerns but this is relatively mild as no personal data would be recorded. Perhaps it could pop up a Javascript window.confirm() dialog asking if it's OK to record your behaviour. But it would be a very useful tool for examining site usage, especially for commercial sites. This is the way modern marketing works. I leave it up to your conscience as to whether it's ethical.

Posted in AJAX, Business, Web Design | 2 Comments »

Construction in Inkscape

Monday, September 25th, 2006

Sometimes – increasingly perhaps – I find myself using Inkscape for constructing program assets.

Program assets are a different beast to standalone artworks because you start to have to recombine artistic elements in new ways programmatically.

Most of the time, when web programming, you don't really need to generate completely original artwork on the fly, but you often need to composite some selection of pre-drawn assets. There are a variety of ways to do this, but Inkscape doesn't seem to make any of them very easy for me.

(more…)

Posted in Artwork, SVG, Web Design | 4 Comments »

« Older Entries