On Sun, 31 Dec 2000, Patrick Dughi wrote:
> The one thing that I may just not have gotten to yet is that of
> interface design. I'd be curious to see how you can write a generic,
> yet useful interface for most of the common tasks in the editor.
I think this is actually the easiest problem to address. The editor does
not need to describe its interface in any way. It only needs to take
advantage of the XML Schema to create a more-than-acceptable UI. A sample
Schema for a room might look, in part, like:
<xsd:complexType name="RoomResType">
<xsd:attribute name="Vnum" type="RoomVnum"/>
<xsd:sequence>
<xsd:element name="Name" type="ShortStringType"/>
<xsd:element name="Description" type="LongStringType"/>
<xsd:element name="Flags" type="RoomFlagList" minOccurs="0"/>
<xsd:element name="Sector" type="RoomSectType"/>
<xsd:element name="Exits" type="RoomExitList"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="RoomFlagType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="DARK"/>
<xsd:enumeration value="DEATH"/>
<!-- and so on . . . -->
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="RoomFlagList">
<xsd:list itemType="RoomFlagType"/>
</xsd:simpleType>
<xsd:simpleType name="RoomSectType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="INSIDE"/>
<xsd:enumeration value="CITY"/>
<!-- and so on . . . -->
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="RoomExitType">
<xsd:attribute name="dir" type="DirType"/>
<xsd:sequence>
<!-- . . . -->
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RoomExitList">
<xsd:sequence>
<xsd:element name="north" type="RoomExitType"/>
<xsd:element name="south" type="RoomExitType"/>
<!-- and so on . . . -->
</xsd:sequence>
</xsd:simpleType>
<xsd:simpleType name="RoomExitList">
<xsd:restriction base="RoomExitListUnbounded">
</xsd:restriction>
</xsd:simpleType>
Knowing the type gives us a big clue about the interface. Without
describing too much of my motivations for this (I'm space constrained), an
element/attribute that is an instance of a simpleType has a direct input
control within the current editing window. The specifics of the
simpleType hint at what type of control to use. There are a variety of
rules we can derive from this, too numerous for me to mention. A simple
set of rules might be:
* If it's a non-enumerated simpleType, provide an input box for the
person to type the value into. Constraints upon the type can be used
to constrain what can be entered -- for instance, an xsd:integer can't
have an alphabetical character in it. This covers vnum, name,
description, etc.
* If it's an enumerated simpleType, provide a dropdown list. This
covers sector types, item types, etc.
* If it's an unbounded list of an enumerated simpleType, provide a set
of checkboxes so we can check all the elements we want to be in the
list. This is good for flags.
* If it's an orderedList (we'd have to write the type -- which is very
trivial, the name is the only significant difference from a regular
xsd:list) of complexTypes, we provide a small box, perhaps 6 lines
high, displaying part of the list with a scrollbar for scrolling
through the remainder of the list. The list should have controls for
reordering the elements, adding a new element, removing an existing
element, and opening a window to edit an element. (Issue: how are
the elements displayed here?). This covers Zcmds.
* If it's a simple xsd:list of complexTypes, provide a similar control
as above, absent the buttons for changing the order of the elements.
* If it's a complexType, provide a button to open the editor for the
complexType or, if the complexType is just a sequence, we might try
embedding it directly in the current window (this is because exit
editing would then be ugly: click "Edit Exits" and get a window with
"Edit North", "Edit East", ..., "Edit Down," and then you click one
and finally get to edit the desired exit -- uck).
Expanding upon these rules is a good idea, but I'm running out of steam.
It's probably acceptable to write the rules as XML itself, dictating how
they're displayed. This would give you some flexibility for deciding how
certain element types are displayed without having to edit the code. It
would also give end-users the ability to customize how their new elements
are edited. Something along the lines of:
<PjD:display control="dropdown">
<type>simpleType:enumeration</type>
<type>simpleType:SmallRangeInteger</type>
</PjD:display>
Anyway, I think that answers your question. The actual display of the
interface, of course, is left up to you, but deciding how to display it
is simple rule-based programming.
-dak
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT