Flash(tm) has a place on the internet, but being used to move the odd bit of text about is definitely not it! Sledgehammer, nut, smash. However, doubtless much to Adobe's glee, the idea that all animations on the web are obliged to use Flash has somehow become deeply ingrained into the public psyche, and more importantly those members of the public who ask us to develop websites for them.

But then along came the iPhone, a device for the near exclusive use of trendy-young-things, awash with plenty of that indispensible disposable income that keeps businesses in business. Now all of a sudden that Flash animation becomes invisible to the very market sector you most want to influence. Is it time perhaps to fall back (yet again) to the tried and trusted technologies that work on all devices?

As a quick example I have created an example here:

But the really interesting thing to note is what happens if you switch the javascript off. It stops moving, but your banner remains:

No nagging message telling you your plug-in is out of date, and that you really ought to spend the next half an hour downloading a 20MB file and getting Wizard Fatigue.

Now, I don't want this to sound like a lecture, but instead I want it to be a message of hope. HTML5 is around the corner, and a whole plethora of new technologies are about to come on-line, such as scalable vector graphics, opengl and so forth. Sorry, did I say new? I mean a whole plethora of technologies we should have had years ago might finally arrive at a browser near you, and what on earth kept them?

What this means is that both the simple javascript animation I show you here and Flash may soon (I mean eventually) be consigned to the dustbin of history, and the tried and trusted technologies will expand to fill their shoes. We can't wait.

Our Zimbra email service is a great alternative to Microsoft Exchange, one of its built-in features being spam/virus protection.

One thing it currently lacks though is a full "quarantine" system, which is rarely a problem, but very occasionally a false positive is triggered by an attempt at sending a file securely falling foul of the "block encrypted archives" option. At this time it's handy to be able to send the mail on its way.

I had to do this today, and here's what I did:

• Find the right mail in /opt/zimbra/data/amavisd/quarantine it will be called something like virus-1BghBzSYKd2E - this can involve finding the time of the original message in the logs and comparing with the timestamp on the virus file. In the unix world "ls -lhrt" is your friend here for listing the virus files in order of arrival. The location could be different on your install.
• Deselect the option to block enrypted archives in Global Settings -> AS/AV (or remove filtering of the particular file type also in the Global Settings as appropriate).
• On the server as user zimbra do "zmamavisdctl restart"
• To send the mail on its way again: sendmail -t -i < virus-1BghBzSYKd2E
• Look in /var/log/mail.log for the mail being sent ok and not still being rejected.
• Reselect the block encrypted archives option so that it operates in future
• On the server as user zimbra do "zmamavisdctl restart" to finally put things back to normal.

Email is a great tool but encrypted zip files are quite weak from a security perspective, so probably a better means of communication for a private file like this is to send by a secure means such as Dropbox or, if sending from Zimbra, to use the Zimbra Briefcase, or to use a more robust form of encryption for the email such as PGP.

Cataract operations and gallbladder extractions might be the most common kinds of surgery on the NHS but our customers prefer a Plone migration. 

Plone.org has an online manual for those who like getting their hands dirty, but it's easy to see why many organisations like specialist help with this task.

Since the arrival of Plone 4 we've been fairly inundated with requests for information on how to upgrade sites (some as old as Plone 1.0.5) to it. Sometimes the older sites are actually simplest and quickest especially if they are sites that were setup for a particular purpose with only a few extra products.

It's fair to say that the addition of a 3rd party product which isn't supported in recent Plones can be the biggest stumbling block to a full migration. Another issue is a lot of bespoke templates, especially if the site's main template has been customised. This means that a lot of functionality may have to be recreated in a Plone 4 kind of way using new templates. These solutions aren't always expensive although some customers may take the opportunity to rethink the overall design and kill two birds with one stone.

Rarely it does happen that it's not feasible to migrate a whole site, and instead it's best to make a new Plone 4 site and try and move over as much content as possible. At this point Dexterity in Plone 4 is a real bonus - it means we can quickly create new content types to match the old ones and then write a script to convert the data from one to the other.

Sometimes there is some particular content that isn't worth the time taken to reproduce and a manual cut/paste is the best solution. However, to date we have succesfully moved at least 95% of any site content when requested and our customers are enjoying all the benefits of Plone 4.

For more details about migrating to Plone 4 please contact us.

No, not the familiar Google product, but the 'ad words' found in brochures, posters, advertisements, and yes, websites: the catchy phrases, slogans and mission statements by which marketeers hope you will remember their brand over all the others. 

They have an important role to play in your overall marketing strategy, but often they are mis-used in your website,  taking up space in html tags that could be better optimised to drive search engine traffic.

Take these examples:

• "20 years of delivery" (in a hypertext link and header tag)
• "Brings people and information together to reduce decision times" (in the description text that appears on a search engine listing)
• "We are committed to the well being of all our customers, partners, employees and the general public." (the first sentence that appears on the home page)

They exude trustworthiness, permanance, and all manner of good things.  In fact, there is nothing wrong with these phrases, except - try to guess what kind of product or service is being offered. 

That's right.  This might be the kind of thing that you want people to think of when thinking about your business, but they are not words or phrases that people use to search for a product or service that they want.  All of the above examples are taking up prime optimisation opportunities, and throwing them away.

So, by all means, use 'ad words', but put them where they won't do any harm.  Right up front, make sure you state who you are and what you offer, and state it more than once.  Use those header tags, the hyperlink texts, and the description fields to their best advantage.

The websites? An oil and gas services company, a consumer electronics company, and a plumber.  All of them are pretty good websites too, but wasted opportunities can creep in anywhere.  Take a good look at your own site and see.

If you would like to improve traffic and Return on Investment (ROI) in your website, contact Openia's Usability Team for an initial consultation.

Back in the good old days, graphics were graphics and text was text. These days even something that looks like a text mode might be using the framebuffer and technically have a graphics resolution.

We encountered this problem recently when recommissioning a server.  To enable remote access should the server encounter a problem many of our servers have a KVM over IP daughterboard which allows console access if all else fails. This particular device also allows a remote user to hook up a local CD ROM or ISO image to allow a remote install to take place.

This was what we attempted recently with Ubuntu 10.4 (LTS). Unfortunately the graphics controller on the KVM daughterboard (in this case a Supermicro M3296) operated fine until the installer booted but then showed a corrupt display claiming to be 648x481 pixels in size. 

So, instead, on one of our datacentre visits, we reinstalled it in the conventional way, however afterwards the screen was still corrupt when viewing using KVM over IP.

The reason for corruption is because of a particular mode used by the linux console. This can be edited in the file

/etc/modprobe.d/blacklist-framebuffer.conf

and inserting

blacklist vga16fb

solves the problem.

I also believe that the kernel options 

vga=normal nomodeset 

should have the same effect during install, but we haven't tested that theory yet.

As often happens in hosting we recently moved some sites from one server to another. In this case a server had gone bang and so we rebuilt everything on a new server running the latest Ubuntu LTS.

Of course, one issue in moving the hosting was that the new server installation didn't come with the same versions of software installed as the old one did. In this case our Zope instance needs Python 2.3 - a fine vintage - but our new Ubuntu installation has Python 2.5 as the lowest available version for install by the package manager.

Thankfully, in the open source world it's easy to build older versions to run pretty much anywhere you want; so in a very short time we had the Zope instance up and running on our homemade Python 2.3 complete with Python Imaging Library (PIL). 

Or so we thought.

After a short while we noticed an issue that thumbnails were not being generated when new images were uploaded. In the log was found: 

File ".../lib/python2.3/site-packages/PIL/ImageFile.py", line 189, in load
d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
File "...lib/python2.3/site-packages/PIL/Image.py", line 385, in _getdecoder
raise IOError("decoder %s not available" % decoder_name)
IOError: decoder jpeg not available

This error suggests that PIL had not been built with libjpeg support, however when building PIL it had output the following:

*** PIL CORE support not installed
*** TKINTER support not installed
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
*** FREETYPE2 support not installed
*** LITTLECMS support not installed

which indicates that libjpeg and zlib were both found during the build. 

After a bit of rebuilding and head scratching the Plone community came to the rescue here:

http://plone.org/documentation/error/ioerror-decoder-jpeg-not-available

In our case we had simply omitted to specify the root of the libjpeg install (for us this is simply /usr because it was installed by the package manager).

So the crucial thing for us was to replace in PIL's setup.py :

JPEG_ROOT = None
ZLIB_ROOT = None

JPEG_ROOT = libinclude("/usr/")
ZLIB_ROOT = libinclude("/usr/")

It's a bit odd that it goes on and builds anyway with this missing but now we know about it we'll be looking out for it next time.

A little over a year ago I blogged on the new phenomenon that was Google Wave. During that year we saw it gain popularity and all manner of extensions, plugins and desktop applications like Waveboard. As a company we used (and still use) it to write collaborative documents. Sadly, though, Wave would never reach its potential before Google decided to pull the plug on it.

On the face of it Wave was an obvious development - we all send messages around the world by various means, email, IM, forum, wiki, blog - so what we needed was a way to tie it all together - wasn't it? Well maybe, but the crucial thing that needed to happen didn't - at least not in time. Wave never saw its tentacles extend fully into the systems that we all know and already use, meaning that you had to convert yourself over to Wave in order to use it.

Another drawback was that there was no way yet (although it was promised for the future) to really use your own Wave server and have it hook into a larger Wave "cloud". That and the overall complexity of the Google interface seems to have resulted in Wave's premature death.

The odd thing now is that out of the ashes of Wave comes, yes, Wave. Google recently announced "Wave-in-a-box" which is ostensibly giving wave to the Open Source community so that in time everyone could host their own Wave server. This could be the best thing that happened to it. The Open Source community already manages development of the world's most popular web server - Apache, the most often recommended browser - Firefox, and provides free alternatives to commercial software in just about every sector.

The Google implementation of Wave was arguably too different and radical, too ahead of its time, but if the Open Source community can build on this basis in a modular way then, in time, Wave could still become the foundation of a new way of sending messages, an all-encompassing, open, distributed system that represents as much of a step forward as email has been over the last 20 or more years.

We were advised by our Certificate Authority of choice (GeoTrust) some while back that they would be switching to new 2048-bit signing. Great, we thought. Now instead of it taking merely the lifetime of the universe to hack a certificate by brute force, it will take the lifetime of the universe squared. Big deal.

What we didn't realised was that in practice that would mean that the next time we renewed a certificate and installed it, the browser (in this case Firefox) wouldn't recognise it, and reports:

This Connection is Untrusted

www.site.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

It worked with every other browser, but what's the point of shelling out for a bona-fide certificate if one of the world's most popular browsers doesn't recognise it? Good question.

We quickly searched for a solution, and discovered that we aren't the first people to whom this has happened. We also discovered, like them, that information from GeoTrust themselves is thin on the ground. We certainly didn't get any warning that something called an Intermediate Certificate might be required. Oh no, we had to work that out for ourselves.

The good news for anyone reading this is that we have discovered a useful page where you can download any Intermediate Certificate you might need. We're quite happy to advertise ssl247.com on this page because they really helped us out. Thanks guys!

Once you have your Intermediate Certificate, put it into a text file on your Apache server (we put it into /etc/apache2/certs and give it the suffix .crt) then add/modify the following directives in the relevant ssl VirtualHost:

  SSLEngine on
  SSLCertificateFile /etc/apache2/certs/site.pem
  SSLCertificateKeyFile /etc/apache2/certs/site.key
  SSLCACertificateFile /etc/apache2/certs/intermediate.crt

Restart Apache and your site's new cert should now be trusted. Problem solved.

Recently we had a case where someone changed the encoding on their Plone site using the portal_properties tool. This resulted in the site being unaccessible, even via the ZMI.

So, for posterity, here's how to recover from a fatal property setting:

1) Stop the instance (bin/instance stop or whatever)

2) Attach a python shell to the instance. There are a number of ways but in recent Zopes that ship with Plone (in this case Plone 3.3.1) the easiest is this:

bin/instance debug

This should run up a few lines and then settle down to a >>> prompt where you can type some python. You're now in a python shell and the ZODB is directly accessible via the "app" object.

3) Start a transaction. The right syntax had me foxed for a while, as it seems to have changed along the way, but the way to do it in recent zopes is like this:

>>> import transaction

It's important to do this before you start fiddling.

4) Make any changes you want. There are a few pages on things you might like to do to delete rogue objects etc, such as these:

http://www.zopelabs.com/cookbook/1054240694
http://wiki.zope.org/zope2/DebuggingWithIPythonAndOtherTips

However these are a bit old and don't help so much in this case as we need to change a property. So we do this:
 

>>> obj= app.unrestrictedTraverse("/Plone/portal_properties")

We can then look at a property like so:

>>> print obj.site_properties.default_charset
ASCII

Aha, so this is wrong. Let's change it:
 

>>> obj.site_properties.default_charset="utf-8"

And see if it's changed:

>>> print obj.site_properties.default_charset
utf-8

5) Very important step - if all went well don't quit the shell at this point, we need to commit like so:

>>> transaction.commit()

[If all didn't go well, then best to quit and not commit. That should leave things as they were before you started.]

6) You can then detach from the python shell with ctrl-d and see if your Plone site now works again.

We live in interesting times as regards fonts in browsers. For a long time the choice has actually been getting narrower as technology has advanced. Certainly with the advent of Linux, and the popularity of all things open-source and Public License, many (if not all) of the world's most famous fonts are now increasingly being left out of Operating Systems and Browser distributions. This is because they are heavily protected and can be used only under license.

In the past Microsoft, Apple, Sun, etc. have licensed fonts for use with their Operating Systems, so no-one else had to. These days however an increasing number of systems (and by 'system' we mean a computer, phone or any other generic computing device with a display) are being created that are entirely license- (and therefore royalty) free.

This is good news for the consumer, but as a website owner it makes it very hard to specify anything. You might want your next website to be in 'Verdana', but if the person visiting your website isn't using an OS that has licensed that font, then their browser will fall back to whatever else they have. There aren't even any sophisticated systems for automatically falling back to the closest alternative. We were therefore rapidly approaching the situation where only two fonts existed: serif and sans-serif. These were literally the only two fonts guaranteed to be on every device.

It is into this situation that several new technologies have emerged that aim to solve this problem, and they are really a breath of fresh air. These solutions are invariably highly technical, not very easy to set-up, and not very reliable either (in our experience so far) but they do work. We shall investigate two of them on this page: sIFR and Cufón, as well as a much simpler alternative just using CSS.

Scalable Inman Flash Replacement (sIFR)

This text has been replaced using Scalable Innman Flash Replacement (sIFR)

This way of replacing text employs Javascript, CSS and Flash, and was the first prominent text-replacement technology to appear on the scene. It is now up to version 3 (in beta, but well worth the risk). Since it requires both Javascript to be enabled and the Flash Plugin to be installed, it will not work for every visitor. However it falls back very gracefully to just display the original text, and is also good for accessibility. Better still is that sIFR Vault offers many funky fonts for free download.

A nice feature is that the replaced text can still be highlighted with a mouse character by character (try it!) should people want to cut and paste it. However, it is not suitable for large sections of text, just for menu items and headings. One huge technical problem we have noticed is that support for transparent background excludes users of Linux. If your website design requires this, which many do, then you will be out of luck.

Cufón

This text has been replaced using Cufón

Cufón aims to be 'a worthy alternative' to sIFR, and manages to do so without any reliance on Flash. That's one fewer Plugin to worry about, and therefore a larger viewing audience for all your hard work. The solution they have dreamt up is stunningly imaginative, but this blog entry aims only to sum-up the differences to the end-user, not dwell on the technical wizardry.

For the end user the text looks the same, but cannot be selected one character at a time as with sIFR. The authors are working on this, we are told, so it sounds like they have a solution in mind. Better still Cufón is fast enough to be used on blocks of text. Most Truetype fonts can be used, but the issue of licensing is still very much a grey area. In using this technology you are revealing everything about the font to the end user. If it turns out you aren't entitled to use the font (highly likely!) then it is possible you could end up facing legal action.

However, from our point of view the biggest problem with Cufón is that it doesn't seem to work all the time. At least not on this page! This is most likely the result of some strange reaction between Cufón and Plone, but it does highlight quite nicely how precarious these new technologies can be. Our advice might be to 'wait and see'.

Good Old CSS

This text has been replaced using CSS

Ultimately, do not let technology be your master. If your requirements are simple, the text doesn't change, you don't need to highlight letters one at a time, and you want a 100% reliable cast-iron solution, just use CSS. From an Accessibility point of view there's no problem (since it is a background image), and you can have high-quality transparency with no compromises. Why seek complication?

In Conclusion

The other technologies are well-worth keeping an eye on, as is the upcoming @font-face, and CSS3. My personal recommendation would be sIFR3, but only for headings and menus, and only without transparency. In any case, it's definitely an exciting time to sit back and spectate, and wonder what might be coming next.

Plone (first released in 2001) is an application that runs on Zope (first released in 1998) and here at Openia we have been developing on Zope and Plone since 1999. We have therefore been in the privileged position of seeing how the two of them have developed in tandem over the years. Developments in Zope, specifically as it has progressed from Zope2 to Zope3, have driven profound changes in the way that Plone works, starting from the very lowest layer.

At times it has been quite a roller-coaster ride as we have had to relearn how we do even the basics every couple of years, often much to our annoyance. Why does software evolve so quickly? More importantly, are newer versions actually any better, or do they just adhere to stricter and more abstract philosophies? After all, if you obey a stricter ruleset, surely the end result must be better? Or is it just harder work for the same end result?

It is against this that we observe newer competitors in the open-source CMS market really coming to the fore. Drupal (first released in 2001) and Joomla (first released in 2005) are foremost amongst these, and they have many things in common. They are both based on PHP/MySQL, and they both place a great emphasis on extensibility via plug-ins or modules, and inspire a huge level of community involvement. Since PHP is the most widely used website scripting language in the world, the number of potential plug-in and module developers is enormous. This huge strength of community involvement will surely wipe Plone from the CMS map of history - or will it?

Whilst developing on Drupal we have been struck by the number of similarities between it and Plone. CCK is just like Archetypes. ImageCache is just like Plone Images. Taxonomy is just like Categories. Views is just like... well, nothing on Earth! The point is that to a certain level of approximation the functionality of the two CMS platforms is converging. True, you actually have to install CCK, ImageCache and Views in order to make Drupal more like Plone, but many people do. It's not just us who regard those three (plus the rather eccentric Views module) to be the 'Fantastic Four' without which Drupal is simply incomplete.

So, to a certain level of approximation it doesn't matter which of the three you choose. That's good news, approximately. However it is worth bearing in mind that one of the greatest weaknesses of PHP as a website scripting language is its complete lack of strictness. It is very hard to write totally secure PHP code, so hard that it is almost a fruitless exercise. The aphorism "I wouldn't start from here if I were you" certainly comes to mind. Why choose PHP to try and write something secure? Choose something else - anything else!

The truth is that it's only a matter of time before some kind of loophole is found in whatever PHP you have written, no matter how carefully you write it. Attacks using extra parameters fed in using POST or GET are on one level, but cross-site scripting (XSS) is on another level entirely. Here I would say that Drupal and Joomla are better off than other open-source projects, due to their high level of community involvement to spot the errors, but even here there are limits. You might think a few attacks are not much to worry about, but you will think very differently when the front page of your website has been defaced by a hacker, and you still can't work out how they're getting in!

Against this Zope is starting to look like quite a sound technology choice. It was designed from the ground up with a totally different concept of security in mind. It does not rely on a filesystem to store information, where that information is vulnerable to being read by any user with sufficient access. Instead it stores all its objects in an Object Database - a single, monolithic and unreadable file to all intents and purposes. We trust Zope implicitly, and do not know of any situation wherein the underlying technology itself has been breached.

It does take more server resources to host this monolithic Zope Instance - it is a real heavyweight application - but the payback comes when your website is handling thousands of hits instead of just hundreds. By that time a Drupal site's underlying PHP technology, even with caching, is starting to struggle, whereas a Zope instance simply keeps on going. So does this mean that Zope is only suitable for medium to large scale enterprises? I would argue that it isn't, and we have plenty of clients who agree. Even to a small enterprise, the cost of any website security problems that occur can be punitive, and completely swamp any considerations over technology choice.

The final question comes down to size of community. Will Plone cease to grow and develop if it has a smaller community than Joomla or Drupal? Does not the larger community always win? Won't Plone simply cease to exist? The answer to all of these questions is 'no'. It doesn't actually take a huge community to run a successful project - just a sufficiently committed community of just the right size to keep on top of things, and that is what Plone has. Plone has shown no signs of running out of steam, or of running out of community. But even that's not the issue. The point is that the world is quite big enough for all of these CMS projects to coexist, and there is no real need to ensure that your website is developed using 'the winner'.

It's a clichéd example, but in the end VHS won out over Betamax, even though it was technologically inferior in every way. So am I saying that Plone is like Betamax, and then advocating that all our clients buy Betamax? Yes I am, because Content Management Systems are not like video-recorders. Betamax video-recorders ceased to be, but Plone is not going anywhere.

Apache comes with a directive to allow administrators to customise the error message for any error, as specified by its number. For example, the error number for a Bad Gateway is 502, therefore the directive:

should change the Bad Gateway message to whatever is specified in the file error502.html.

All would be well, you would think, except for the fact that all of our Plone hosting uses mod_rewrite, which would produce an apache vhost config such as this:

Unfortunately if you try this out you will (rather ironically) get another 502 error message whilst trying to serve the 502 error message:

"Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request."

The reasons for this are rather obvious: the request error502.html is also going to be rewritten, and since nothing under http://192.168.131.85:13080 is going to work (because the Zope instance is down!) this produces another 502.

One workaround is to use an absolute URL in the ErrorDocument directive, e.g.

but we didn't like this because this causes a browser redirect, so the visitor loses the URL they entered into their browser, which is very annoying if you want to keep refreshing to find out when the site comes back up. Also the redirect code is confusing for search engines:

"the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code."

Therefore we wanted a workaround that avoided this. The solution we came up with is to add a RewriteCond to exclude error502.html thus:

in words this means "Rewrite all URLs to the zope instance, unless the URL is error502.html". This now works perfectly. Problem solved. It's odd I haven't seen this solution elsewhere on the web.

Often I'm asked by friends with little knowledge of the world of computers to recommend a laptop or desktop machine for their home use. Although I'm still a fan of Linux, these days I nearly always suggest that they pick the Mac they most like the look of. A long string of questions and answers then ensues. Generally the enquirer's husband/mother/friend/uncle will have suggested some brand of PC running the latest incarnation of Windows, so my suggestion can come as a bit of a shock. Why would someone that appears to know what they're talking about even think about suggesting a computer that doesn't run the the programs that Auntie Betty's machine can?

It's into this world that Google Chrome has burst on the scene. Its tantalising open source goodness means that all us techies are itching to try it out, but does Auntie Betty want to use it? Will she even notice it?

In recent times the "netbook" has become a bit of a breakaway from the general home computing scene - often these things (generally the cheaper ones) are powered by alternative OSes (usually a shade of Linux). Strangely non-windows netbooks do sell, sometimes to ordinary people. When I went into the shop to buy one for my daughter I was summarily informed that I didn't want one of these because it didn't run Windows. When I retorted that this was one of its major selling points, I got a strange look as if to say that I know nothing about these things.

Maybe I do know nothing about what the average person wants. Maybe the ideal world would be one where everyone runs Microsoft and we all share the same viruses, sorry, I mean "binary compatible code". Probably when the ChromeOS netbooks appear the salesman I enountered will still try to push buyers onto a more expensive machine with "better compatibility".

Sadly, for all us geeks out there, this is where marketing can do what years of volunteer effort has failed to do - package up the advantages of open source for the uninformed user and gain market share in the face of a competitor who starts with a huge advantage.

After the launch of Android, Google should have a fair idea whether or not Auntie Betty will be getting a ChromeOS machine next and whether she will like it. I hope for her sake, and everyone else's, that they get it right.

Without desecrating our professional altars by suggesting that we 'dumb-down', I believe that the 'message' needs to be communicated better in both content and in style. I don't just mean straight-talking or randomly using 'cool', 'slick' and 'next-generation' when describing something as potentially life changing as neural computation or nano-technology. But rather stepping back to re-assess what we say (and do) in context of its impact on our immediate professional and social environments before going for world domination!

Clients are people too

Clients are everyday people with everyday problems and mostly basic, sometimes boring, requirements and it is our job to support them without fuss or having to suffer the waffle or sing-along the gospel of Open-Source, Fair Trade or any other belief. And that comes from spending a lot of time listening to our clients, fixing their problems and meeting their expectations.

If psychologists could only communicate with other psychologists, the world would be a very troubled place indeed (yes, even more so than it is already..). Of course, the counter-argument is the devaluation of a profession, such with psychiatry, by the likes of Dr. Phil, Jeremy Kyle and Paul McKenna and this is not what this is about.

We are all trying to do 'the right thing' but I believe that more effort is needed from us as professionals to establish the true value of what we do against the needs of everyday Joe before finding a way of communicating such value in a shared language.

As information technologists, some of us seem to lack the skill to inform... it is not quite as simple as printing a slick brochure or having a Christmas-tree of a website but it is understanding the market well from both the vendor and consumer sides. Before we inform, we need to listen carefully and hopefully offer relevant products and services and communicate such in such a manner that gets the message across.

Just to be clear, I am not advocating that people such as regulargeek.com need to communicate with my mother no matter how they try to phrase statements such as;

"The general idea is that programmers should be writing unit tests using TDD and refactoring as they continue development."....

... but I think she may stand a better chance with our friends at Plone.org who introduce their website by saying,
 

"A powerful, flexible Content Management solution that is easy to install, use and extend, Plone lets non-technical people create and maintain information using only a web browser. Perfect for web sites or intranets, Plone offers superior security without sacrificing extensibility or ease of use."
 

Openia took its name as a leading advocate of Open Source and we did not mince our words and decided to take on a brand that clearly delivers the message.

Beyond the name however, Openia lives and loves Open Source with its values placed at the heart of everything we do. But what about the client? do they have to 'love' what we do too? and why should they? When it matters and if it matters, we will tell clients about the benefits of using a 'Free Public License' and besides the 'free' part, we tell them how their businesses can benefit from all things Open Source including the freedom to design and develop technology that grows with them, the peace of mind that they are supported by continuous improvements delivered by thousands of professional programmers worldwide.

In essence, many professionals enjoy bearing the standard for a variety of concepts or technologies such as Open-Source in the case of Openia. Yet we must always communicate to the market the benefits of joining the march or it may be a lonesome trek.

The basic answer to this is Resizeability. All browsers from the humble IE6 onwards allow the visitor to resize the font, and recent browsers also (attempt to) resize the graphics as well. IE7 is rubbish at this and Firefox 3 is totally superb, as per usual.

However, HTML has never really been very good at coordinating the positioning of resizeable text and (potentially) unresizeble graphics. One place that this crops up over and over again are form buttons. The design has rounded ends and a nice gradient from top to bottom, so how do you make this button resize itself to fit the text?

Answer: The following is a simple technique that works well. The trick is to avoid being overly specific about the height of the button, i.e. let the graphics fade away to transparency at the bottom, and align everything by their top edges. The above button gets cut into 3 pieces:

of which the middle bit will be a repeating background, thereby stretching to any length. Next the HTML:

<span class="roundblackleft" ></span><a class="roundblack" tal:attributes="href string:${here/portal_url}/get-to-know-us" >Get to know us</a><span class="roundblackright" ></span>

Here we have used two empty span elements to hold the left and right ends, and the middle element is just the anchor itself (note that this means that you cannot click on the very ends of the button, but hey).

Now finally the CSS:

The important things to note here are:

• display: inline-block. This allows us to specify a width and height for the span tags, but ensures they still appear inline. Not all ancient browsers support inline-block, but IE6 does.
• vertical-align: top. This is the crucial directive which makes everything line up. Because the anchor is being displayed inline, its height is unpredictable and uncontrollable. Therefore we align it by the top edge, and allow it to become any height it likes.
• If you still have problems with vertical alignment, try applying line-height: normal to the anchor tag. A competing directive can be inherited from CSS elsewhere on the site (especially Plone sites).

This technique only works if the graphics don't have a defined bottom. If they do you can re-do everything aligning with the middle, but this only works with bigger buttons.

The end result:

 Get to know us 

 Get to know us 

 Get to know us 

It's a rare moment at Openia when we stop what we're doing to watch the same video on Youtube, and an 80 minute long one at that. Google's Wave presentation has such an air of occasion about it, that it would seem churlish not to take the time to watch. But is there any substance behind the understated-but-we-know-we're-good Google glitz? There are some pretty powerful applications out there, including many excellent web-based ones, so what exactly is it that makes Google Wave the "killer app" that so many claim it is?

First, it's important to recognise what Wave isn't - it's not one single new idea, it's a bunch of very small, but important, changes to a lot of other ideas which have been brought together. So the first thing we realise is that Wave owes a lot to other technologies. In so doing it stands on the shoulders of giants such as email, blogs, forums, social networking and instant messaging. (Even some of the "new" ideas, such as the ability to watch your correspondent as they are typing the individual letters and words of their message are not that original - "Phone" on VAX/VMS had such a feature back in the 1980s.)

Secondly, although it's a great piece of work, expertly delivered (from what we can tell from the video) it is in many ways completely inevitable. It was only a matter of time before blogs and email and messaging were integrated in some way - it is a technology waiting to happen. That it has happened in one big jump makes it more exciting, but you can rest assured that we would have got there eventually. That said it is reassuring to have Google at the helm at moments like this, rather than some of the alternatives.

But the part which makes this the app which will replace email, IM and many other messaging tools in all our lives is the fact that it is released as a protocol, and an open one at that. So anyone can write their own Google Wave compatible applications and talk to anyone else's. This is what makes Email the current primary choice for messaging - there is no need for everyone to use the same provider. Provider choice is key for planning communications, and Google are big enough to know that they can't be the only provider in the world without poisoning the well for all of us. One has to wonder whether if this technology had been constructed by Microsoft or Apple (for example) that it would have been used as a tool to try to secure market share, rather than making the world a better place for us all.

As a microblog, Wave might only be an incremental change from Twitter, and as a Forum/Social Network it's only a few thought processes removed from Multiply or Facebook, and as an Instant Messenger it might be practically the same as Jabber, MSN or Yahoo; it's the combination of these facets and, more importantly, the openness and ubiquity of them that makes Wave unique, as will be evident when the makers of Twitter, Facebook and others present their offerings in a Wave-like way.

And if this all works out as it should, Wave will become the "glue" of the web.