Monday, March 14, 2016

Updating the End User

Updating our Users

Over the years it has become increasingly noticeable that our end users just don't get to know the capabilities of our software. In many cases they have been creating and editing S1000D Data Modules for years and don't know that there are features which would greatly speed up their production and possibly increase the accuracy and convenience of their task.

Of course we provide a comprehensive User Guide which includes instructions for not only what the software does but how to use some of the Data Module types.

If, as is the case for a large number of our users, they are familiar with our products, they just don't know what has been added. It is often the case that unless they are reporting an unrelated problem and we have a conversation with them to find out how they are finding our application that they hear about feature updates.

Let’s be honest about this, most authors are being pushed to up their output and do not have time to look at the user guide. I must admit that my wife is often nagging me to change my general view of “if all else fails read the handbook”. There is often the case, particularly for one of our productivity features, the person who installed the software has not ticked the box to make it available to the user.

Perhaps I need to mention that a lot of the new features that we introduce have been suggested by our end users. We are always grateful for feedback. Our score for Customer Support in our annual survey always scores very high so we do that bit right but of course we try to improve on our performance whenever we can.

How do we grab their attention

Of course we send out emails and letters to the ‘registered’ contact in a company saying what the new release contains. In most companies that gets passed on directly to the IT department for them to download the installer and update each client machine. It is generally obvious that the recipient of the communications does not pass that on to the actual users.

IT Departments generally do not look at the installation instructions which are, in our case, included in the zip file containing the Installer. Why should they, they know all about installing software don’t they? (Sorry about the slightly sarcastic comment here!).

Software updates are not quite the same as equipment updates are they? Hardware updates are discovered when the technician has to use the handbook to fix a piece of equipment. For software the user is unlikely to see signs of an extra feature unless they are observant and notice an extra Menu option.

Help extra to the User Guide

We realise that the old adage of a picture is worth a thousand words is true. Our take on this is to make short videos available on line to demonstrate the, what were once, extra features. We keep on adding to this resource.

But how does the end user get to know about these videos? This is the same problem as finding out about the updated features isn't it?

Of course these videos may be unavailable for numbers of our users. They are sitting on a network which is very secure and has absolutely no access to the Internet. So:
  • Should we make these available as part of the Installer?
  • And if they are part of the installer should their installation be a choice?
  • In which case we are back to the earlier problem of what the IT Department actually installs aren’t we?

Other peoples experiences

Given that this problem must be pretty universal it would be good to know what others think.

It would be particularly good to know how end-users think that this problem can be solved.

Of course there is the old saying “you can lead a horse to water but you may not be able to get it to drink” but shall we put this problem on one side?

There does need to be a really good way to get through to the end user.

An experiment

We are about to undertake a small experiment to see if we can break the circle of not updating the end user. It looks good on paper. Only time will tell.

If it works I’ll let you know.

Thursday, October 01, 2015



Many years ago I was involved in the design, implementation and population of a keyboard-less maintenance handbook system for a well known UK Train Manufacturer's product associated with a new set of underground trains. There were three multi-machine networked systems in different locations. Touch screens were used as the method of interacting with the handbook (a keyboard was available at one machine on each network). A table of contents (although available) was not used because navigation was entirely graphical which enabled the user to drill down to the location of the equipment to be viewed. It was quick, completely non-computer literate staff could find the knowledge that they required within seconds.

We used a very crude markup system (it was pre SGML) to populate the knowledge side of the system and cross referencing was automatically populated due to mark up in the text. Hotspots on graphics was via a proprietary graphical handling system. We had a numbering system based on the equipment breakdown so in someways it was following the ATA/S1000D principles.

The original front end concept was developed on an early Macintosh computer (large screen) which then was streets ahead of anything on the PC platforms. (Unix was discounted even though it provided a brilliant interface on various counts.) But Macintosh was not possible by the terms of the contract so that triggered a considerable search for an supplier of software that could handle graphics half-way decently.

That was then, using a DOS operating system if you remember that. (Graphics was the big thing then because then you didn't do pictures did you?) . Years later I met someone who was involved in the project from the clients point of view and he mentioned that he had not up to that point (well over 10 years later) seen anything like that system. I must admit that I have not seen anyone pushing the concept of graphical access to data - although I have heard that there are some around. A graphic front end is still not a matter of course. At each level in the graphical drill down access via screen based buttons was provided to descriptive, maintenance, ipc and fault information which made the graphical user interface even more useful and functional.

Later I was involved in an IETP project that was implemented to handle early S1000D data for the UK MoD which complied with Def Stan 00-60. This followed the S1000D arrangement which was advanced for those days.


This wallowing through History sparked a discussion about how much (or how little) IETPs have progressed. Not having recently been involved in providing IETP for S1000D I thought that I had better have a quick look at what the 'Book' says about it. I remember when the specification first introduced the concept of IETP and the 'working area' and it does not appear to have changed much since it was first introduced. Chapter 6.3 of the specification provides the details of this area of information delivery.

There was a feeling that the S1000D specification was now very dated and that modern technology is capable of so much more. Modern tablets and even mobile phones provide facilities undreamed of when the specification was first written. For example:
  • should we design the IETP functionality to accommodate touch screens given the increasing availability of these input methods on laptops?
  • what about connecting to a network via wifi? I know that there is a security issue with some defence documentation but there are secure communication interfaces available to handle this - or is even this a problem?
    • as a corollary to this how many handbooks are in a civilian environment where security (information wise) is a problem?
  • how many changes should we make to the interface? Some of the S1000D areas have been overtaken by technology.
  • should we allow he individual user to move bits of the interface around the display area (the concept of movable widgets - or pods in Adobe terms).
  • how important is it to provide local notes? In the paper days engineers always made copious margin notes.
  • and what about feeding these local notes back to the authoring team?
  • I know that there are issues about printing off information (there are places where computers are not allowed for safety reasons|) but should this be allowed to stop outdated information persisting?
These are all possible now, er actually not just possible be ridiculously easy to implement.

The future

The MD of a previous company that I worked for had a pretty good abbreviation: WIBNI (Wouldn't It Be Nice If). He used this to get a discussion going about what should we be looking at 6 months, 12 months, 2 years hence. This simple phrase sparked very interesting discussions.

Given that all the above is possible I suppose we have to ask what should we be looking at to provide IETPs for the future. A genuine WIBNI. But should the WIBNI take into account the desirability of some of the features. Of course the design of the IETP UI originally was in the hands of a committee with very little reference to the end user. This begs the question whether or not the UI that they designed actually suited the end user.

So in the sense of genuine interest and some sort of general discussion
  1. what do you think that the UI should be like?
  2. should we give the end user the ability to move the various parts of the UI around to suit him/her?
  3. should the entry system to the IETP be Graphical?
  4. should the end user be able to enter his own notes which remain un-moderated (always possible that the note is not factually correct)?
  5. the above are just three simple questions (although I do realise that some are contentious), what else should be put into the mix when considering IETPs and their UI.
It will be interesting to see if there are any responses to these questions or any further comments and suggestions. Please don't be shy in coming forward.