Many thanks to Johannes for writing this! -- Seth

Indie: Basic Usage

by Johannes Abendroth

Getting started

Create a window

Using the Interface menu, switch to Design Interface mode. Create a window (using MenuInterface-Make New Window, then click on Menu Interface-Edit Current Window, click there on Edit Window and check the Box Show on Startup)

Define your hosts

Hosts are the directories (paths) on your Computer, where you'll put your resources like, videos, audios, pictures, cursors, etc. Make a logical structure -- it'll help you later on.

How to make an Ask System

What is an AskSystem?

An AskSystem is a linked structure of question and answers -- for each answer you can have some points, which can appear in a notebook.

The question, answers and points can appear anywhere on a screen, therefore you use viewers.

To "browse" the AskSystem you need start levels -- these start levels are usually defined by the current task you have to do (i.e. a specific test, a interview to a certain topic, etc.).

These start levels are named Topics. These topics define the questions which should appear first for the given task.

For example, if you go the first time to a specific test, you want the user to see 4 questions in your AskSystem. These 4 questions are defined as the topic.

What do you need for an Ask System?

That's what you ask
That's the answer texts or movie clips
That's the points, which are added to your notebook
There are two kinds of points: fact points and result points -- fact points are scenario independent points, meaning coming from the expert AskSystem, result points are scenario specific points, like only valid for one picture within Rembrandt. We should keep the distinction said Seth, even if I don't know any effect.)

They have to use some kind of intermediary to finally appear on the screen -- why, I don't know beside for Answers (later about that) -- these intermediary are:

Question List
for Questions
for Answer
Evidence List
for Points
To bring them to the screen you now need a viewer:
Question Viewer
for Question List
Answer Viewer
for Speaker
Evidence Viewer
for Evidence List
The Answer Viewer is the only viewer which can have more than one of these intermediaries (here: speaker) -- the other viewers have a one-to-one-relationship to their lists. The purpose is, that the name of the speaker (should be the real name) can appear on a nameplate below the answer viewer.

How to do it?

It could be different depending on how far you are in your design -- if you have your AskSystem ready structured or if you only know all your questions or if you only know the interface.

I only describe the case, that you have your entire AskSystem ready structured (the other cases could only differ by another order and the use of dummies).

I would do it like this:

Create a question, write in the question text (If you already know the question lists, meaning the location where the questions will appear, define them now, otherwise do it later, like described below). Now double click on answer (creates one), create (or choose=find) the speaker, click on text/movie/picture. If you have your videos etc. already logged, type in the text box the file name and the synopsis -- if you like (and have it ready), you can already choose the actual file below the text box. Now click on Followups/Points/Next Answer and type in your points -- each point, which should be a separate piece of evidence has to get it's own point.

After you finished the input of all questions and answers, you have to structure them. Therefore I would start with creating a topic and asign (find) the first question for this topic. Then double click on this question, define a question list for it, double click on answer, click on Followups/Points/Next Answer and define (find) the followup questions and define the question list for each. Take care, that the question list should be the same as for the topic questions. (This is only valid, if you have only one AskSystem on the screen at the same time. If you have more the one AskSystem, i.e. the expert AskSystem and an interview in the simulation, you define on the topic level all the question which should appear in this topic and assign them to two different question lists. Be careful with the followups -- an example: If you have a question in the interview, which should have followups in the interview and changes the expert AskSystem that's the common case], you need to have followups for the interview w/ the question list of the interview questions and followups for the experts w/ the question list of the expert questions.)

If applicable, define in each followup question the next level of followup questions following the same procedure. Do this until you have defined the entire AskSystem for this topic. Now go to the next topic and start over. It doesn't matter if you had defined a question as a topic or followup question before -- you can still use them here again as topic or followup question.

Finally you drag the question, answer and evidence viewer from the palette (the window w/ the funny pictures) onto your window and define the question list, speakers and evidence lists: double click on the viewer, goto Edit xxx Viewer. (If you first created the interface -- this would be your first step and not the last like here.)

One hint: In the Question Viewer, you can change the kind of buttons you want to have in the AskSystem -- it seems to me, that the MacButton is not able to wrap text!! Maybe it's a global Mac property, maybe it's a bug.

Now you have to call (trigger) the topic. A trigger is activated by an event. An event could be for example the clicking of a button or the start of the GBS. An event like clicking of a button needs (haha) a button on the screen. Drag one over from the palette, double click on it, click on Edit trigger, open the topics section and choose (find) under Then activate these topics... the topic you want to be called. After clicking on the button later on, you will see in your question viewer the questions of this topic.

Windows & layers

The windows/layers concept is quite easy: You usually have one main window which appears at startup (see Getting started). Now imagine the window as a overhead projector, on this overhead projector you place your transparencies -- these transparencies are your layers. You see everything of the uppermost layer but only that part of the lower layers which are not covered by objects on the upper layers. You can show layers, meaning put them on top or hide them, meaning remove them (if you show them again afterwards they are on top now). On a layer you can have several objects (items). They work the same way like the layers on a window: You see everything of the upper most object but only that part of the lower objects which are not covered by an upper object. The order of the objects on a layer is fixed for the user -- you cannot change it later by an user action (certainly it's always changeable by you in design mode).

How to make layers/windows and assign objects?

The best way to work with layers and windows is the window Window/Layer Controller, which you can activate from the Interface menu. Open it and there you can go to the windows and the layers window to create new windows or layers or click directly on existing windows/layers to edit their properties.

I assume that you have one window, so click on edit layers, in the new window click on create layer, then give it a name and choose (find) the window it should appear on. Now choose (find) the objects (items) which should appear on the layer. To bring them in the right order, use the Move up/Move Down Buttons -- but be attention, the list is reversed to the appearance: the top item in the list is the lowest object on the layer and vice versa! Conceptually, the items appear in the order that they will be put onto the "overhead projector".

Another way to put objects on a layer is to select them and then on the Interface menu, choose either Add to layer... to add them to an existing layer, or Add to new layer... to create a new layer and add them to it.

How to show and hide layers

You show or hide layers usually with triggers.

Another way is the pseudo grouping of layers. In the same window where you define the objects on a layer, you can define which layers should appear together (like a group) or should exclude each other (like a switch). For example: you have a background layer and a two button layer. Everytime you activate button layer A you want to have the background layer as well, and you don't want to have button layer B. To do this, add in the properties of button layer A under Layer it shows also, the backgroud layer and under Windows/layers it hides button layer B. But attention again: This is not a real group and not a real switch -- the links go only one way. For example if you show the background layer, button layer A is not automatically shown, therefore you have to add button layer A to the properties of background layer as well. And if you show button layer B, button layer A is not automatically hidden, therefore you have to add button layer A to the properties of button layer B as well. But even now, it's not a real group or switch. Because if both layers, background layer and button layer A, are shown it's still possible to hide one of them and the other is still there and it's still possible to have none of button layer A and button layer B on the screen. ... but it's still a useful property.

Some of this properties work also between windows and layers.

Avoid infinite loops of layers

Last time I said something about layers, that can give the impression, that you should let the layers show each other or hide each other and not only in one direction (this was in the very confusing part of the pseudo grouping of layers) -- but this is wrong.

If you get a "Stack Overflow Error", the likeliest cause is that you created an infinite loop in your layer structure, e.g. layer A is on layer B's "show also" list and layer B is on layer A's "show also" list. If you accidentally do this, the Indie developers can help you find the loop and remove it.

A good rule of thumb to help you avoid this is: a layer should always require its background, but never vice versa.

Best hint of me: Just imagine the shown/hide functionality is like an internal trigger.

Layer Q & A

Q: There is this problem of having a layer shown, then you show another layer which covers the first one -- now you want to see the old first again, but this seems not to work, although the windows/layer controller tells you that it's there.

A: It's quite easy -- you have to realize, that the show/hide layer command don't actually shows/hides the layer. Imagine the layers as slides on a overhead. Hide layer takes the "slide" from the overhead and show layer puts the "slide" on top of all other "slides". So -- if you haven't removed (hidden) the layer, you can not put it on top (see it again). Solution: Every time you don't need a layer, hide it -- this is a good idea anyway because it will improve performance.

Q: But, you say -- what should I do, if there is a layer, for example with some button, which has a changing background -- first background A, now I show background B - background B now covers my buttons.

A: First -- the easy, but not nice way: Let the trigger which shows B hide the Button layer and as a next trigger show the Buttons again. The better way is: avoid this situation -- one possibility could be, to cut the background into pieces and avoid the part of the buttons or integrate some of the background in the button layer.

Buttons and pictures

Hopefully almost intuitively clear.

Important is the TwoPict Button: You should define at a minimum the pressed and the non pressed button -- otherwise it will look bad. Two Pict buttons have 3 properties: Sticky, Pressed on Startup and Is a Checkbox. Sticky means it's a onetime switch -- once you pressed it, it will stay down. Is a Checkbox is a real switch, after pressing it stays down, if you click again on it, it pops up again (that doesn't has anything to do with its functionality). Pressed on Startup should be clear -- it can be combined with the two others. A combination of Sticky and Is a Checkbox is possible but shouldn't be because it doesn't make any sense.

Radio buttons

If you have Radio Buttons or Option Buttons, only one of them can be pressed at the same time (like Multiple Choice w/ only one right answer).

To create something like this you need TwoPict Buttons. In their properties you have to give all relevant buttons in the field Radio Group an identical group name and activate the property Sticky. If you now click on one button, it will go down, if you click on another button, that will go down and the first one will pop up.

Remote pressed radio buttons

To have (radio) button pushed down without clicking on it, you need a special trigger (why do I want to do it? -- see following application). If you have now an event (like clicking another button outside the radio group), choose Edit trigger and choose Model Action (what exactly a model action is -- I cannot say. For me it's a conglomeration of actions with don't fit under another category -- but most probably there is a real reason behind it). (NOTE: Model actions were named that way because the original idea was that none of them would affect the interface directly -- instead, they would only affect objects in your "world model", i.e., tests, results, questions, answers, etc. But as Indie evolved we wound up creating "model actions" that really just do stuff in the interface. Eventually we'll separate them out into "model actions" and "interface actions". -- Seth)

Now you create a model action named Pop Button Model Action, choose (find) the button in your radio group you want to have pushed and after that you click on the option ... but keep this one pushed (insane!).

Okay -- why should I want to push down a button in a radio button group remotely?

Imagine you have a notebook with different tabs (sections in notebook). You can switch between the notebook section by clicking on the tabs. How to do that? the different sections are different evidence viewers lying on different layers each. The tabs are radio buttons. Their trigger, show the respective notebook section layer, which has as property hide all other layers with notebook sections.

If these section are now specific to something in the simulation and you want the notebook change automatically to the section you are in, you have to do following: The event, which brings you to the part of the simulation should also show the respective notebook layer and should push the respective button in the radio button group down.

Building a turnkey application

I know, that right now, almost nobodyq cares, but for me the nicest way to deliver an Indie GBS on a CD-ROM is, if you only can see the Indie-Icon on the CD ROM, double click on it and ... voila.

To do this: launch the Indie Runtime application (don't ask me, why it's not possible from the Tool), load your GBS, and then choose Save GBS as Application on the File menu. Before doing this though, in the Tool, be sure that you save it with the right hosts for the CD ROM. It's best to use relative paths in your hosts. It's also best to use relative window positioning, otherwise you will have problems on other machines with a different screen size. The next steps are easy -- burn onto the CD Rom the new application you just made; at the same (root) level save the 3 pcml-xxx-4.1 files and the hosts with your resources. In Toast you can double click on the files and folder and decide, if they should be invisible. If you do this for all but the application, you'll have a nice clean distribution CD ROM (although that's not very practical if you want to use it as a backup medium).

Oh yeah -- and to avoid an error message either send the logfiles to the user's Preferences folder in their System Folder (there is a setting for this in the GBS Preferences object) or turn off logging, therefore you have to create a text file named "INDIE-prefs". Put it in the same directory as the application. Put the following line of text in it:

(setf ccl::*logging-p* nil)

Reference card

Last modified 4/27/98 ST