Interactions
The user will need to be able to work in a visually and interactive ‘hypertextual’ environment.
Note that a Volume can be created, stored and thought of as a list, with further information. This means that a traditional document with headings can become a volume by definition. The need for ‘type’ to be specified for volume and objects is to tell software how to treat the volumes and objects. I propose that no object can exist without a volume, a volume will therefore need to be created to copy/carry a node between volumes.
It needs to be possible to link to an object within a volume.
Knowledge Volume Design
Core (required)
• Name
• ID (name plus time of creation or similar)
• Type (map, defined terms, reference/citation list, desktop/home) Default is simply ‘nodes’.
• ID and locations of enclosed objects as a list (can be empty, but needs to be included to show that it is empty)
Context
• AR location (location in real world, can be coordinates or connection to a named space, with perhaps coordinates in that space, such as ‘left office wall’)
• Owner Volume (if nested)
• Owner Account/Person
• Creator Person
• Creator Software
• Last edited Time
• Created time
• Created place
• Affordances (what the user can do with this volume)
• Physicality (how the ‘world’ in this volume might differ from default)
• View Information and software. (Can be rich and complex, does not need to used by most systems but specified software will be able to use this information. Includes visual information and what metadata to be expected in included objects…)
Knowledge Object Design
Core (required)
• Name
• ID (name plus time of creation or similar)
• Type (desktop icon, map, defined terms, reference/citation list) Default is simply ‘node’.
• Description (general contents)
• Associated icon
• Category (for the user to see as a ‘This is a…’ User or system assigned, such as ‘person’)
• Associated resource(s) (local link to document, URL, citation etc.)
• Owner Volume
• Affordances (what the user can do with this object)
• Physicality (the virtual physical attributes of this object)
• View Information and software. (Can be rich and complex, does not need to used by most systems but specified software will be able to use this information. Includes visual information and what metadata to be expected in included objects…)
Object Spatiality
• XYZ location in Volume
• Size
• Manually connects to list (for user manual connection to other objects)
Object Appearance
• Must be possible to customize colors easily, by the end user.
• Must be possible to customize how much information is shown.