I had never needed to know what actually happened when the translation crawls through a whole page until this morning, when I discovered that all of my custom meta elements were being stripped out.

The values of these meta elements were important to me because I was using them to determine on a page by page basis the parameters in a querystring for a JSONP service.

For those for whom it’s necessary to store data in meta elements in oft-translated web pages, consider yourselves well warned!

The “unknown runtime error” was at one time a common problem when working with innerHTML in Internet Explorer as for some elements it’s a read-only property. Needless to say, I was a bit surprised to see it this time, especially since I couldn’t spot anything out of the ordinary.

Then I suddenly realised that the source of the problem was probably the dynamically-created HTML5 figure element into which I was asking Highcharts to insert my chart. Rather than mess about with the Highcharts library and a homegrown workaround du jour, I decided to go with a simple div.

As with everything Microsoft, given time things will work out. Updated figure documentation from Microsoft and Caniuse.com confirm that support for HTML5 semantic elements (and therefore read/write innerHTML) should be available in IE9.

I’ve spent much of this week struggling with a Google Mini, a server that plugs into a network, crawls what it’s told to crawl and then returns search results using the vendor’s famous technology.

The Mini had been sitting there in perfect anonymity – as far as being bright yellow allows – on the server rack, looking like a slab of emmental. It’s a cheaper and therefore more limited version of the Enterprise search which I first came across over five years ago while working for Research Machines.

One fine day, someone vaguely remembers the Mini’s existence and I’m asked to “look into it”. Good things rarely come of these three words.

Getting started

I’ve never been keen on Google’s documentation and the bumph that ships with the box is no exception.

The information is properly formatted but it just never seems to get inside my thick skull. In my experience as an information designer, this tends to happen when the writer fails to provide a context. It helps to know the purposes, reasons and consequences of one’s interactions.

I’m not a sys-admin, but I’m not exactly a technology virgin either. Even so, getting to grips with the new vocabulary (“OneBox”, “Host Load Schedule”, “Freshness Tuning”) is a difficult experience.

Background activity

According to the log file, I learn that the Mini has been happily crawling away for the last almost three years already. Perhaps the licence limit has been met.

Could this go some way to explaining the steampowered search speeds I’ve been getting? With 50,000 items of content in the index and me the only user querying them, an enormous recordset of 269 results is rendered in a dizzying 34 seconds!

Front-ends

One of the better aspects of the box admin is the ability to alter the search/results UI. There’s so much bad code in the factory XSLT that this comes as a big relief.

Customised search results

As this autumnal week of long shadows draws to a weary close, I’m left plugging away at what originally promised to be the most interesting aspect of the Mini for me.

OneBox modules are self-written keys to leverage information from other datasources when returning Mini search results. In theory, you can poll another server when users ‘trigger’ the functionality in their search terms. Here’s an example:

1. User submits a search query for who: mike padgett
2. Google Mini checks the query for triggers – keywords or phrases that trigger a OneBox
3. Google Mini runs the search for mike padgett normally and polls the location defined in the OneBox, say, http://myserver/?q=mike+padgett
4. Google Mini processes the results and returns custom-formatted content above the ordinary search results

This offers fantastic opportunities for the “joined-up” organisation. Rather than simply go ahead and dump the output of the crawl matches, we can first offer customised boxes of information. Google already uses many examples of OneBox modules in its own online searches, including geographically aware weather summaries and unit conversion.

I decided to adapt an “internal organisation” example outlined by Google by developing a little box for staff member contact details, triggered by a who keyword similar to that mentioned above.

So far, however, I’ve been unable to get anything working. What I’ve been left with are: a blank search log, no error logging and a mild headache. Watch this (vacant) space…

Epilogue

It’s not easy to say whether the Mini – or indeed big brother Enterprise – has been a success. Of course, the Gartners of this world probably told you that it was the best thing since Sharepoint.

As for the people who actually have to work with the stuff on which management bursts the budget, there are some pretty jaded reviews out there.

Michael Cottam talks of hardware failure, while Justin Deltener’s problems were all software-related.

Finally, I think that Ville Laurikari sums up many of my own frustrations when he says: “It’s like shining a bright light on a big pile of crap. It’s still a pile of crap, but you can see it more clearly.”

This is only a problem, so far as I can see, when you’re using backgrounds on the unfloated element(s), because thr background image or colour will overrun your floated element.

Want to try it? The situation is as follows:

1. Float an element containing either an image or text
2. Continue with unfloated elements so that under normal circumstances they wrap around the floated element
3. Give the wrapped text a background property, such as a background colour or image

The code so far:

/* CSS */
.floated {float: right;}
p {background: #fc0;}
...
<!-- HTML -->
<div class="floated"><img src="/images/tmp.jpg" /></div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit</p>
<p>Class aptent taciti sociosqu ad litora torquent per conubia nostra per inceptos himenaeos</p>

Up to this point everything’s normal:

So far so good. Now add font-style:italic; to the rule for p.

Here’s Firefox, with no surprises:

But here’s Internet Explorer 7:

The only (il)logical answer seems to be the addition of overflow: auto to the rule with the background.

I was clued in by a slightly different issue with the same fix already discovered long ago. Just to remind you once more, this is IE7 only, folks!

Source: Wikimedia Commons

The virtues of @media print have been explained elsewhere, best of all by Eric Meyer in his seminal A List Apart article Going to Print, whose original publish date (May 2002) makes me feel a bit old!

Yet one of the most annoying aspects of developing CSS for print is testing it.

Now I know that testing print CSS doesn’t take a huge slice of our lives, but it annoys the heck out of me. So if you’re a tolerant sort of person who’s happy to rub along with naff workflows, you might find this article and indeed the fact that there’s a whole article on the subject, just a bit finicky.

Thing is, I hate testing print CSS.

Sure, simple markup and layouts only need buffing to a shine to be ready for print, but an increase in complexity or a requirement for absolute fidelity in printed material can lead to ugly scenes round my way.

Print CSS: browser testing !== Print Preview testing

Developers tend temporarily to substitute their screen CSS for their print CSS, run it in the ordinary browser environment, et voilà. Rinse and repeat.

Yet the actual conversion to the printed page can sometimes lead to unexpected results, as can be seen in the image: different browsers, different Print Preview results – even though in the browser there was nothing obviously objectionable.

Print Preview !== a tool for development

Finding fiddly print CSS issues would be a lot easier if testing tweaks was a smoother process. Every change cycle equates to:

1. Refresh the page
2. Invoke Print Preview
3. Review the change
4. Close Print Preview

Testing print CSS as opposed screen CSS appends two additional steps 2 and 4 – invoke Print Preview (Alt + F + V in Windows for both IE and Firefox) and close Print Preview (correspondingly Alt + F4) . Those two simple steps make the business very laborious, even if you can remember those shortcuts.

Slight workflow improvement: an IE-only trick

A dirty little script in IE only takes care of the task of invoking Print Preview, which slightly shortens the workflow. Yes, it’s IE only, but given that it’s usually IE giving me print CSS grief, every little helps:

<script type="text/javascript">
function printpr()
{
var OLECMDID = 7;
var PROMPT = 1;
var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
WebBrowser1.ExecWB(OLECMDID, PROMPT);
WebBrowser1.outerHTML = "";
}
printpr();
</script>

This script automatically invokes IE’s Print Preview. Dump it just before the </body> and save yourself a shortcut! You could also call printpr() from anywhere else, of course. And here’s the source of the original code snippet, which also shows a few other unrelated options such as Save As.

Why can’t we refresh the Print Preview?

All of which finally begs the question, why can’t we simply refresh the Print Preview with an F5 shortcut, just like we have in the browser itself?

Probably because I’m the only person in the world who gets genuinely annoyed by testing print CSS in Print Preview. More fool me, I guess.

Proper font embedding in a browser is long overdue. We’ve had to put up with the same old Arial, Verdana, Georgia, Helvetica, Times New Roman for years.

Now that browsers have to some extent caught up with the rest of us, thanks in no small part to a bit of healthy competition, Typekit has finally answered the call: you’ll soon be able to choose what fonts drive your website.

Everyone’s favourite glue

We’ve had sIFR, we’ve had MIR and we’ve had RIR. We’ve probably had enough.

None of these solutions proved to be ideal, but how often is anything ever ideal on the client side?

Well, let’s take a look at Typekit. At the time of writing, there isn’t too much to go on, but what we do know is this:

1. Typekit’s solution uses (quite a lot of) Javascript
2. The solution ‘downloads’ a font feed from a predetermined location
3. A ‘modern’ browser will interpret CSS @font-face correctly and render the desired fonts

So Typekit is merely following in the footsteps of jQuery, Prototype and other JS libraries. It’s about using Javascript as a sort of web glue to make things fit together. However, this time around it’s not being used to cover up for browser naffness.

Typekit will count on consistent support of modern browsers for the @font-face at-rule. This at-rule has actually been around since the CSS 2.0 specification, though a better, verbose description appears in CSS 3.0. An orthodox implementation of the at-rule looks like this:

@font-face {
font-family: "Mike Old Face";
src: url("http://www.mikepadgett.com/fonts/mikefont.otf")
}
/* The .TTF (true type format) will also be supported, as would *any* URL */


Once the font is “instantiated”, it can then be utilised (in Hemingway’s Fiesta sense of the word) normally:

h3 {
font: normal 120% "Mike Old Face", "Times New Roman", Times, serif;
}

Browser support for @font-face is still a bit patchy but things are picking up fast and now the browser people have discovered the joy of automatic updating, we can expect a fairly rapid uptake.

On the bright side, it’ll mean that designers can make more beautiful websites. The dark side is that many other websites are going to get a lot uglier!

But glue can get sticky

Microsoft tried and failed to get their Embedded Open Type solution accepted by the world at large (there wasn’t much of anything ‘open’ about it, of course). Redmond ended up handing it over the W3C as a feeble proposal for CSS 3.0.

One of the itchier reasons for all the fumbling was the issue of proprietary rights to the fonts themselves. This same issue may well cause problems for Typekit, though this time in the reverse sense.

You see, whilst the Typekit solution is likely to appease and perhaps even create uncharacteristic interest from type foundries (it appears to properly respect intellectual property rights), it might not sit well with many designers and even less with developers.

Here’s why:

The story goes that the Typekit script is going to be pretty hefty. It needs to be to do all the processing it would need to do and how long is that going to take? In addition, the font pattern will then also need to be downloaded (some fonts are marvellously chunky themselves).

Next, the matter of the rights. One of the first things I learned about business is that the real value is in contracts rather than sales, especially when you’re selling other people’s products. So it goes without saying that Typekit needs to be a subscription service.

On the one hand, some orgs would sell their chairman to properly and faithfully reproduce their branding online. How on the other, as one commenter suggested, do you now square it with your client that your design will actually attract an ongoing cost? Could this be another opportunity for Open Source or are the foundries on the edge of the precipice into which the music industry has already fallen?

Here’s a quick introduction to the Rational Unified Process (RUP) – IBM’s software development process framework – and what’s in it for user experience professionals. Comments are welcome and encouraged.

An overview of the RUP is essential reading and you’ll find that elsewhere. Assuming that’s covered, let’s say that the RUP consists of three basic elements:

• Project lifecycle phases [1]
• Software development best practices [2]
• Definition of disciplines [3]

RUP basics

Crudely put, the RUP is simply common sense distilled into a set of principles and practices that form a business process. This common sense is the product of lessons learned over the course of many years’ software development experience, together with a healthy dose of theoretical steering.[4]

Rather than being a prescriptive, fixed software development process, RUP is object-oriented, customisable and modular. Thus to be implemented by an organisation, the RUP must first be designed.

A designed process consists of roles, the tasks these roles do (called “Artifacts”) and how the tasks should be done. These artifacts are informed by disciplines described in the RUP documentation.

RUP concepts familiar to UX professionals

Like many aspects of the most if not all of the disciplines identified by the RUP will already be familiar to most user experience professionals depending on their exposure to the whole development process.

What may be less evident is how their individual roles and highly specialised tasks fit in the scheme of a RUP business.

Of the best practices in the RUP, user experience professionals will recognise iterative development and probably already work iteratively. For example, prototyping and prototype testing are usually iterative processes as is visual design.

Component-based architecture is also analogous to pattern-based design and the Cooper methodology. Like user experience activities, the language of RUP is all about workflow and outcomes.

Finally, most RUP processes are described visually, having been modelled with UML. UX professionals will appreciate this and may find themselves very capable of getting involved with the design of the RUP itself.

How RUP addresses user experience design

User experience is expressly included in the Analysis and Design discipline and embodied in the role of the User Interface Designer, whose tasks are to design and prototype the user interface and whose outcomes are a Navigation Map (something like a taxonomy) and a User Interface Prototype.

Ostensibly however, the User Interface Designer has no prescribed involvement in the development of use cases, software design or testing. His/her role is limited simply to the prototype and design of the user interface.

This role, with its default set of inputs and outputs, might work well enough for simple software that perhaps relies heavily on established patterns (traditional desktop client interfaces, for example) but it seems rather archaic and inflexible among  today’s technologies.

Perceived friction between the RUP and user experience design

In my opinion, the “classic” RUP leaves an absurd amount of risk at the door of just a few individuals: the burden lies particularly heavily on software architects and system analysts.

In practice, the idea of a User Interface Designer à la RUP probably won’t fit so neatly into your organisation. You might for example separate such activities between visual or experience designers and information architects, or prescribe others not mentioned above.

Furthermore the user experience professional’s role has very little connectivity with the wider development process, whilst carte blanche is given to more “senior” figures to totally limit or ignore the influence of user experience on the finished product. There’s a risk therefore that the positive benefits of UX and user-centred design on requirements gathering, architecture and testing tend to go unrecognised.

In this way, the RUP apparently leaves very little room for innovation, not least because it strongly favours predictability over agility. And while much work has been done on this aspect – agile processes are now the subject of a high-profile plugin – newer, evolving UX disciplines such as information architecture do not fit comfortably in the RUP sphere.

At best, this seems uncompetitive, at worst and to acknowledge the horror stories of many user experience professionals, it is unwise.

So just as the RUP demands considerable (and uncommon) breadth and maturity from its architects and analysts, the same is also required from organisations as a whole.

Maturity means among other things not taking the RUP specifications too literally. There is a difference between RUP roles and real jobs. Just because a user experience professional does this or that task in the RUP, it does not follow that the organisation’s expectations of him/her should stop there.

From another angle, if UX professionals have other work to do that requires different skills and experience, it might be difficult to justify these in a narrow RUP implementation. Hence the requirement for maturity in the organisation.

There is an appreciable risk of commoditising and compartmentalising job roles, particularly if the organisation doesn’t already consider UX among the highest priorities. Indeed I have seen something similar done with ITIL transformations: one day the goalkeeper turns up for the match only to discover he’s been moved to centre forward.

Summary: shake well before use

• The RUP is a process library for software development and the technology function at large.
• A sensitive implementation of the RUP has the potential to considerably improve technology projects, functions and processes, as well as the lot of those who work on them.
• User experience professionals are given an expressly defined role and the benefits of their work is recognised and embodied by the RUP.
• The RUP does not however put user-centred design at the heart of its approach to software development and UX professionals should consider carefully how their contribution can be properly recognised in a typical RUP environment.

Notes

1. Consisting of Inception, Elaboration, Construction and Transition. ↑
2. Consisting of Iterative development, Requirements management, Component-based architecture, Visual modelling, Ongoing quality assurance, Change management ↑
3. Consisting of Business modelling, Requirements, Analysis and design, Implementation, Testing, Deployment, Configuration and Change Management, Project management, Environment ↑
4. For more on the history of RUP, see the Wikipedia article on the original, pre-IBM Rational software ↑

The images in this article are all of artworks by M C Escher.

Further reading

• UIDesign.net Editorial (2001) UI RUPture: can Rational Unified Process really facilitate a better experience?
• Phillips and Kemp (2002) In support of user interface design in the rational unified process
• Lif and Göransson (2008) Usability Design: A New Rational Unified Process Discipline

For me, Flash development pretty much dropped off the radar in 2004. Jakob Nielsen famously killed the idea of Flash as the be-all and end-all of websites and suddenly, like the stock market interest in the dotcoms, the buzz had gone.

I wrote about Flash again in 2006 on the occasion of the technology’s tenth birthday, noting at the time that it was thanks to Flash that the online video boom had happened.

Flash design 1.0

Why did everyone stop doing Flash sites?

1. Good design goes to heaven, it is often said, and bad design goes everywhere. Accessibility and usability suffered while the keyframes fizzed by. If you allowed your website to become a puzzle, as Nielsen concluded, users would just go elsewhere.
2. The Internet has always been a fickle sort of business, particularly once the marketers got into it. Flash as a key differentiator eventually and inevitably reached saturation point. There was no longer a wow factor to be had in whizzing keyframes: like the bodykitted Vauxhall Nova, every idiot had one.
3. The future of the Internet was predicated on ‘social’ (and therefore interactive), user-generated content and relationships yet 99.9% of Flash sites were 99.9% read-only.
4. Javascript libraries reignited, then accelerated, the capabilities of the ‘traditional’ XHTML-CSS interface.

A place in the sun

The environment in which Flash finds itself today is rather different. Accessibility, usability and web standards are essential factors. Browsers are generally much improved. Business efficiency and profitability are paramount.

And within that environment Flash still has a place that, when implemented correctly, continues to be unchallenged in terms of relevance and effectiveness. It’s the format of choice for online video and music delivery, it’s still interoperable with excellent XML support and it continues to gain traction in the ever-growing mobile market.

Progressive enhancement and visualisations

Though much maligned as a user experience killer in the bad old days, most developers recognise the benefits of Flash in small doses. Flash was and is incredibly useful for visualisations. The last time I used it heavily, for example, was in the development of a floorplanning tool. I use it more often, however, for graphing numbers and geographical mapping (though GoogleMaps has increasing advantages).

When the metaphor is necessarily visual and the data is dynamic, there isn’t much out there that can match Flash for quick, effective results.

Now with ‘modern’ methods, we can also provide an accessible experience. Any HTML table of data, or an ordered list of countries and their attributes, is a candidate for visualisation and pre-formatted data source. The original data will still be there on the page but a bit of simple DOM work can convert it into something Flash can use.

Faust and the DOM

As with many of these ‘development trends’, we’ve been doing it for years but some smart folks had to put a name to it. In this case, it’s the agency Space150 and they’ve named it after everyone’s favourite devil-dealer Faust.

The idea is to provide content on the page and have Flash use that content via its support for XML. The visualisation is displayed and, typically though not always, the original content is hidden by recourse to Javascript.

So it follows that the content exists without Flash requesting it, which means that it’s accessible and search-engine friendly.

What’s interesting though, is how the developers got around DOM limitations caused by Internet Explorer’s serialisation of HTML rather than XML. Consider the following example:

<ol id="countries">
<li id="cty-1"><a href="#">Algeria</a></li>
<li id="cty-2"><a href="#">Argentina</a></li>
<li id="cty-3"><a href="#">Australia</a></li>
<li id="cty-4"><a href="#">Belarus</a></li>
<li id="cty-5"><a href="#">Brazil</a></li>
<li id="cty-6"><a href="#">Canada</a></li>
<li id="cty-7"><a href="#">Chile</a></li>
</ol>


In Javascript, we ask:

alert(document.getElementById('countries').innerHTML);

or with JQuery if you prefer:

alert($('#countries').html());

Here’s the DOM excerpt from Firefox:

Now note the equivalent excerpt from Internet Explorer:

See how the nodes get capitalised and the @id is stripped of quotes? This isn’t “illegal” behaviour, but it is exceptionally irritating. Passing that IE excerpt as a string to Flash via flashvars is a recipe for trouble.

The developers “sanitise” this DOM output by converting it to XHTML (and therefore well-formed XML) using a (relatively) simple function contained in their innerxhtml.js:

// innerXHTML
// -------------------------------------------------------
// Copyright (c) 2006 space150, LLC and released under the CPL license:
// http://opensource.org/licenses/cpl1.0.php
// -------------------------------------------------------
function innerXHTML(obj, encode) {
   // It is an option to pass innerXHTML() a string indicating an id attribute
   if (typeof obj == "string") {
      obj = document.getElementById(obj)
   }
   var open = '';
   var content = '';
   var close = '';
   var tagname = obj.nodeName.toLowerCase();
   var emptytag = (obj.nodeName.match(/area|base|basefont|br|col|frame|hr|img|input|
      isindex|link|meta|param/i)) ? true : false;

   // Write open tag
   open = '<'+tagname;

   for (var i=0; i<obj.attributes.length; i++) {
      if (obj.attributes[i].specified && obj.attributes[i].value != "null") {
         open += ' '+obj.attributes[i].name.toLowerCase()+'="'
            +obj.attributes[i].value+'"';
      }
   } open += (emptytag) ? ' />' : '>';

   if (!emptytag) {
      // Write tag content
      for (var i=0; i<obj.childNodes.length; i++) {
         var node = obj.childNodes[i];
         if (node.nodeType==3) {
            content += node.data;
         else if (node.nodeType==1) {
            content += innerXHTML(obj.childNodes[i], false);
         else {
            content += " ";
         }
      } // Write closing tag
    close = '</'+tagname+'>';
    }
    // URI encode the content if desired
    return (typeof(encode)=="undefined" || encode==true) ? encodeURIComponent(open+
      content+close) : open+content+close;
}

Et voilà! Beautifully done.

When I’m testing work done with jQuery in Internet Explorer, I’m normally a karmic cow. I wonder if Mr Resig and friends ever thought about their specific contribution to world peace.

Indeed with jQuery, you can almost forget about the bad old days. At least until something comes along like it did this morning, when I hit a situation using .html().

Using .html() to return elements with bound events

If we use jQuery to bind events to an element and then take a look at the DOM, Internet Explorer may well return unexpected results. Here’s the code:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
//<![CDATA[
$(document).ready(function(){
$('#countries li a').click(function(){alert('clicked!');})
alert($('#countries').html());
});
//]]>
</script>
...
<ol id="countries">
<li id="cty-1"><a href="#">Algeria</a></li>
<li id="cty-2"><a href="#">Argentina</a></li>
<li id="cty-3"><a href="#">Australia</a></li>
<li id="cty-4"><a href="#">Belarus</a></li>
<li id="cty-5"><a href="#">Brazil</a></li>
<li id="cty-6"><a href="#">Canada</a></li>
<li id="cty-7"><a href="#">Chile</a></li>
</ol>


Consider the result from Firefox below. Predictable isn’t it?

Now look at Internet Explorer 7 and notice the junk that’s found its way in there:

Results for IE7 + jQuery 1.4

It’s like Sizzle just ate a bag of shell-on peanuts in your taxicab. The behaviour has been described briefly by Matthew Pennell.

It’s only a problem if for some reason you need clean, well-formed XHTML.

Don’t depend on .html() for well-formed XML snippets

For example if – like me – you were using XHTML from the page as a dataset for use in a dynamic Flash object (via progressive enhancement) then that could be a problem: Flash balks at this stuff in IE.

Moral of the story: check your code

My quick fix was to change the order of business. I simply did my jQuery event binding after the data had been sent. A hard lesson learned, then, in view of the amount of time I spent tearing my hair out, but an important one nonetheless.

I attended a seminar last night that represented the Belgian contribution to World Usability Day.

The conference was hosted by interactive agency Emakina and the theme set by the global organisers Usability Professionals Association was Transportation.

The agenda consisted of presentations on traffic congestion, user experience in online airline booking and social networking.

Usability and traffic congestion

The opening presentation from Joannes Vandermeulen, concerning how usability could contribute to the resolution of traffic congestion, was both curious and interesting.

Vandermeulen compared the current, systemic approach to traffic management with the possibilities of adapting Swarm theory, wondering aloud how direct communication between car drivers might resolve jam situations.

The online airline

So far, so good. Next we heard about an Emakina case study in which the latter had presented client Brussels Airlines with what it called a “user experience mission”.

The idea is to method act the process of booking and taking the flight, from website to take-off, so that the user experience can be considered not as an isolated online transaction but rather in the context of a larger process in which users engage with the brand. Hence the trip to Lisbon.

Of course I appreciate the sincerity of the thinking here, yet it does sound nevertheless like a marvellous jolly too – pity I’ve never had an airline industry client (though some orgs would be more preferable than others: could you imagine doing a user experience mission for SkyChefs?).

Feeling unsociable about the social web

After the break, there followed two presentations on the subject of social networking. Unlike Laurent Goffin, who was riffing enthusiastically about the “social web”, I’ve been unable to retain quite the same level of enthusiasm lately.

And here’s why. As far as social networking’s concerned, I’m right in the middle of yet another perennial cycle in which:

• I have embraced change;
• I have seen opportunities;
• I have accepted that it will have implications for my work;
• I have begun to implement it;

All good. But now, two or three years later, the cycle has predictably evolved:

• My clients have now heard a few acronyms and buzzwords;
• My clients can talk of nothing else;
• My clients call me in and tell me that I must embrace this new and exciting change, discover its opportunities, accept that it will have implications for my work and start to implement it;
• My clients insist on a [insert the social network du jour that's très à la mode] presence

Don’t misunderstand me, I love my clients: they do their thing, they pay my bills and they fill my day with endless amusement. But sometimes they behave like kids. This is the result of having baby boomers in senior management.

In a way, you could visualise this cycle in the same way as Joannes Vandermeulen described wave theory in traffic jams. Think of me as the blue car and it makes perfect sense.

Rant over, but what does social networking have to do with transportation?

And finally

There’s always a risk that this type of event, managed by a company, can end up being a glorified advertising campaign for the host. Whilst Emakina made reasonable efforts to avoid this situation, I did find myself wondering about what other contributors – myself included – might have offered, especially since we were told there had been numerous submissions.

Perhaps with a wider range of contributors there might have been more focus on the theme of transportation, in which I was particularly interested after the recent issue of UX. There might also have been some discussion of media other than the Internet.

Fundamentally, what’s most important is that this event – the Belgian edition of the global initiative – continues to grow. This year’s audience was quite impressive and very encouraging. If I’m around next year, the UPA‘s designated theme matches my competences and I hear about it soon enough, then I’ll certainly consider making a submission!