mediajunk

Bill Thompson has an entertaining diatribe against web 2.0 in The Register (via Nick Carr).

I agree that web 2.0 is over-hyped (hey, even boo.com is relaunching and it's registered to a Dublin-based woman; make of that what you will).

However, there seems to be a sense among traditional software developers, Thompson among them, that the pendulum has shifted too far in favour of interface designers.

But Ajaxian interface techniques are not always popular with interface designers and usability experts.

Many so-called rich internet applications (RIAs) are not cross-browser compatible. They are a nightmare for visually impaired users who rely on screen readers, and a pain in the neck for millions of internet users in developing countries where broadband is, ahem, a pipe dream.

Interfaces that update on the fly cause usability headaches for interaction designers for one simple reason: with RIAs, the web page doesn't refresh.

As counter-intuitive as it sounds, page refresh is useful; it signals that the application is responding to your actions. And, until all sites are RIAs, users will expect page refresh. This was exactly what Vikram Goyal discovered when he decided to try an Ajaxian search interface out on some users:

I was happy with the result and so was my manager and we decided to show this to the users. They hated it.

So, while the basic infrastructure that websites are built on may well need to be remodelled, reconsidered and upgraded, we're still a long way from achieving usable interfaces as a standard.

I've created this entry using Performancing - a Firefox plugin that lets you create blog entries via a WYSIWYG editor that runs in your browser.

Since I'm creating this post directly in the browser, I don't have to login to my Movable Type account via the web, so I don't have to wait for it to load.

Another advantage is that the editor has all of the basic formatting capabilities you'd expect - bold, italics, quote, bullet points, insert image, etc. On the downside, however, I've just noticed that the HTML "b" and "i" tags are used rather than "strong" and "em", so I've had to switch to HTML mode and change these manually.

Hopefully these issues will be resolved in the future or -- better yet -- maybe we'll be able to add custom XHTML tags to the editor.

While there are other ways to get a WYSIWYG editor for Movable Type, they involve adding a plugin to MT itself. For example, MTEnhancedEntryEditing uses TinyMCE's nifty feature set - but I've found this problematic when using IE (and so have others). It works fine in Firefox however.

If you are an MT user and decide to use Performancing, take note of the following:

• You will be asked for the URL of your MT publishing API. This is not your mt.cgi URL; it is your mt-xmlrpc.cgi file (this is in the same directory as your mt.cgi file).
• You will be asked for your API username and password. The username is your regular MT username but the password is not necessarily your MT password.
  
• To check -- or reset -- your MT API password, log in to your MT account, go to >System Overview > Authors > Your Name, scroll to the bottom of the page and look for the "API Password" field.

Anyway, after writing all that, I still don't know if my Performancing plugin is working! I guess it's time to press the "Publish" button and find out...

Update (5 minutes later): Hmmm... I'm not so sure about Performancing after all. It added a "Powered by Performancing" tag and link to the bottom of my post (which I have just deleted). Is that link going to appear in every post I make with Performancing? That's spam!

I understand that the makers would like something back but, hey, I think a blog post evangelising the plugin (my original intention) and a link back to their site is enough.

Secondly, my paragraphs have become pseudo-paragraphs -- created using double BR tags, not P tags. This looks ugly in source code, but it looks even uglier in my Textile-2 enabled Movable Type interface.

Sorry Performancing, after an exciting start, you now get the thumbs down. Someone's bound to make a better blogging plugin soon.

There are many different types of webmasters but two types I encounter often are:

1. Standards-Obsessed Designers (SODs)
2. Profit-Oriented Webmasters (POWs).

SODs strive for neat, compliant XHTML and best practices in usability and accessibility. Their websites are typically clean, clear and slick.

However, SOD websites can also look cold and generic. Indeed, many so-called "Web 2.0" websites look trendy but soulless.

POWs on the other hand are not concerned about look-and-feel so much as the message they transmit. These are typically bombastic and aggressive - "BEST HOTEL DEALS GUARANTEED", "MAKE $$$ WORKING FROM HOME" etc.

POW-created sites crop up a lot in lucrative areas such as travel. POW travel sites do well in search engine results pages but ultimately look like cheap imitations of market leaders such as Hotels.com or Lastminute.com. (This is because they are all powered by a small number of "white label" booking engines, so they all offer the same "products".)

The worst kind of POW site, from a user perspective, is the "Made for Adsense" site, which lures you in under false pretenses as it were, only to pitch more advertising at you.

That's why authentic websites come as a breath of fresh air on the web. What's an authentic website? Well, if you're an experienced internet user, you'll know one when you see one. But typically they are exhibit the following traits:

• Clearly made with care and passion
• A "homemade" look and feel
• Don't follow latest trends or best practices
• Few if any advertising messages
• Engaging, unique content

As a quick example, Algarve Beach Life is a genuinely authentic site I discovered recently when trying to discover things to see and do in the Algarve, Portugal. The site is designed and maintained by one woman, and is clearly a labour of love.

Now, if only there were a way to tag such a site as "authentic" in Google, not just in deli.cio.us...

Ever used your laptop on the train? You're trying to finish a project; you get sucked in and time flies, when -- aaaaargh -- the battery dies, and you haven't saved your work!

Even if you're not so nerdy, I'm sure you've had a mobile phone conversation that went like this:

"Hi. Listen, this is really important ... no, hold on, this is really important, I have to be really quick because my battery's about to ... hello?! He ... awww shit!"

Both these scenarios could be a thing of the past if the promise of wireless electricity becomes a reality. According to the BBC:

US researchers have outlined a relatively simple system that could deliver power to devices such as laptop computers or MP3 players without wires. The concept exploits century-old physics and could work over distances of many metres, the researchers said.

Sounds great, until you read the next paragraph:

Although the team has not built and tested a system, computer models and mathematics suggest it will work.

Computer models and maths, eh? Why am I unconvinced?

This reminds me of another electricity-related promise made in 1999: Broadband internet delivered through power lines.

I couldn't wait; luckily I didn't. The internet via electricy dream failed, despite its promoters' insistence that "the technology was fundamentally sound".

In their quest for Artificial Intelligence (AI), many computer scientists first aim for a child-like AI with the ability to learn from reading and experience.

As Stanford University Professor of Computer Science Dr. John McCarty puts it:

This idea has been proposed many times, starting in the 1940s. Eventually, it will be made to work. However, AI programs haven't yet reached the level of being able to learn much of what a child learns from physical experience. Nor do present programs understand language well enough to learn much by reading.

But what if computer "minds" could learn a different way? Not by reading but by Googling?

In his lecture All I Really Need to Know I Learned from Google, Oren Etzioni (University of Washington) describes how his research group's AI project uses Google to discover facts about the world.

Called the KnowItAll project, the machine "learns" by searching Google (and, more recently, its own web index) for certain types of phrases, then analysing the results.

For example, let's say KnowItAll wants to find a list of town names in Ireland. It could do this is by searching for the following phrase:
"Irish towns such as"
- and examine the words that follow this phrase, in each of the web pages in which it occurs.

It could also search for "and other Irish towns", and identify the words that come before this phrase.

Repeat this formula with many other useful phrases and you get a list of words that are likely candidates for towns in Ireland. Words that occur with less frequency, or do not occur in all of the lists, are less likely to be town names.

I'm glossing over the details here. The methods and algorithms used for finding and determining facts is much more complicated but, in principle, this is how it works.

What does this mean for the future? Hmmm... Well, within milliseconds, your artificially intelligent friend could find out the answers to each of those tricky Pub Quiz questions. And you wouldn't even have to buy it a beer. Thanks, Google School!

Digg has recently changed its algorithm, making it harder for a story to reach the first page and thereby benefit from the resulting traffic spike.

From a Darwinian perspective, Digg's algorithm update is part of a co-evolutionary spurt whereby Digg is upping the stakes in the evolutionary arms race with Digg "parasites".

Online arms races -- accelerated growth involving mutual adaptation -- occur where individual webmasters benefit financially from a large, successful website or web service. In biological evolution, spurts occur in the co-evolution of parasites and hosts or other mutually dependent organisms. Consider, for example, the recent emergence of superbugs in response to the widespread human use of antibiotics.

The phenomenon of search engine optimisation is another co-evolutionary spurt. Realising the benefit of top 10 rankings, webmasters learned to game search engine algorithms, developing techniques such as stuffing keywords into murky corners of web pages, or writing programs that automatically added backlinks to guestbook pages or blog comments.

Search engines, particularly Google, responded by improving algorithms to filter out pages using such tricks, and by promoting preventative measures among web publishers (e.g. popularising the "nofollow" attribute in blog links). For every response, of course, there is a counter-response, particularly as the stakes get higher: Google and Yahoo depend on profits, while individual webmasters depend financially on their SEO strategies.

Each cat-and-mouse game ratchets up the complexity of the algorithm, and of the gaming strategies.

Another host-parasite symbiosis involving Google takes place with its Adwords/Adsense services. Here, Google battles against click fraud or, more recently, "Adwords Arbitrage" and Made-For-Adsense sites.

But the arms race is not confined to search engines. eBay has developed Bayesian responses to fraud techniques such as shill feedback, of which it identifies two types:

Shill feedback, defensive - Using secondary eBay User IDs or other eBay members to artificially raise the level of your own feedback. Shill feedback, offensive - Using eBay User IDs or other eBay members to leave several negative comments for another user (commonly called feedback bombing).

"This is no different than the offline world -- the bad guys come up with more creative ways of doing things," says Rob Chestnut, vice president of rules, trust and safety at eBay (via eBay Strategies blog).

Speaking of Bayesian methods, let us not forget their most common online uses: to detect email spam, viruses and phishing attempts.

I recently wrote about how spyware and malware authors -- motivated by the lure of financial gain -- are creating more and more sophisticated social engineering techniques, which antivirus companies are struggling to counter.

So who will win these internet arms races? Well, most of them will continue in a prolonged stalemate of increasing complexity. After all, if the "Digg spammers" win, Digg would become useless, and the Digg spammers would have no raison d'être.

I often use the services of freelance web developers, who create documents or templates for projects, which typically I then modify.

I have put a lot of time and effort into selecting great freelancers; each of my suppliers produces excellent, valid HTML or XHTML and CSS. Over time, I have learned to make some key requests up front. When my suppliers apply the following tips, I find it much easier to understand and tinker with their code. I hope you find them useful too:

1. Begin the Document with Last Modified Details

Traditional software development has a developed a complex set of practices and procedures for dealing with version control but web design documents are normally created, revised and shared in a much more casual manner.

I recommend using a short comment at the beginning of each document, noting who last modified it, and when. For example:

/*------------------------------------------------- 
CSS Document for xyz.com
Last Modified by Michael Heraghty on 04 November 06 
---------------------------------------------------*/

This last modified comment is particularly useful in CSS documents, as style sheets get changed more often than individual web pages.

Nevertheless, I like HTML documents to have a last modified comment, though I appreciate that it may not be practical, depending on what editor you use. (With Homesite, it's a snitch. Homesite is my editor of choice for many reasons; its powerful set of "Find and Replace" features among them.)

2. Indent the HTML Code Properly and Consistently

Most web designers worth their salt will nest their HTML, but I reckon that at least 50% of the documents I receive from freelancers aren't properly and consistently indented.

Here is an example of what I consider to be HTML that's not properly indented:

<html>
<head>
<title>Sample document</title>
</head>
<body>
<div id="intro">
	<p>Lorem ipsum dolor sit amet.</p>
	</div>
	<div id="main">
	<ul>
	<li>1st list item</li>
	<li>2nd list item</li>
	</ul>   
	</div>
</body>
</html>

And here's the same HTML, this time with what I consider to be proper indentation:

<html>
	<head>
	<title>Sample document</title>
	</head>
	<body>
		<div id="intro">
		<p> Lorem ipsum dolor sit amet.</p>
		</div>
		<div id="main">
		   <ul>
			   <li>1st list item</li>
			   <li>2nd list item</li>
		   </ul>   
		</div>
	</body>
</html>

I use HTMLTidy, built-in to Homesite, to help with indentation.

Some will argue that the more indentation, the more whitespace and therefore the greater the file size. That's true, but I think the trade-off is worth it. The increase in file size is unlikely to be significant.

3. "Close" div and span Tags Using Comments

Did you notice the comments I added in the previous example?

I hate seeing end-div tags. I have to hunt for the opening div (that can be a real pain where the code hasn't been properly indented, or where divs with the same class occur several times in succession.

To avoid headaches, I request that freelancers put comments right after a closing div or span tag, indicating the name and type of the relevant selector. For example:

<div id="wrapper">
Lorem ipsum dolor sit amet.

	<span class="intro">
	Lorem ipsum dolor sit amet.
	</span>< !-- .intro -->
	
</div>< !-- #wrapper -->

(Note: I had problems displaying comments here, so I had to add a space before the exclamation mark - don't do this in "real" code, or the comment won't be hidden.)

4. Use Breadcrumb-style CSS Selectors

One of the most difficult elements in reverse-engineering someone's code is figuring out where various CSS selectors are used in the HTML document.

I like my designers to get specific, wherever possible, when identifying selectors in documents.

For example, rather than:

.credit{
border: 1px solid #000;
}

I prefer to see:

#footer p.credit{
border: 1px solid #000;
}

Now I know the "credit" class occurs within a paragraph, nested within a footer div. I can "see" the HTML, even though I'm looking at the CSS. I also know that changing the "credit" class will affect the footer of the document, but no-where else.

My CSS editor of choice (Top Style Pro) groups selectors according to inheritances, so that I can see at a glance all the selectors that start with #footer. In other words, I can see all the footer CSS grouped together.

Purists will argue that this breadcrumb-type selector identification isn't efficient, since it adds extra bytes, and it probably isn't true to the "spirit" of CSS either. Again, I would argue that there's a trade-off between being pure and being practical, and you have to strike a balance.

5. Explain Your Hacks

You may have expected that I would want my freelancers to provide many clear comments in XHTML. Truth is, so long as the designer has coded neatly and efficiently, and has had adhered to the tips I've already mentioned, I don't need to see many other comments. At that point, the HTML and CSS documents should be straightforward^*. In fact, commenting the obvious may be irritating.

CSS hacks are different, however. There is a large and still growing zoo of hacks for the various browser bugs. I don't intend to learn all of them, let alone try to keep up with them.

All I need to know is – what does your hack do? Often this simply means what browsers is it hiding from/visible to?

For example:

/* Hides from Firefox all versions/platforms \*/

/* Hides from IE5.x-windows \*/

^*I also like to see clear and detailed comments when the document contains non-native code -- such as PHP, JavaScript, MT or Wordpress tags, etc. But I haven't dealt with this here as I'm concentrating specifically on (X)HTML/CSS.