I-DE: I-X Domain Editor

Aim

Process Editor Design Notes from Austin Tate

Click for full size 1024x768 screen image

I made this using Steve Polyak's CDE/CPE tool which has a fair amount of what we want in the graphic views. I attached this to Microsoft's XML Notepad editor which provides a nice tree viewer/editor with each entry in the tree having a row aligned in-line attribute value editor.

The screen is split into 5 main areas and has some important aspects of what I think we need....

1. MENU BAR -- the usual drop-down menu along the top. Individual toolbars will appear with the individual viewers.
2. TAB CENTRAL -- this is a stylistic element which we have adopted in many of our user interfaces over the last 20 years. We have had a central bar across our TF Workstation, editors, process panels and so on that has provided buttons, tabs and so on to control what is shown in wind panes that are above and below this central tab belt - I suggest the name "tab central", "central belt", "control belt" or "control centre" for this. Any preferences? We might not only use tabs here. Radio buttons might work better for some selection functions, and buttons to launch other undocked or undockable panels might be added. In general any window pane ought to be undockable to allow for multi-screen working in future.
3. HOME VIEW -- There is a "home view" in the top left. I consider an anchor or home view important, as we will use many tools and techniques and views, most of which will only provide partial views of the whole emerging model. For this home view it seems to me important that its a pretty complete - even if very simple - view. So it might also be rteferred to as "full view". You should always have the feeling you are seeing the whole model as it emerges. It shpould feel as if all other views are looking at or updating this home view and that the current model is defined vy this view. Load and save of views, as well as import and export of the model should feel as if they work on this home view for clarity. Many of the others tools and viewers will only show specialised aspects or partial views of the emerging model. For this home view I chose a tree view of the complete domain model - which would have MUCH more than just a list of processes in it. It would also contain the global constraints, outstanding modelling issues, and indeed the grammars, lexicons and other information that all are part fo a full domain definition. Added and anchored by row to entries in the table view is an "in-line value editor" which would itself be grammar and lexicon limited suited to the entry to hand.

   Example interfaces that could form a suitable home view may be seen in Microsoft's XML Notepad (shown in the I-DE mockup screen Home View) and XML Spy's Nested Grid View (shown below).

   

4. GRAPHICS VIEW -- To the top right is where I would place any graphical views. Of course the interface should eventually allow this to be pulled anywhere, or indeed to be turned off completely - as should be the case for any of the various viewers.
5. WORK AREA -- To the bottom would be a "work area" where I would choose to place tools such as a form orientated way to full in details of the model - which could itself by driven from the grammar and lexicon suited to the currently selected entity in the home view. I would allow a whole host of tools to share this work area. This would include assistants to check on te model and raise modelling issues to be addresses. An Issue handler or conflict resolving assistant. Tools to amend any Grammar or Lexicon and to check the impact on the model of any such change - again raising modelling issues if there are problems in the change. Tools to provide object (Activity-Relatable Object - ARO) views and an ability to create and maintain the object class-sub-class-instance model associated with the process model and i turn its links to the relevant lexicons and their links to the grammars would be provided here too.

Some other aspects of the editor design are noted here:

• TF METHOD -- Some ideas on a methodology for process or activity domian design are described in a paper by Austin Tate, Steve Polyak and Peter Jarvis on the TF Method (Postscript document).
• APPEARANCE AND CONFIGURATION -- Many aspects are user configurable. The user should be able to move the boundary between any window panes to give more or less screen real estate to the views they are workign on or prefer. View configurations with a setup as the user prefers can be saved (after selecting the current set up) and restored. A set of initial layouts would be provided - a standard one would allow for egeneral use. Specilaised layouts for editing focuissed on some specific areas culd be provided - such as a layout that is better for acrtivity eiting, or a layout for global constraint editing, or one that is better for manipulating the grammars and lexicons, etc. A "workflow" style of support could be provided whereby the user is encouraghe dto go through some modelling process and given suitabel screen setups for each phase or aspect of the modelling.
• MULTIPLE OPTIONS OF THE MODEL -- The screen also shows a simple idea on how to present options of the overall domain model, as tabs below the "home view". However, I have not thought a lot about this yet. In particular we will almost certainly want structure sharing of options (perhaps using our favourite implementation method for this - contexts), not completely separate copies.
• XML FORMAT -- The editor should be able to store and load domain models from persistent repositories of various kinds. This eventually should support sophisticated multi-user and multi-poorganisation repositories with version control, partial checkout and checkin, etc. But at first simple filestore save and load will be supported. All external interfaces will use XML. Some initial ideas on an XML format for the domain model are available here (<I-N-OVA> XML Outline).

  There will be an inova-plan.xml to go along with this that adds objectives, evaluations, preferences and plans. Their core structure will be the same. Domains are likely (but not necessarily) to have activities with just ONE level of expansion for a process library. Plans are likely to have as many expansion levels as are in the plan structure.

• EXAMPLE GRAMMAR AND LEXICON DRIVEN ATTRIBUTES EDITOR -- An example attribute value editor that can be driven from the grammar and lexicon available was created on the TBPM project. See images here:
  

  

• SIMPLE DOMAIN EDITOR I-VIEW A simple domain editor I-View will provide a "quickly add a way to do something" for use in I-P2 and for simple I-DE editor use by inexperienced users or those wanting to add legitimate processes quickly.

  It should be very simple and limiting (deliberately):

  activity (schema) name - a symbol? expands pattern
  nodes (sub-activities)
  constraints
  annotations
  The constraint box would be really simplified - just two radio buttons saying "ordering is sequential" (this will be the default selected for new schemas) or "ordering is parallel".

  A variables field is not needed, it should be assumed that in this view all variables mentioned are declared and made available behind the scenes.

  On the pull-down menu bar there should be an option to "turn on/off advanced editing capability". This is off by default. If turned on it would bring up an advanced button in the constraints area of the display. This should call up the more sophisticated constraint editors such as the garmmar/lexicon constrained editors described above.

  Underlying the simple I-View, the schema produced would be in the full stored process/domain model format we are adopting.

Planning & Activity Management | I-X

Page maintained by a.tate@ed.ac.uk, Last updated: Mon Jul 11 16:16:43 2016