A taxonomy of educational widgets
JAN HERMAN VERPOORTEN
Institute of Information and Computing Sciences
Utrecht University
Padualaan 14, 3584 CH Utrecht
THE NETHERLANDS
http://www.cs.uu.nl/~janherm
Abstract: - Interaction is an essential hallmark of education. Therefore widgets are relevant in educational software. This article describes a taxonomy that is capable of describing a possibly infinite widget collection in a finite way by drawing a distinction between abstract widgets and concrete implementations. The taxonomy is of help in designing educational software: It offers the designer a consistent overview of possibilities for interaction. The taxonomy also can be used for indexation and retrieval of widgets, for instance in case of reusing widget components or reusing learning resources containing widgets.
Key-words: - Taxonomy, Metadata, Design and Development, Educational Software, Component reuse
1 Introduction
For some years the e-learning community is paying considerable attention to the possible reuse of 'learning objects'. The two reasons for this focus are the reduction of cost of development and the desire for dynamically assembled products ('the right instruction to the right person at the right time'). In general, reuse pays: Using components again reduces development cost. Also, daily practical use ensures that components are more reliable because they have had to prove their usefulness in real life and are being tested over and over. However, to take advantage of these, one must be able to rely on standards for re-assembly and interoperability as well as on metadata describing components for indexation and retrieval. The supply of components and the demand in the application domain must match too.
With respect to e-learning several, organisations are working on the fulfilment of these conditions. The Learning Technology Standards Committee (LTSC) of the IEEE is developing accredited technical standards, recommended practices and guides for learning technology. Recently (approved June 13, 2002) one of their working groups established the Learning Objects and Metadata (LOM) standard [1]. This metadata dictionary describes learning objects. The creation of the IEEE LOM standard was accomplished by contributions of organizations such as the Advanced Distributed Learning initiative (ADL) [2], the European ARIADNE (Alliance of Remote Instructional Authoring and Distribution Networks for Europe) [3] and the IMS Global Learning Consortium [4]. IMS for instance has carried out the XML notation of the IEEE LOM metadata (called the IMS Learning Resource Metadata Information Model). CEN/ISSS WS/LT (European Committee for Standardization / Information Society Standardization System, Workshop on Learning Technologies) [5] is currently translating IEEE LOM to be used throughout the European Union (internationalization). Clearly IEEE LOM already is the commonly accepted global standards solution for describing learning objects through metadata.
Other educational standards (some still under development) focus on retrieval or exchange of learning resources (Gateway to Educational Materials [6], ARIADNE [3]), on learner information (AICC [7], ISO/IEC SC36 [8]) and on content packaging (IMS [9]).
Finally, outside the e-learning domain, in 1997 the Widgets Working Group of the VRML community intended to develop a component-based architecture for reusable, interoperable widgets, and create a widget repository to store, document, and classify these widgets. Unfortunately the group is now defunct without leaving any results [10].
Two things are notable in the above-mentioned projects. In the first place the focus is on the reuse of concrete, subject matters containing learning objects. In case of application development, however, reuse should be focused on empty components in addition to such concrete objects (the 'kitchen' as well as the 'restaurant'). In the second place the description of educational interaction (controls, widgets or response types) lacks details, even though this is such an essential hallmark of education: The IEEE LOM standard has a limited set of metadata fields meant for interaction elements, which are objects at the 'aggregation level 1' (raw data or fragments) in this standard. Its metadata covers some requirements (operating system or browser) and a datatype, to be indicated as a MIME value. MIME is insufficient for the description of more complex data structures such as lists or trees. The only interactivity values are active or expositive. Finally, only some information can be retrieved from the learning resource type (exercise, simulation, questionaire, etc.), the interactivity level (5 levels from very low to very high) and a few educational properties such as context and difficulty. So, for an effective reuse of widgets the IEEE LOM metadata should have a capicity to retrieve much more information than now possible. However, it has the possibility to refer to an external classification. IMS, which has carried out the XML notation for IEEE LOM, also recognizes that the IEEE LOM standard may not adequately capture all metadata needed to describe learning objects and their use. Therefore, its notation allows extensions for proprietary metadata elements and structures. Of course, using such extensions risks breaking interoperability.
Organisations that require more information about interaction elements can deploy the proposed taxonomy, either in their own way or following the IEEE LOM or IMS guidelines. The proposed taxonomy has a broader possible application than the reuse of concrete subject matter containing learning objects. The properties of a widget component and its accidental learning content are rigidly separated: The taxonomy is only aimed at pure widget properties. This way it is useful both to application development (the 'kitchen') and to learning object distribution (the 'restaurant').
In the next section the proposed taxonomy is discussed. The discussion is restricted to its structure and the underlying principles: A possible notation for instance to fit the IMS extension mechanism will not be further explored. Section 3 finalizes the paper with a summary of some results and a conclusion.
2 Taxonomy
The father of the taxonomy is Carl Linneaus (1707-1778). He brought systematic order in the description of living nature by structuring plants and animals hierarchically into orders and families. Hence, according to Webster's Dictionary a taxonomy is a "a classification of organisms into groups based on similarities of structure or origin etc.". More generally expressed it is an orderly classification of information according to certain (and often debatable) relationships. Its hierarchical organisation is expressed as a tree.
2.1 Abstract widgets
In a taxonomy usually one traces a path from the global characteristics to the specific instance: say from Animals down to Ant. On this point the widget taxonomy differs explicitly: It applies in the first place to abstract widgets. These can be compared with Linneaus' higher categories called genera (singular, genus). A genus consists of concrete species (ant, fly, spider), widget implementations in our case. The difference between an abstract widget and a concrete widget implementation is that the former specifies the properties and the latter shows particular implementations of these properties, specifically with respect to the widget view and control. Focusing on abstract widgets has two reasons. Firstly, the number of possible widget implementations is huge, so we would run a realistic risk of an unsurveyable and unwieldy taxonomy. Secondly, new implementations are continually invented: Besides update problems this can cause a a nearly infinite collection. By restricting the taxonomy to abstract widgets both a surveyable and finite collection is achieved, while sufficient widget properties are mapped. This tractability is essential for a durable and effective categorization.
2.2 Didactical versus morphological
Educational widgets have similarities with test item formats (response types): A simple item format consists of a single widget while the more complex multiple response questions contain several widgets (e.g. fill in a form). In didactics, quite often an informal categorization of item formats is used which divides into open-ended questions that are characterized by the length of the answer (completion item, short-answer question, essay[-type] question) and the more 'closed' objective test items, characterized by the construction of stem and options (multiple-choice item, matching item, true-false item). This predominantly didactical categorization, derived from paper-pencil and verbal interactions, is of little use in e-learning: Computers enable more and different interaction elements (e.g. drag and drop, controlling a virtual process) that can hardly be categorized into an open-ended or objective format. This categorization also is not very consistent: Open-ended only applies to the effect of the student response action (characterized by the length of the answer only), while objective test items are characterized by a data model (implicit by a list only) on which the student's action is performed. A more consistent arrangement can be obtained by viewing both attributes, data model and student action, as belonging to the morphology of a widget and therefore to concentrate on this morphology.
2.3 Data model
The first distinction in the taxonomy is made with respect to the data on which an action inside the widget is performed. Three basic data models are defined: singleton, list and tree, satisfying the expression of every type of data structure.
A singleton is a single instance of some data. This may be intrinsic content such as a bitmap or a character stream, but can also be some internal structure, managed by the singleton. The latter is called a container singleton. This has no other visible granularity than the root of its data structure. For example a document that is viewed only as a series of words, even though it consists of headings, sections and paragraphs. The data of a singleton has a datatype, for instance a MIME type.
The next basic data model is a list, according to Goodrich and Tamassia [11] a sequence of positions at which elements are stored. An element is either a singleton or a list, this way realising multi-dimensional lists. Positions can also be empty, not storing a list or singleton. For example a crossword puzzle, which is a two-dimensional list (table) with empty positions.
The final basic data model is a tree, a hierarchical structure consisting of nodes. Both internal and external nodes (leaves) may store a singleton. List positions and nodes are considered to be structure elements. Although a tree can be expressed as a recursive list structure, the difference between a list and a tree is maintained: Among other reasons, a list position is either empty or stores a singleton or a list, while a node may store a singleton independently of having child nodes or not (see figure 1).
Fig.1 Structure of the basic data models
2.4. Choice of data model
It can be argued that a singleton, containing some text is actually a list of words or characters. In the same way it can be argued that if such a text contains HTML markup elements, it is actually a tree. The choice between singleton, list or tree is determined by the scope of an action. In a singleton the action is performed on the data itself. In a list or tree actions are performed on the data structure. For example inserting or deleting a particular position or node. However, actions can also be performed on the singleton stored at such a location. If an HTML document is presented as a tree, for instance to insert a paragraph section (node) as well as to type in some text inside that section (singleton stored at the paragraph node) is possible. But if it's presented as a (container) singleton, no structure is accessible and actions apply to the text only. So, required actions determine which data structures are to be chosen. That is why the next distinction in the taxonomy is defined by the types of possible actions.
2.5 Action types
Two action types are defined: edit en select. Speaking about actions, the meaning of selecting is quite clear but the meaning of edit is rather ambiguous. The effect of an 'edit' action is a type of modification, for instance a text change inside a singleton, or a list mutation. There are four possible modifications: insert, delete, replace and reorder. To accomplish a single modification, several succeeding actions need to be performed. The series begins with a selection of the required start position, possibly succeeded by the selection of an end position in case of a replace or reorder modification. A replace will next be performed by deleting the selected part followed by the insertion of the new one. A reordering will possibly be performed by dragging the selected part to its desired location. Actually the actor has several ways to reach the desired outcome, such as deleting the selected part, selecting a new position and inserting a fresh part. So, an edit action can fall apart in several part actions (it almost always starts with a selection) in a possible ambiguous way. But in the end the effect is clear: something has been changed. All 'edit' means in the taxonomy is 'change', which also fits well with the daily used terminology. It depends on the data model what edit may mean precisely.
2.5.1 Actions for singletons
In principle, a 'select' action can be performed in a singleton, although it depends on the data type what the exact meaning will be. Possibly a text allows the selection of characters or words, but the result of selections in a bitmap may be restricted to the coordinate values of selected shapes.
The possible meaning of edit is insert + delete + replace + reorder of data, of course completely dependent on the data type.
2.5.2 Actions for lists
A list allows the selection of positions. In most cases position selection is synonymous with the selection of the singleton stored at that position. However, if such an position contains a list then it might be selected in its entirety, although the meaning of such a selection is totally dependent on the educational context. An example is a multiple choice question whose options consist of text and an image (each option a list storing two singletons), leaving it open to the implementation whether a selection applies to an entire option (list) and/or the text of image part only.
Editing a list applies to the list positions and means insert + delete + reorder. Replace seems to lack but applies to the stored singleton: It means editing the singleton including the entire deletion of it (creating an empty position) or the insertion of a new one. In such cases the list element is selected with the purpose to edit it (figure 2).