IETPs

History

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.

Today

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.