I-DE: I-X Domain Editor
To provide user configurable task and process modelling tools. I-DE
is intended as a process and activity domain modelling variant of a
more general modelling support tool called I-AKT
being developed under the UK EPSRC-funded Advanced Knowledge
Process Editor Design Notes from Austin Tate
I have made a mockup screen image to provide guidance on the various inputs
to the I-DE design.
Click for full size 1024x768 screen image
I made this using Steve Polyak's
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....
- MENU BAR -- the usual drop-down menu along the top. Individual
toolbars will appear with the individual viewers.
- 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.
- 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
Notepad (shown in the I-DE mockup screen Home View) and
XML Spy's Nested Grid View (shown below).
- 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.
- 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
- 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
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
- 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
- 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?
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
Underlying the simple I-View, the schema produced would be in the full stored process/domain model format we are adopting.
Page maintained by email@example.com,
Last updated: Mon Jul 11 16:16:43 2016