Archive for the ‘Blogging’ Category

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.

RSS: Error-prone

Wednesday, June 24th, 2009

I subscribe to only about a dozen RSS or Atom feeds, but more than half of them suffer from one problem or another.

  • Intermittently dumping a dozen duplicate posts.
  • Dumping a dozen duplicate posts on every refresh.
  • Duplicating the most recent post on every refresh.
  • Double-escaping HTML entities, so I see “, ”, … and such like in post names.
  • XML syntax errors causing total feed outage until some improperly encoded post drops off the feed.
  • <pre> code snippets that have lost their formatting.
  • And, of course, the occasional snippet of HTML that doesn't work as intended when removed from the context of the original HTML document and embedded in RSS.

I often have to search for Pipes to get a useful feed, which is a consequence of the way RSS specifies only a data format, not an obligation on producers, an architectural flaw I've discussed before.

But quite aside from this, it seems that a significant proportion of feeds aren't implemented properly.

Obviously we can blame developers for bugs, but the design of RSS may well be a contributing factor. The process of encapsulating HTML fragments in XML is not as straightforward as it looks. The requirement for a unique ID for each post at first glance does not look onerous. But does the ID correspond to the specific version of a post? Or does it correspond to the current version, however it may have changed since it was first published?

RSS may be useful, but it should also just work, and it doesn't. Developers and standardistas alike should start thinking why.

Wordpress Audio Player

Friday, January 9th, 2009

Martin Laine's Wordpress Audio Player seems to have quite a broad penetration, but having seen it in a couple of places, I want to add that I think it's an excellent. When not playing, it's a plain, unintrusive icon that clearly indicates an option to play a sound, and which smoothly expands to a straightforward, clutter-free player. By changing the colour scheme, you could make this fit with nearly any website style, and unlike many alternatives it will not draw attention away from your text or audio content.

Exploring publishing models

Wednesday, February 6th, 2008

I have been increasingly drawn into the world of blogging over the past few years. It is sometimes claimed that the blogosphere represents an information publishing revolution, and I wouldn't disagree. Blogs are, in their simplest terms, a simplified content management system that has very simple and clear semantics and a very low barrier to entry. I sell customised blogs to my clients on exactly that basis. They are the cheapest websites we can offer.

Blogs are a trade off. Blogs make publishing easy, but the value of the collected content doesn't increase as fast the quantity of posts increases, not in a single blog nor in the blogosphere as a whole. The archives of the blogosphere are hard to navigate. Where information can be found it may be wrapped up in reams of prose or buried way down in the comments. Most of the value of a blog lies in the most recent posts – the ones advertised at the top of the first page and the RSS feed. This, of course, is perfectly suited to news.

One comparison I could draw is with wikis. Wikis offer collaborative editing and this tends to increase the quality of the content as a whole (if the rate of improvement outpaces the rate of vandalism). Wikis are as a whole more up-to-date than blogs too, because old articles linger indefinitely in the archives of blogs, whereas wiki pages are replaced in situ. Personally I find a single wiki – Wikipedia – more useful than the entire blogosphere. It's a very complex comparison to draw and an endlessly debatable one, but wikis offer a model which allows discussion or documentation of topics which are deeply interwoven – which is almost everything. Blogs mediate the actual mechanics of a single discussion better.

For professional publishing, we should try to identify and capitalise on the benefits of both of these models. It's very tempting for me just to tack a blog onto a finished website so there is a channel for the owners to communicate with users, but lots of professional sites end up fronted by a rather dull blog, filled with unedifying news and other tidbits the authors think might engender some interest or at least turn up in search results. Instead, the heavily hyperlinked nature of a wiki could allow visitors to click from this sequential news to in-depth information, and collaborative editing (internally not publically, of course) could increase the quality of the content they find better than a shallow hierarchy of authors and editors.

I'd be interested to know if there's an advantage to releasing content in "issues" like a magazine. I wonder in particular if visitors can get more engaged in a site when it complete refreshes once a week than when there's a slow but steady drip of articles. Not a great proportion of sites do this although I can think of a few (The Onion, Linux Gazette). By publishing in issues your RSS feed becomes an invitation, not a medium in itself, an approach which would partly quench my long-standing gripes about RSS. But spending a fortnight writing and editing articles could be much more valuable than a constant drip of articles. But above all it could allow time to create unique and engaging graphic design for dynamic content, a holy grail for the web industry, and something I'll talk about another time.

Writing an RSS client

Tuesday, February 13th, 2007

Interestingly, my latest paid project is to build an RSS reader. I am doing this not out of bloody-minded determination to reinvent the wheel, and I would be perfectly happy to adapt an existing project to work in the way I want, but none of the apps I have seen or tried does what I want it to do.

This project is a desktop feed notifier. It will poll feeds and pop up messages (non-intrusively) either when it starts or when it first sees them.

I have mentioned my views on RSS before, but happily they don't conflict this project. Because this is aimed at intranet service notifications there is a contract between producer and consumer, not merely a shared protocol.

I think that one good aspect of RSS is its ubiquity. Several apps already in use in this Intranet are RSS-aware and can be wired into this system with a minimum of work.

Without wanting to revisit the previous arguments too much, I might as well summarise them for completeness. I can envisage only two useful strategies for a syndication format:

  • Fixed contract: Specify a unique set of obligations for producer and consumer including both syntax and semantics. eg. RSS 0.90
  • Negotiated contract: Specify obligations of syntax, but encourage producers to offer a complete semantic representation, and allow consumers to build a customised syndication from within it. eg. RDF.

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.

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

Why I'm not sold on RSS

Saturday, October 14th, 2006

I don't know if I'm the only one but I've just never gotten on with RSS (under the umbrella of which I include Atom too). Nothing I've read about it resolves these open questions:

  • What is RSS for?
  • Why is RSS the best way to do… whatever it is that it's for?

I think that RSS's history lends credibility to the fact that nobody really has the answers to those questions.

(more…)

Planet HantsLUG

Tuesday, September 19th, 2006

My namesake Alan Pope has added this blog to Planet HantsLUG. Hello HantsLUG people!

SVG Kubrick Source

Monday, September 18th, 2006

One of the first things I wanted to do with Oli's blog was start making minor alterations to the default Kubrick theme (which I really like, incidentally) in my favourite vector graphics editor, Inkscape. However, after searching the web for the source, I eventually found that the original source was a Photoshop file – one that the GIMP couldn't open.

Frankly, I don't think this is a very good show for an application which purports to be open-source. Anyway, as a result I pulled Wordpress's assets into Inkscape and reconstructed the graphics, as closely as I could, tracing the originals.

The result is an SVG file and a shell script to extract the assets. The assets should all be replaced together because the match isn't quite pixel perfect, but if you do replace them you shouldn't notice the difference.