NB: this file is still under construction. The first few sections are
all that has been produced so far. If you feel like producing one of the
sections that are incomplete from the list at the bottom of this document,
then send an html doc to the mebmaster for inclusion (after appraisal)
Introduction
This document is the basis of a use case analysis of the JEDI system. The sections of this document each cover a different aspect of the way that a user might interact with (i) the JEDI system, (ii) with programs in the JEDI system and (iii) with other users logged onto the system at the same time. When this document is finished the requirements specification process should be more informed about the features that are absolute musts and those that are graphical candy.
The primary requirement of any environment that is to be used by “power users”, (which is what developers are) is that it must be slick. Psychologically, there are many other requirements for a system to be usable by humans such as frame rate, perspective, understandability, learnability etc. Being a developer I assume certain things about the users that may be unfounded, but in my experience are probably true. For example, most programmers are great readers of science fiction. Many of them have read the seminal classics such as Gibson’s Neuromancer. Although such works are not requirements specifications for a VR development system, they have defined what a system could be like with good HCI. More than that, the Cyberspace described by Gibson has a visceral thrill which, if exploited, could convert the JEDI system into a Killer App overnight.
Therefore one shouldn’t ignore Graphical Candy and sound effects in the requirement spec. It could make all of the difference between success and failure. There is a basic set of features that the system should provide. They are independent of the graphical display system (JDM), and are related to the program manipulation, representation and execution. However, such features, although revolutionary, wouldn’t fill people with enthusiasm.
To grab people by the balls you need presence. To do that with software developers you need the feel of the future or gadget appeal. That’s where the Cyberspace metaphor comes in. The ability to completely embed yourself within the abstract environment of the JEDI system, rather than manipulating it from the outside as in conventional IDEs, would make the programming process not just fun but desirable. If objects glided around the screen with a life of their own you would get a feeling of the system being full of power. If there were perspective and unlimited space, then there would be a feeling of unlimited possibilities. If the user were given complete power over the system, they would want to experience god-like power more often. If when the user performed some action, the action were attended by some soft power music (as in a sword and sorcery film – tasteful and sub-vocal) then the system would become embued with a sense of magic.
If at the same time as making using JEDI fun, we can make it addictive we also have a distinct advantage over the competition. If the end results of JEDI development are also more robust, then the combination is users that are driven and who in the process of their all night hacking sessions produce good code, the software industry will benefit as well as the clients who invest in JEDI.
So, should the requirements specification for the system include the specification of the right combination of look and feel to make the system a Killer App? I think so. And that explains the reason why I dwell within this document on what the system will feel like to use as well as how it will be used. I shall describe how I want to feel about using the JEDI system.
This story is based upon the design of a program for controlling a microscope and camera to produce an Image Acquisition System. The only reason that this particular example is being used is that I am about to start work on just such a system. Moreover, I have a tight deadline and a loose specification of what I am to do. I am to work with other code from developers in my company that has not been designed nor written with reuse in mind. For the majority of the reuse code, this will be the first time that the code has been reused outside of its original application. Therefore there is additional work to be done in adapting the code to the needs of my design as it unfolds. This project is a real world example of how life for me would be easier if my company made use of JEDI rather than an industry-standard Windows based C++ IDE. The story starts just after the first meeting in which my task is explained to me. “You are to produce an image scanning system that performs time series, montage scanning and serial slide scanning, and you have three weeks to do it in, this tape will self-destruct in 20 seconds.”
Starting the Program Up
I have just come out of a rather boring meeting in which it was explained to me that I have three weeks in which to design, implement and test a new system in my company’s suite of image management tools 3DFI. There has been some talk for a while about producing this application, and I am pleased to get the job. The trouble is, the spec is a bit loose so a lot of the program I’ll have to design myself. Still, now that we have JEDI and I have a quiet office, it should be a breeze.
I return to the office, in which I work, and make myself a cup of coffee. I’m already deep in thought about how I’m going to create the system. I have some ideas, but right now that’s all they are, and I’ll have to start producing a good design right away. Normally, I would shut myself away for a day or two with a new pad of paper and a new pen and start to scribble furiously. Some of the design tools that we used before we got JEDI were OK but they only went so far. I used to get frustrated because they never really supported C++ the way that I used it. The diagramming tools were only OK as a record of what I had designed so far. But I couldn’t create code from them and therefore as time went by I was put off using them as design tools in favour of the best design tool of all – a piece of paper!
That’s all changed now. I can sit down and start developing right away, without feeling guilty or that I have broken a golden rule or something. When I develop in JEDI the design is the program, and vice versa. There is no source code so I just work with the design. That’s just as well considering the tight deadline I have on this one, I can’t afford to waste any time.
Happy now with a full cup of coffee I slouch off into my office and shut the door behind me. Nobody will open that door to ask me questions, which is what used to happen. They can just give me a shout within the JEDI system. That’s what Noah did the other day when he was at the Board meeting for the PathSight project over in Oslo. He needed me to explain the reason why I had disabled a feature in the scanner on the PathSight interface. I was working and he had a JEDI mask on his laptop. So he attached himself to my design space and I saw his avatar appear nearby, we had a short conversation in which I explained my design to him, calling up the design for him to see. I showed him how there was a conflict in the requirements of the old feature and a new set of features that we had inserted a few weeks before. Apparently, he had patched his JEDI system into an old 2D overhead projector so that the whole board was able to see a 2D representation of the design, and hear my comments about the flaws in the old arrangement that had been corrected by the new features. Noah had then been able to vanish back to the meeting with the board satisfied that there was a good reason for it. The board were very impressed by the JEDI system, themselves. They bought 3D JEDI viewers to the next board meeting and insisted that Noah and I explain to them the way that the PathSight project fitted together. I got a lot of questions from them about the inter-compatibility with other imaging systems and databases. They didn’t know that I had programmed for them to see the abstract (friendly) representation of the PathSight system. They would have been overwhelmed had they seen the totality of the design all together. So would I for that matter. I guess that project is equivalent to about a couple of million lines of code these days. Not bad for a two-man development team, I thought. And I told them so! I never got a raise though :-(
I have an old sofa in my office. None of that orthopedic nonsense, I wish to be comfortable when I program. If I could get away with it I would bring a bed in here instead. But they think I would fall asleep on the job, which wouldn’t go down well, especially at the rates I charge these days! Still the sofa is OK, since I don’t need a keyboard so much as I used to in the old days. With a microphone and a pair of VR gauntlets I can do more, faster than I ever did with a keyboard and a mouse. The JEDI system is programmed to recognize the Hungarian notation when spoken by the JEDI operator. It can therefore translate variable names and method names into text. It does it so well that my naming style seems much more consistent these days. The others have commented about how tidy my patch of the design space looks these days. I’m quite proud of it myself. Not that it couldn’t be converted into something more aesthetically pleasing for them if they so desired. They all have their own naming conventions that they carry around JEDI with them, but when we collaborate on designs we tend to use the identifier style that the original designer used, when creating the design. It even tries to guess what the type of a variable is by the name that I give it.
Even though we share our naming conventions when working together on a design that still leaves a lot of room for idiosyncrasy. My mate Taki over in GenSym uses JEDI as well, but he has programmed it to show the design space as a dungeon of a haunted house, where design subsystems are crypts and unfolded classes are shown as sarcophagi. Linked classes are attached with trails of blood and slime. When he unfolds a class, the process is shown as the lid being pushed off of the sarcophagus and a skeleton climbing out. Quite gruesome really, but then what do you expect from an old Goth. Still he has produced some really hot code lately so I guess that arrangement works for him.
I’ve got a couple of PUPs or Programmable User Profiles that I tend to use most often. The main one is a virtual representation of Kubla Khan’s pleasure dome. I find that if the environment is more pleasurable I take a more positive attitude towards the work, and pay more attention to detail. I dot my classes around the fountains. I keep my system files packed away in the Tents out in the grounds, where Kubla Khan used to sleep when he wasn’t off killing the peasants. The JEDI help guide is none other than Marco Polo himself, and of course the background validation system is Kubla Khan. He occasionally shouts at me in a loud voice about the fact that my program “wouldn’t run like that!” If I don’t tidy my act up a bit I shall die the death of a thousand cuts. I can consult the system documentation by either going to the Khan’s library or by asking questions of Marco Polo. I also have a sci-fi PUP that I got from a Trekkie bulletin board in Geocities. It is based upon the inside of an interstellar space ship like the one used by that guy in Isaac Asimov’s foundation series. You are in communication with the ship’s computer. It takes the place of Kubla Khan as the JEDI system and Marco Polo is replaced by a little Simulacrum of Hari Seldon. It’s really cool – if you make a mistake, and the ship systems detect it, they send Hari Seldon to correct you. It’s just like in the Book, he suddenly appears in front of you and says his little speech about making yourself comfortable and smoking if you want to because he doesn’t care. And then, when he finally gets to the point, he tells you that his calculations have predicted that the software will not work in the near future because of some terrible thing that the galactic empire (you) have done. Unless something is done, the second foundation (shipping the software) will not happen as planned. Well, I thought it was cool anyway. Pity they never made a film out of that series. I often use PUPs like these because I make use of the Roman room techniques for memorizing thi
ngs. I find that if I have a Design Space environment that I am familiar with I can remember where I left a piece of my design, or some notes that I dictated earlier. Other people like enhanced versions of the good old IDEs of yesteryear. Some old-timers even use JEDI with a plane old 2D JDM which the claim is just as good as the 3D spaces.
I’m in a bit of a hurry, though, so I am going to run JEDI in bare Cyberspace mode today. I take a last slurp of my coffee before I put on my Goggles, I forgot to do that once and dipped my microphone comset in the coffee. The Mic was trashed, and I had to get a new one from Misco. The comset I use at Fairfield are, needless to say, the cheap pair that comes with the basic JEDI system. A wrap around ray-ban style set with old RAF-style goggles for the visuals and an integral Sennheiser microphone and headphone set for the acoustics. I’ve been trying to get a pair of Clint Eastwood style shades for the visuals, and an original Kate Bush Live Mic. They are much clearer, and you can see through them if you’re one of those that like to pace around your office while you work.
With the headphones in place I speak my invocation command “Warp factor nine” into the Mic. I see that JEDI is beginning to load because the darkness is slowly illuminated as the system uploads itself and the designs from our server, an old Pentium in the other room. Along with the appearance of JEDI comes some daft sound effects that I lifted from the Video independence day from the part where the Space Ship flies overhead – a deep rumbling that becomes a terrifying fanfare for technology. When the fanfare is over the JEDI system is available for use. JEDI has loaded up PathSight which is what I normally work on, I can see Mike and Ross working on what looks from here to be an auto-focus routine. I can vaguely hear what they are saying and I say “Hello guys.” Because I am looking at them while I say this they get the acoustics loud and clear from me. Mike looks up and says “got a minute?” I glide over and look at what they are puzzling over. “What’s the problem?” I say, and Ross replies “It’s doing all of the work but the final view is always the original focus that the system started out on.” After a bit of a root around, I can see the problem. “You have forgotten to update this variable here. If you move to the focus stored in that, at the end you will have moved to the original focus. That variable is not taking part in the rest of the process after the initialization. You need to copy the final position from the FibSearch function into that position. See? That way the end result is immediately updated.”
Ross’ avatar jiggles a bit and I know that he has just slapped his forehead. I drag a line from the outgoing channel of the FibSearch algorithm into the Stage. Immediately the others can see where they went wrong. JEDI’s like that – the logic of the program is so much easier to see when it is floating in front of you!
I make a hitcher’s thumb sign and the toolbox slides in from the periphery of my vision where had been floating ever since The system came up. The box glides in to my central field of view where it hovers, rotating slightly. It shrinks slightly and then quickly unfolds into an artists paint palette with a colourful set of icons on it. I choose the icon that looks like a lightswitch and suddenly the PathSight project design space disappears from view. I can’t hear the conversation that is going on between Mike and Ross. Instead I hear the faint background hum of JEDI. I have just closed the PathSight design because I am about to star up a new project. On the palette in from of me I point at the icon of a present wrapped in a bow. A wizard appears in front of me, asking what type of project that would be. Normally this would be Marco Polo or Hari Seldon, but in the plain old system it is a wizardly avatar with a pointy hat and starts and moons all over his cloak. I select new Windows NT6 Application, and the system guide makes a note on a clipboard he holds in his hand. “Is this a stand alone application sir or would you like it to make use of other code?” I reply “make use of designs from the 3DFI application”. “very well sir”, within the JEDI server in the other room the wizards is performing his magic and creating a new project directory with a basic JCOSS to store the classes on.
Surveying the System Files and Class Libraries
The design space appears piece by piece as the wizard creates it. The design space in JEDI’s Plain Old PUP (or POPUP for short) is a limitless three-dimensional space in which the user can move by using their fingers to direct their movements. I see the Win64 system libraries forming in the distance below me, seemly fathoms deep. Largely, those files really are fathoms deep unless you happen to like rooting around 64bit design files written by people with a very evolved idea of what generic means. They were written to support proper object oriented windowing. They were a good attempt to create component based interface programming and if you don’t want to know how they do what they do you can use them with ease. I seldom have to go down there, because I did all of that low-level stuff on the PathSight project ages ago. Still its sometimes fun to swim down there and explore new regions of the designs.
These designs will be the basis for the 3dAcquire app I’m about to design. They contain all of the basic interfaces to the standard operating systems currently supported by Fairfield. I’ve got interfaces to BeOS, SunOS, Windows NT, Rhapsody, and of course Linux. Next comes the base designs for the 3DFI suite that I shall be dipping into at times for things like image enhancement and alignment tools, cameras and stage drivers. Last of all comes the generic JEDI App framework that I selected first of all. I see that the standard entry point class is in there, linked up to a window class that shows a basic 2D dialog. Wouldn’t it be cool if all applications could make use of 3D virtual environments. People would need more hardware than is currently entry level, though, so I still have to produce 2D apps like some C++ programmer. Yechhh! Maybe one day I’ll add to the JEDI base libraries some fast code for doing VR in the basic App.
I slide over to the app design and see that it contains a class which has the standard function begin. I figured that within the acquire program I need to distinguish between the system that specified where the images were to be taken and the part that took those images. I also need a place to store those images. I therefore point in front of me two. The JEDI system spots my shorthand for new class and animates my VR Glove squirting forth a new class that comes to rest just in front of me. I dictate “Itinerary” and the system places a name on the box floating in front of me: Citinerary. I say, “annotate” and a small microphone appears by the class. I say, “This class is designed to store the positions where a stage might visit in the process of scanning a slide.” The system MPEGS the audio and stores it away on disk. The class itself is adorned with a little play button like a right arrow. I press the arrow and the MPEG annotation is loaded back from disk and played. When it is finished I create a new class in the same way and call it CScanner. I then point three fingers at CScanner and an owns relationship is anchored to the scanner class. The other end of the owns relationship is dangling free. I drag it over to Citinerary where it is attached. The CScanner now owns the Citinerary.
Industrial Inference 