New feature: Recently Referred Visitors

Based on Dean Allen’s Refer code, the new Recently Referred Visitors feature lists the last 50 visitors to Acts of Volition who have been recently referred to our site. The user’s domain/IP, the referring site/page/URL, and the destination page/URL are all displayed.

Warning, it can be addictive. At the height of my Mac-punditry-fame this past week, I couldn’t keep up with the referrals. There’s something spooky about seeing people visiting your site from navy.mil and boeing.com.

Thanks to Mad Mike for setting it up and Deal Allen for releasing the original Refer code.

Meanwhile, in the land of our weblog engine, we answer some questions about selling it (sorta/kinda) and two new sites go up using the system: GenX at 40 and The Daily Commute. That’s in addition to CEOBlues.com and newrecruit. Look for more in the days and weeks to come.

 

Spring Cleaning at AOV

Now that Acts of Volition is running off a new code-base, I’ll be making occasional tweaks and (hopefully) improvements.

First off, a minor design update. Comments are welcome. More changes in the weeks to come.

Two other fine sites are also now running on our spiffy new code-base (run by two co-workers and GeoURL neighbours of mine):

 

The Town Wide Web

The internet lets school children in Mongolia work on science projects with kids from Florida, right? That’s cool and all, but it also let’s you find out what’s playing at the cinema a few blocks away.

The web can be local. In fact, I’m having tea with some virtual/actual neighbours this week. Some of whom I have never met in person.

The GeoURL project longitude and latitude coordinates to websites. Acts of Volition sits happily at 46.26227° North and 63.15676° West. They refer to this location as your “ICBM Address” or “missile address”.

Add a few simple tags to your site, in our case:

<meta name=”ICBM” content=”46.26227,-63.15676″ />
<meta name=”DC.title” content=”Acts of Volition” />

The GeoURL project indexes your site (you can ping them to let them know you want to be indexed), picks up these tags, and adds your site to their database. You can then view a page of neighbours; sites that are geographically nearby. While most of my GeoURL-neighbours are a about 170 Km away in Halifax, I expect to see more of my neighbours in Charlottetown show up in the GeoURL database soon.

This is an elegant little application of what is to come with the semantic web.

Also see Ben Brown’s article, Taking Interactivity Offline.

 

If a tree falls in the forest, and there’s no one there to blog it…

Being almost as North-by-North-East as you can get on this continent, I didn’t get to the South by South West conference. However, the host of the SXSW Web Awards ceremony, John Styn (this link leads to a man in pink briefs), put together a series of videos in the style of Apple’s Switch campaign.

The video on blogging is gold: “If a tree falls in the forest and there’s no one there to blog it, did it really fall?” – (14Mb Windows Media file).

 

Open Software Development Process

When you spend much of every day in front of a computer (which you probably do if you are reading this), you come to know the intricacies and quirks of your software much as a musician comes to know the feel of their favourite instrument. Sometimes the smallest bugs can become the biggest annoyance.

Internet Explorer is a program I use frequently. In general, it is a good program. However, it has quirks that drive me mad. Many of these quirks affect many users and could probably be fixed in a matter of hours. However, I don’t report these issues to Microsoft. Why is that?

I don’t think Microsoft will listen. I don’t think Microsoft is a bad company (you should be suspicious of anyone who claims it is). However, Microsoft is not a particularly open company, and they are enormous. Would my feature request or bug fix request ever get through to a person who would be able to evaluate it effectively? I doubt it. This isn’t necessarily Microsoft’s fault, though I’m sure they could improve both their responsiveness and my perception of their responsiveness. It may simply be that there are too many people like me with too much feedback to reasonably parse.

This is where smaller and more open software development processes can really shine. In the past few months, since Apple’s Safari web browser project was announced, there has been a lot of discussion and an enormous amount of feedback on the browser. I’m sure there was a lot of noise, but there has certainly been a lot of useful feedback.

Add to this an open and responsive developer, and things get interesting. David Hyatt was hired by Apple to work on the Safari project. He publishes a weblog on which he regularly posts progress, requests for input, and explanations of choices from the Safari project. Apple was brilliant to let him do this.

Take for example, a public exchange that took place between a Safari user (and web expert), Jeffrey Zeldman, and Safari developer David Hyatt. Zeldman posted a detailed comparison of his site on the Safari browser and the Mozilla/Gecko-based Chimera (now called Camino – good name choice, by the way). The next day, Hyatt posted a response explaining the reasoning behind the differences.

Hyatt was equally open and responsive to input when weblogger Mark Pilgrim posted his initial feedback on the Safari beta.

Hyatt is not alone in his process. Dave Winer (formerly) of Userland Software, Ben & Mena Trott of MoveableType, Brent Simmons of NetNewsWire, and many others all communicate and collaborate with the users of their software.

It is important to note that none of these projects are open source. Some, like Apple’s Safari project work with open source projects (the KHTML rendering engine, in the case of Safari), but they are not open source themselves.

This openness makes me want to use their software. It makes me confident that my input will be considered and my problems with an application might disappear in an upcoming version. I’ve seen desire for openness in software development drive software choices in a corporate development environment as well.

This is obviously not a large concern for all users. My parents are not interested in communicating with the developer of their browser – they just want their Hotmail. However, there is a large community of wannabe experts like me that collectively bear significant influence on choice of software (my parents are using Mozilla, because I installed it for them).

I would love to see other key Microsoft and Apple developers blogging (let’s see some key Microsoft and Apple executives blogging while we’re at it).

 

Universal Access to All Human Knowledge

Brewster Kahle speaking at the Library of CongressA link found from Matt Haughey’s a.wholelottanothing.org lead me to a talk by Brewster Kahle of the Internet Archive. His organization is working a variety of projects to make public domain content available in an “internet library”. Among these projects is the WayBack Machine, which archives the web.

The talk is part of a series at the Library of Congress and runs 1 hour and 26 minutes in RealVideo format. It is worth watching: Brewster Kahle: Public Access to Digital Materials (1hr 26min RealVideo).

Kahle’s basic idea is universal access to all human knowledge. Every book, speech, TV show, website, concert, etc. should be available to all of us. He looks at three main questions:

  • Should we? Yes!
  • Can we? Is it logistically possible from a technical and financial perspective? His answer: Yes.
  • May we? Will we be allowed to make all knowledge available under law? His answer: Yes.
  • Will we? He leaves this as an open question.

His numbers on the cost to digitize (scanning, etc.), store (disk space), and make available (bandwidth) all human knowledge are fascinating. According to Kahle, the hardware and labour costs required to make all book and all television and all music ever created available are not that difficult (within the hundreds of millions of dollars).

Taking books for example:

  • There are roughly 100,000,000 books ever created
  • The Library of Congress has about 26,000,000 books (I was impressed and amazed that the Library of Congress has 26% of all books ever created)
  • A book costs between $10 and $100 to acquire and digitize
  • A book takes up about 1Mb of space
  • 26,000,000 books would take 26 TeraBytes.
  • 1 TeraByte costs about $60,000
  • The entire Library of Congress could be stored for about $1.5 million dollars
  • Books can be printed, cut, and bound for $1/book from a mobile book printer (~$15,000)

If anyone has the right to make these claims – it would be Kahle – who’s organization is storing massive amounts of data as part of their WayBack project and other projects.

 

Writing semantic markup: Robots to the rescue!

Some very smart people think that the next big leap in web technology will be on the foundation of the Semantic Web. However, some other very smart people are raising concerns that this semantic utopia may be unattainable.

Matthew Thomas is an interface designer from New Zealand. Yesterday on his website, he posted a summary of a few of these smart people’s concerns about the move towards semantic markup on the web. The biggest problem is that people just don’t care about the semantic web. It takes an essay just to explain what the semantic web is – but that doesn’t mean it’s not a worthwhile idea.

I’m sympathetic to Thomas’ points here. I’ve been working to move a web-based system to the XHTML standard. On top of the usual CSS struggles (my mind still thinks in [table] tags, but I’m slowly learning to love CSS), I’m running into a difficult problem. On this particular web system (and on many, if not most, web systems), the users generate most of the content.

First of all, the web is a crappy medium for writing. It’s good for publishing what you write, but it is terrible at the actual writing stage. Spell checking, periodic backup, saving drafts, etc. – all features we’ve grown accustomed to in word processing – are sitting there, in the next window, just a few pixels away from our arcane DOS-esque text-only [textarea] form input box. Lame.

First, we need the browser makers to put better text-editing tools at our disposal. However, here’s where it gets a little complicated. You’ve probably heard hot-shot web developers scoffing at WYSIWYG web-editors before. This is mostly because they product messy and convoluted code. There is, a deeper problem though. The web is not a WYSIWYG medium. The whole idea of XHTML and CSS technologies are that you can separate design from content – style from meaning. WYSI-not-WYG.

A simple (inane) example: I recently posted a reply to a post on the Signal vs. Noise weblog. I included a quote in my reply. I used the [blockquote] tag to indicate which part of my reply was a quote. When I submitted the post, I was pleasantly surprised to see that our friends at Signal vs. Noise had included some nice formatting for the blockquote tag in their stylesheet. As a result, my quote was nicely formatted to fit in their style and layout.

There is a powerful idea behind this simple example. When I used the [blockquote] tag, I wasn’t ‘formatting’ my post. I was adding meaning to the text – I was using machine-readable language to tell web browsers that the next few words are a quote. I didn’t know exactly what it was going to look like. (Note: there are better ways to cite a quote, but this example makes the point)

I’m not sure we can expect everyone to make this distinction. I do think, however, that people can produce writing with semantic markup if the software does the hard work.

We need a semantic-friendly-WYIWYG text editor for the web. Here are some proposed features:

  • Hide the code from the writer (but make it accessible to those who want it – as many current editors do).
  • Provide only semantic tools: lists, blockquotes, citations, links, emphasis, strong, etc.
  • Not quite WYSIWYG: show the text in real time in a typically styled format – perhaps even adopting the style of the destination website.
  • Automate the creation of meaningful markup. For example, when a link is created, prompt the author for a descriptive link title.

By the way, someone has come up with an apt name for what I’m doing here. It’s called the LazyWeb – when smart-asses like me rant and rave, but don’t do anything about it. The hope is that through the LazyWeb, people willing to write code and implement can meet up with the idea (read: lazy) people.

 

Browser of Babel

Apple Safari IconToday, Apple introduced a new browser, called Safari. Also today, every web designer and developer in the world let out a big sigh and said a big collective: Crap!

As you can see from my last post, the differences between browser rendering engines give us indigestion. That said, my first impression of Safari was quite good. For those that care, it is not based on the gecko engine as some may have expected (and hoped). Rather it uses the KDE’s KHTML library from the linux community. More web developer info on Safari is available at dive into mark.

An interesting note about Apple’s release of Safari and a few other Apple apps this past year: they are blurring the line between beta and final versions of software. This is a beta release of Safari, but it is launched and promoted with as much fanfare as any final product would be. For better or for worse, the public is now a beta tester (not necessarily a bad thing – especially since only those who want it will bother downloading it).

 

Taking our struggle with CSS font sizes public

Those readers not interested in web design issues, please pardon this post. For the rest of you, the following is a series of posts I made on the corporate intranet at work. We’ve been struggling with CSS font-size issues. It’s nothing original, but it is my hope that posting the explanation of the problem and one (of many, I’m sure) potential solution I wrote for my co-workers might be of help to others dealing with the same issues.

I’m also interested in feedback on the techniques we used. What did we miss? I’ve tested across a wide range of browsers, but if you notice any weirdness – please let me know.

My first post was an explanation of the problem – basically written so I could straighten it out in my head:

Posted to the silverorange Intranet by Steven Garrity
– January 3, 2003

We’re having some difficulty with font size issues with CSS and I thought it might be helpful to lay out everything we’ve been talking about in one location.

First, some history. We are using CSS percentages (eg. font-size: 75%;) to do font sizes on most of our current sites. We discovered last year that some Mac browsers were inheriting the font sizes recursively (since we put font-size: 75%; on all [td] tags, any table in side a table would be 75% of 75%, eventually getting to the point of being ridiculously small.

We couldn’t replicate this Mac browser inheritance issue ourselves, but it is documented, so we now sniff out all Mac browsers, and all Netscape browsers (on any platform) and show them pixel-based font sizes (eg. font-size: 12px;).

Pixel font sizes are by far the most reliable font sizing technique across all browsers, but unfortunately, none of the IE/Win browsers (including 4, 5, 5.5, and 6 – basically everyone on the internet), allow the user to resize fonts specified in pixels. This is really shitty – it was on Jakob Nielsen’s Top Ten Web-Design Mistakes of 2002.

Some browsers, like all mozilla/gecko-based browsers and Opera, allow the user to resize any fonts – regardless of how they are specified (including pixels). However, the majority of web users are running IE 5, 5.5, or 6. So pixels are easy to work with – but limit IE users from resizing.

The solution we have on most of our live sites right now (Horton Brasses, NovaScotian Crystal, The silverorange Intranet, etc.) works ok (percentages for smart browsers, pixels for dumb browsers). Any kind of browser sniffing is messy, but it works.

The trouble came when we started the move towards XHTML 1.0 (from HTML4.01). Using our current percentage font-sizing technique, if you change the DOCTYPE from HTML4.01 to XHTML, in IE 6, things go wacky. All of the sudden, IE decides to use the inheritance model correctly (which sounds good, but we were taking advantage of it’s weakness in this area – serves us right for leaning on bugs).

So, to make the move to XHTML, we have to figure out a different way to do font sizes. This really sucks, because we are very close to being XHTML compliant – it wasn’t nearly has hard (other than this issue) as we had anticipated.

Here are the options as I see them, let me know what I’ve missed:

  1. Switch to pixels entirely
    This would be a breeze from our perspective, but we would be locking font sizes for squinting IE users everywhere. We could make a font sizing widget in the pages themselves to resize, but I’ve always hated those.
  2. Stick with HTML4 for now
    We don’t have to move to XHTML. Stay with HTML4 would let us continue with our current tried and true font sizing technique.
  3. Avoid nesting of classes
    Inheriting percentage sizes only becomes and issue when you nest classes (or put classes on items that get nested themselves, like [td] tags). Wired News uses this technique to create a fantastic CSS layout with flexible font sizes in all browsers. This is my preference so far – however, it involves some annoying reworking of the way we use classes to avoid nesting.
  4. Use CSS font size keywords
    CSS has keywords that work much like the old [font size=”-1″] HTML tags. These work well, except for an inconsistency in IE5 and IE5.5 – but there is an elegant hack to get around this. Keywords don’t inherit – so a small inside an x-small is the same as outside. Sounds good – however, the default sizes aren’t great. For example, you can’t the equivalent of the 70% Verdana we use so widely (here on the Intranet, for example).

Ok – that’s the state of the union address on font size issues. I wanted to write it out to get all of us and I all on the same page – but I also wanted to write it out to help sort it out in my head. What a mess.

I might post this publicly (linked from aov, maybe) to see if we can get any helpful feedback, but I doubt it. [note: I thought I’d leave this in to show how resentful I am of all of you morons when in private 😉 ]

I think our best bet might be to follow the lead of Wired News (using option 3 in the list above). They’ve made a wicked site with out inheritance issues anywhere. However, this would prove to be very time consuming on existing sites. Maybe keep the current sites at HTML4 for now, and start our next site (and update small, easy-to-convert sites, like silverorange.com) using this technique and XHTML?

Bah.

Then, after some sleep and a night of feverish delieum battling the flu, I posted this possible solution:

Posted to the silverorange Intranet by Steven Garrity
– January 5, 2003

My subconcious brain has been working on this problem all week. Now, I think I have a potential solution for our CSS font sizing issues. This proposal is implemented on the stage silverorange site. Please report any weirdness. I’m going to do more testing before going live, but so far so good. Here’s what I’m doing:

  • I’ve moved from including the styles from a PHP file do doing the browser sniffing outside the CSS file. This allows us to include actually .css files rather than embedding the CSS in the HTML (browsers can cache the CSS – saving time and bandwidth).
  • I’ve simplified the browser sniffing. We were sniffing out Netscape 4 and below and all Mac browsers and showing them Pixels rather than Percentage font sizes. Now I’m only sniffing out NS4 and below (I’m not longer sniffing out Mac browsers). The trouble on the mac was with inherited percentages – and I’m not using them anymore.
  • There are three CSS files:
    • All browsers:
      • core.css – this file includes any styles (or part of styles) that are safe in all browsers
    • Netscape 4 (and below):
      • dumb.css – this aptly named file contains Pixel font sizes and a few other variations (line spacing is smaller, etc.)
    • All browsers other than NS4 (and below):
      • smart.css – this file is includes the combination keyword/percentage font size solution described below
  • Font size:
    • Netscape 4 and below sees only pixel font sizes – if we decide to ditch Netscape 4 at any time, we can lose all browser sniffing for stylesheets!
    • For all other browsers (on all platforms, including the mac), I’m using the Wired News solution: Declare keyword (small) font size as the base font size (for [body], [td], and any other key containers)
    • IE 4, 5, and 5.5 make the font size keywords one step larger than every other browser in the universe. There is a hack called the ?box model hack? that gets around this.
    • This base keyword font size is the basic full size Verdana used as the body text.
    • Any other font sizes (titles, and the beautiful smaller Verdana text used often on the site) and sized as a percentage of the keyword base font. These styles are never nested, meaning there are no inheritance issues.
    • This means that it you want the base font size (full size Verdana), then no style is needed at all (as it’s the base font size for the document).

I’ve done a bunch of testing and haven’t found any cracks in this method yet. However, dealing with the browsers is voodoo, so I’m going to do a bit more testing before implementing.

What separates this solution from the options listed in my previous post on the subject (above) is that I hadn’t thought of using CSS keywords as the base font size setting.

The solution discussed in this second post is now implemented at silverorange.com. Please let me know of any issues.

 

Bullet lists of Good and Evil

I’m working on getting out of this glass house so I can throw more stones. In the meantime, a great pet-peeve of mine is bullet lists that don’t indent properly when lines wrap.

A stupid bullet list:

• Divitias alius fuluo sibi congerat auro et teneat culti iugera multa soli,quem labor adsiduus uicino terreat hoste.
• Martia cui somnos classica pulsa fugent: me mea paupertas uita traducat inerti, dum meus adsiduo luceat igne focus.
• ipse seram teneras maturo tempore uites rusticus et facili grandia poma manu.

A smart bullet list:

  • Divitias alius fuluo sibi congerat auro et teneat culti iugera multa soli,quem labor adsiduus uicino terreat hoste.
  • Martia cui somnos classica pulsa fugent: me mea paupertas uita traducat inerti, dum meus adsiduo luceat igne focus.
  • ipse seram teneras maturo tempore uites rusticus et facili grandia poma manu.

As the principal at a local high school used to say over the PA-system: You know who you are, whoever you are!