techblog 

We have just purchased a 40 port Avocent Mergepoint device for remote server console access management. This saves us using up valuable switch ports and separates these devices from the main network which results in a much more secure console access lan. This device can be managed through Avocent’s DSView3 software, but we are currently running it as a standalone device for testing. The DSView software will also manage their ACS console servers, presenting us with a single solution for console access whether they use a network or serial method of console access.

It is basically a switch that can run DHCP on its ports, and (Linux flash based) software to access and configure everything. It all sounded great so we deployed it out into the field for further testing at a site that was running out of switch ports. At under £3k it is probably cheaper than an enterprise level switch to manage these devices. Using it we connected up 21 remote servers and freed up 20 valuable switch ports. It has dual power, redundant network connections and a serial port for when all that fails.

All well and good so far. Next thing was to configure the web interface and create a new SSL certificate signed by our Nominet CA. This is where it all started to go wrong. The manual linked to on the Avocent website is wrong in so many ways. Firstly the web interface is completely different. Our Mergepoint came with firmware version 4, but the manuals (linked to from the product page) seem to be a previous version. I can cope with a different GUI, but the instructions for creating the certificate used the command line - and were wrong. They said to use

openssl req -new -nodes -keyout private.key -out public.csr

but of course you also need a config file, so the command should be

openssl req -new -nodes -keyout private.key -out public.csr -config /path/to/openssl.conf

with openssl.conf containing (for example) this:

[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name     = req_distinguished_name

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = GB

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Oxfordshire

localityName                    = Oxford
localityName_default            = Oxford

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Nominet

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Tech

emailAddress                    = Email Address
emailAddress_default            = example@nominet.org.uk

commonName                      = Common Name (eg, YOUR name)
commonName_default              = MergePointDeviceName

After that you can use the CSR to created a new SSL certificate. The manual says the certificate should go into /etc/httpd/conf/ssl.key (it actually says use the command “cat cert.cert-/etc/httpd/conf/ssl.crt/server.crt” to do this. Does anyone every proof read manuals these days?). This is wrong and the private key and certificate should actually go into /etc/httpd as server.crt and server.key.

Next you should restart apache. Again the manual is wrong and says to use “daemon.sh restart APACHE”. Wrong - that’s the command that you would have used on an ACS console server. The Mergepoint is much more like standard unix here and a simple

/etc/init.d/apache2 restart

or

apachectl restart

is all that is required. All well and good and your new certificate is now in place and working. However, this is a flash based linux so you’ll need to ensure that these new files get saved to flash or they will be lost at the next reboot. There’s the handy manual that tells you to use the saveconf command (correct for once), but it is incorrect in telling you that all files listed in /etc/config_files get backed up. There is no /etc/config_files file (there is one on an ACS console server which is obviously what the manual was based on). The actual file to edit is backup_list.txt. Add these lines to the end:

/etc/openssl.conf
/etc/httpd

Finally if you want to add users to this device and allow ssh access via public key then add /home to the /backup_list.txt file. The users must be added through the web interface as this also updates a database allowing access to the web interface. Then add the users keys, update backup_list.txt and run saveconf. Optionally edit /etc/ssh/sshd_config - we remove root access and password access as we use non-root key based logins only.

I have voiced my concerns about the poor quality manuals to Avocent so that no-one else has to try and reverse engineer things. They originally said that creating a new CSR was impossible, but have since provided a draft of how to do it which was still missing some of the points above (specifically about getting the files saved to flash). A new firmware version is due out in July and hopefully the manuals will be better this time. They still maintain that public key ssh access is impossible without using the DSView software.

It seems I have done something I have been trying to do for years and achieved the impossible.

While working on some simple wireframes for an upcoming development project, I was wondering whether there was much out on the web about button placement and style from a usability perspective.

Apart from information on how people tend to read web pages (in an F shape working from top to bottom, tapering to the left) and Apple’s UI guidelines (seemingly placing the most important button on the right hand side) I couldn’t find much, so thought I would post my thoughts on the matter.

The context: a form (as part of several steps) with three buttons, one that take a user to a previous step (”previous”), one that takes the user to a further step (”next”) and one that cancels out of whatever step process one is in (”cancel”). My examples below are a little contrived, but they do illustrate my thought process.

As styled below in simple form, there is little indication which button is the logical next step at a glance (based on the fact that people usually don’t read things when looking at a page). Some obvious initial problems are the buttons are too close together, and the cancel button really is a different action when compared with the other two buttons.

By moving the cancel button to the right things become a little clearer. Some people use angled brackets on buttons to indicate direction of flow, which can help visually, as people interpret symbols more intuitively than words.

This still causes more problems, as not only is the most important button in the middle, but the semantic meaning of the button is not clear. “Next” and “previous” what exactly?

Looking at the most common usage on the web (paging through search results) “next” really indicates that the user is expecting more of what is displayed currently on the page, especially when used along with “previous”.

Changing the button labels to something more meaningful like “go back” and “continue to next step” make thing a little clearer.

But based on the idea that people read a web page in an F, the buttons are still in the wrong position, as the button that comes into view first is the go back, which isn’t the most important.

If we reverse these to make the most important button first (continue to next step), we are then faced with the problem of both arrows diverting attention to the space between the buttons.

These angle brackets are most often used when paginating through similar records, but in this instance they are being used to indicate what is the next step going forward. If we replace the angle brackets with a different visual indicator, such as more emphasis on the primary button, we solve this problem.

Another benefit of putting the primary button first is that if the user hits the enter button with focus within an input box on a multi-button form, often browsers will submit the first button they come across.

Words like “next” and “previous” can be used when paginating through records along with angle brackets, but are sometimes not totally appropriate when used in other contexts.

I realise the examples above are all purposefully simplistic, and within the context of a step within several steps. On most forms on the web things are a lot simpler, so often just a single button is used, and labels like “submit” are perfectly meaningful and suitable. It’s all about considering the context.

So although buttons seem a minor detail within the greater context of a web page, taking button style and labelling into consideration is important, especially on forms with multiple buttons. By using suitable and more semantically correct labels, good visual indicators, and considering meaning within an overall context, one can much improve the usability of a form.

It is rare that the OSX interaction designers get it wrong, but this is one of those cases and it is a whopper.

We have an HP DesignJet 120nr in the office, basically a big (A0) printer, networked up for us to share.  I’d only ever used it from a Windows box before but I needed to set it up on OSX.  My first step was to open System Preferences then Print and Fax and press the + to add a new printer.  Then I selected LPD printing and typed in the queue name, which it duly recognised as a valid queue.

However it did not auto-detect the printer type and decided it was a Generic Postscript Printer.  So I dropped down the list of drivers, found HP on the list, but I could not see the DesignJet 120nr on that list.

This seemed pretty obvious to fix, just install the drivers.  I downloaded those after a bit of hassle because HP make you register to get them (so old-fashioned) and installed them.  But still the printer did not appear in the list.

I then spent ages looking at files like hpdjPM.plugin and trying to work out how it all fitted together but got nowhere.  I could clearly see from the installer log that the right driver was installed in :Libary:Printers:hp:deskjet:hpdjPM.plugin:Contents:Resources:XMLData:Printers:designjet_120nr.xml but it would not appear in that list.  I tried fixing disk permissions, which found a lot of errors around there but that still did not work.

Finally I spotted a clue on the web that gave me an idea as to how it works.

I went to the same screen but instead of filling anything in, just pressed the ‘More Printers …’ button.  Then I selected ‘HP IP Printing’ from the drop down at the top.  The screen then has two tabs, Auto and Manual.  Auto was blank so I guess that uses a local subnet broadcast and Manual asks for an IP address.  After all this fiddle using dig to get the printer’s IP address is trivial but still something I should not have to do.  Anyway I did that, entered the IP address and pressed Add.  After a several second delay it flipped back to the printer screen with my new printer correctly identified as a DesignJet 120nr and even had the right icon.

What a fuss.

Following up on Jay’s posting on the unexplained symbols on Mac keyboards, I was also initially rather confused when I first started using a Mac 18 months ago. What was even stranger was that books such as David Pogue’s Mac OS X - The Missing Manual didn’t explain either. Surely one of the first things you need to tell a newcomer to Mac OS X is that when someone talks about the ‘Command’ button they mean that one with the cloverleaf pattern on it?

Anyway, after that someone else (I think it was jad) emailed round a link to the Mac OS X keyboard by Matias. This has text on almost every button, but even they think that the cloverleaf button is self-explanatory…. Sigh.

The apple keyboard has some keys on it with only symbols, no words. Unfortunately to me these symbols are completely meaningless and so it has taken me ages to understand what those keys really do.

Even worse, Apple keyboards are completely inconsistent.  For example on the MacBookPro keyboard it says ‘home’, ‘end’ and ‘page’, but on the normal standalone keyboard it used the symbols ↖, ↘, ⇞, ⇟ without any words. On some keyboards the word ‘option’ is used and in some case the symbol ⌥.

Unfortunately Apple uses these symbols in several places, such as the preferences pane where you control key combinations used for common tasks. This means that setting and using those combinations is trivial if the keyboard has them on the keys, but not otherwise. For example the following symbol ⌫, appears on the Finder menu as one of the keys used to ‘empty trash’, but it is nowhere to be found on any of my Apple keyboards. I’ll take a guess it is a backspace key.

It also means that you never learn what other functionality you might be affecting since you don’t know how those keys are used. This side-effect learning is normally quite important.

The final problem I had is that there is a key on the apple keyboard with just the  symbol and the command symbol ⌘. Now I know what the command bit does, but do I have a clue what the Apple symbol is on there for? No chance.

Buried away on the Apple web site, I did manage to find a symbols document which explains most of the symbols, but not all.

The other useful thing that I discovered when trying to work all this out is what Unicode characters can be used to represent these symbols. They may not be the exact ones that Apple use but they seem close enough. So, to finish off, here is a helpful reference that combines the Apple document above with the Unicode code points.

I can’t find the Unicode characters for the Apple tab key symbol with the sloping line, but then that only appears on one of my keyboards, on the others the line is vertical. Sigh.

Update: I just came across this earlier article, from an unusual source that sheds some light on the keys I don’t understand. But not much.

Acronyms (and abbreviations for that matter) within a website, according to the Accessibility Guidelines, have to be explained at least once (usually at the first occurrence, and usually via a title, long description, alt or other tool-tip). This is good practice and very helpful. Ironic then, that the three organisation’s websites that contribute to Euroaccessibility.org don’t actually do this. Take Ability Net, whose homepage statement reads

‘AbilityNet helps disabled adults and children use computers and the internet by adapting and adjusting their ICT.’

Well of course they do. But what is an ICT? It’s not explained on their homepage.

It’s not under ‘About us’ either. Search the site and you get a news link to “AbilityNet joins ICT Consortium to support the voluntary and community sector”. So will the article tell you what an ICT is? No, it won’t. But it does mention (and link to) the ‘ICT Consortium’ site. Surely that will tell you? Going to the ICT Organisation site states, heplfully, ‘ICT Hub: Delivering ICT Resources for the Voluntary and Community Sector’. Followed by the homepage text which reads ‘Welcome! It’s been a busy time at the ICT Hub. Staff have been in post since January and amongst other things are organising a series of seminars and conferences around the country.’. No luck so far. But they do have an About page - at last the place where ICT is defined? On the ICT’s own site ‘About Us’ page?

But you’d be wrong. In fact nowhere in the ICT site is ‘ICT’ actually defined. Even though it’s mentioned in practically every sentence, link or heading.

Unfortunately the same goes for the RNIB and RNID sites. Whilst I’m aware of what they stand for, others might not. In fact, RNID’s acronym does not stand for their full name. At least on these sites, if you dig deep enough (RNID>Home>About Us>History, mid way down) you can find it.

Maybe AbilityNet, RNIB and RNID are all relying on Google to explain themselves?

Euroaccessibility.org is a consortium of european organisations that has been around for a good few years now. The members are most of europe, with the UK’s individual contributors being Ability Net (www.abilitynet.org.uk), RNIB (www.rnib.org.uk), and RNID (www.rnid.org.uk. Their objectives are (taken from their website):

• Avoid the risks of fragmentation of the WAI outcomes
• Develop testing methodology based on the W3C/WAI Web Content Accessibility Guidelines
• Set up a common certification methodology of Web sites
• Create an Accessibility Quality Mark based on common rules
• Establish a certification authority for Web Accessibility
• Set up a European network of regional consulting desks
• Develop an harmonised set of supporting services over Europe
• Disseminate best practices in accessibility evaluation
• Significantly increase the number of accessible Web sites

The important one I believe is ‘Set up a common certification methodology of Web sites‘.
This is obviously going to set (at last) a common framework for developers of online content to work to. But should that be ‘european developers of online content’? Is europe going to lead the way? Doesn’t North America have some strong views on developing for accessibility? Will non-european developers just do their own thing?

The consortium is working with W3C, so hopefully this is just a case of someone taking a lead in the absence of any standard.

As part of our goals to make our web content as accessible as possible, we looked at (amongst other functions) the use of access keys. There are actually many differing views on the use of this capability, with divisions appearing to take on a geographic dimension. To summarise, there now appears to be a distinct North American versus European standpoint on the subject, centering on the availability or choice of available keys.

What are access keys?

Access keys are author or user-defined keys that are assigned to textual hyperlinks or specific HTML
elements (such as <input>) within a webpage. In short, a hyperlink or HTML element may have a letter or number associated with it, which when used (usually in combination with keys such as Alt or equivalent) targets that link, thus removing the need to use a mouse to navigate or (for example) select a particular field.

The access key attribute, introduced in HTML 4.0, can be written as <a xhref=”somewhere.htm” accesskey=”L”>Link Text</a>

Are access keys standardised?

Access keys are advocated by W3C’s WAI (Web Accessibility Initiative). A broad example of websites that use, or at least encourage their use, include (in no particular order):

• Most but not all UK government sites (e.g. cabinetoffice.gov.uk)
• scottish.parliament.uk
• Other international government sites.
• bbc.co.uk
• sitepoint.com (developer/accessibility resource site)
• alistapart.com (well known CSS discussion site)

However, there are many differing views on accessibility, mostly aired on various forums or CSS discussion sites. A sample of sites that do not advocate use of access keys appears below:

• nomensa.com (http://www.nomensa.com/resources/articles/accessibility-articles/access-keys.html)
• accessifyforum.com (for and against, see website)
• wats.ca, Web accessibility consulting firm (http://www.wats.ca/show.php?contentid=32)

The benefit of using access keys in my view is that it makes it easy for some people to use and navigate websites if they are unable to use a mouse, solely need to use a keyboard for whatever reason, or are for example using a screen reader. Bearing this in mind, and although they are part of the Web Accessibility Initiative defined by the W3C, it seems it is no guarantee of takeup by the developer community.

What are the issues surrounding use of access keys?

The current situation regarding take up and use of an approved system is actually fairly complex. Fo  starters, there is no approved system of which, or what, access keys to use. The list below identifies some basic issues:

1. Not every browser or version supports access keys. In addition, behaviour differs from browser to browser; IE in later versions requires use of the Enter key after using an Alt key. However, since access keys are primarily aimed at users who would in all likelihood use a screen reader, non-compatibility of some browsers (Netscape Navigator, IE4) in this respect is not a major issue.
2. Some screen readers already make use of access key combinations; these will be overridden by those defined in a web page, negating the user’s preferential Alt keys (such as ‘D’ for accessing the address bar in a browser). The worst keys to use according to some are D, E, F, and H, as these are commonly used for other functions. See http://www.wats.ca/show.php?contentid=43 for more information.There is no standard set of key definitions, and therefore every web site has their own configuration. A more standard method would be to employ numbers instead of letters (this method is used by government and the BBC) to define commonly used functions – skip to main content, search, site map and home, for example.
3. Making users aware that access keys are available requires a visual clue for the links themselves (usually underlining or emboldening), as well as, or instead of, a page of content providing information on their use. This is not a serious problem, but can impinge on content layout or presentation).

As a region, North America uses two main screen readers (namely JAWS and IBM’s HomePageReader) that come with their own access keys already defined. These two applications hav  a fairly international user base however, and so most screen reader users in other parts of the world are also likely to be using this software.

Accessibility advocates based in North America have taken a position of championing these two applications and the access keys they use, and support a move to deprecate or simply not use the W3C defined XHTML accesskey attribute as it can override the access keys defined by these top two screen readers. This alternative position also advocates replacing the XHTML attribute instead with similar elements (see http://www.wats.ca/show.php?contentid=47)

Some accessibility groups have additionally persuaded the Canadian government to drop their implementation of access keys on their websites. The approach the Canadian government took originally was the same as the UK government; namely using a series of numerals (1-6) to provide specific functionality for common tasks. With British and possibly European developers now looking to the UK government’s implementation (rightly or wrongly) as a standard (the BBC implements this approach as well), there is now a real conflict of perceived ’standards’.

W3C have also written a new attribute (“@key”) into the draft XHTML 2.0 specification, again much to the annoyance of the North American accessibility groups who see it as the same as the previous “accesskey” attribute mentioned above albeit under a different guise. Developers of the Firefox browser have also written a plug-in for the JAWS screen-reader (which previously was not compatible with Firefox) that pre-defines the access key numerals 1-6, which would also conflict with a ’standardised’ UK implementation of using numerals for common functions.

Based on the above divisions in the developer and user community, there is a a marked division on how to proceed with any standard regarding access keys. In fact it seems that there is no broad agreement as to what that standard might be; hopefully one will emerge sooner rather than later.

The ‘cruel joke’ in the title came from one of the IE7 beta feedback entries, in which the contributor summed up the beta release perfectly. Despite being factual and informative, the post was removed by the IE7 blog moderators.

What it’s not

Microsoft are currently trialling their beta release of the next version of Internet Explorer, IE7. For developers and users of CSS, this was meant to be something of a watershed - we all expected something special (if not simply plain useful). IE7 however, is somewhat of a cruel joke for many reasons - CSS issues being just one them.

IE7 was meant to be standards compatible, at least compared to IE6 (not hard) and at least in the eyes of developers. Astonishingly, however, the IE7 beta simply corrects the
basic bugs and mistakes that existed in the product first time round. Most other browsers fixed these problems as they went along, years ago, and are now reasonably up-to-date with W3C standards. For a list of these bugs. errors, and broken implementations of standards in Internet Explorer, see http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx or http://www.positioniseverything.net/articles/ie7-dehacker.html.

So instead of any *new* levels of CSS support (bug fixes that should have been patched years ago not withstanding), you now get….nothing!

That’s right, zero *new* levels of CSS support. Not even support for min-width/max width
min-height/max-height which other browsers have been supporting for years and years and
years. The min/max css rules are especially important. Since the advent of ‘table-less’ design
(just a tad important), the ability to control a layout by use of CSS has been absolutely essential - content layouts have needed to cater for increasingly dynamic content, in fact the entire structure of a site’s layout has needed to become very flexible indeed, and not simply for accessibility reasons.

This is achieved at the moment via CSS 2.0/2.1 with a reasonable amount of trouble (let’s face it, quite a bit), by use of the min/max rules amongst others - allowing areas to be controlled
dynamically. Internet Explorer however simply throws a spanner in the works by not supporting the min/max rules whatsoever. Designers have been crying out for this to be supported in future releases of IE for years and years, being extremly vocal - so you would think that a major new release of the browser would take this into account. In fact, there are so many other non-implementations of standards in IE7 that it is impossible to list them all here.

More bugs and incompatibilities…

So why haven’t Microsoft at least implemented the min/max rules (something that FireFox did from the beginning) in the beta release? Originally I read that it was “too difficult, would require too much code re-working at this late stage”. Which of course beggars belief. Over a year in to the beta release they are however now stating that they “are working on it” - however I’ll believe that when I see it.

Another dissapointment - IE7 beta introduces more bugs that IE6 does not have - and these are *new* bugs, not issues caused by hacked IE6 styles not working in the ‘now fixed’ version of IE7. For a list of these new issues see the beta feedback entries at http://blogs.msdn.com/ie/archive/2006/01/31/520817.aspx.

A far more serious issue than the above is the fact that all the websites out there that use hacked or bespoke CSS to correct IE6’s failings will now no longer work in IE7 - as the IE7 team have deliberately fixed the support issues in a certain way - ironically in order to ‘minimise disruption’.

nb. A useful quote from Microsoft: “We fully recognize that IE is behind the game today in CSS support.” Stated only this year.

Microsoft’s IE7 Blog site

MSDN’s random blog site for IE7 (nb. impossible to navigate or get anything like a homepage with logical links)

• http://blogs.msdn.com/ie/archive/2006/01/31/520883.aspx#522483.

Further reading on Microsoft and IE7’s “CSS support” (ha ha ha ha!) :

• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ietechcol/cols/dnexpie/ie7_css_compat.asp
• http://blogs.msdn.com/ie/archive/2006/02/02/523679.aspx