Instrumental Device Usage

Disclaimer:

I've been putting this off because I needed to build up enough potential commands to fill a 256 Term Block. I still don't have enough commands, but this is a start. I will be adding (and rearranging) commands as they occur to me.

As always, everything needs testing at the very least and redesign in more than a few cases.

Although, if the interface is too perfect, people may find it cold and inhuman. Fortunately, Instrumentation is almost entirely free of perfection so far.

Introduction

This is the default block which begins with the glyph #FF FF FF 00. This is the Instrumentation Command Mode Block.

This is the Block which will hold the commands which will be used by the users to control everything that happens within the users authority. Once a device has been built that uses a chorded keyboard as it's only manual input (or the syllabary for voice input), a user will need to use these commands to send a message or more importantly, to play solitaire.

This design does not address analog input such as a mouse or joystick. Analog input is needed for drawing images, immersive virtual game-play, and other freehand uses. If motion capture were used to create a virtual keyboard, that same motion capture could be used to simulate a virtual mouse or joystick. Until that final evolution of the technology, analog input will have to be simulated, possibly using a separate flexible 'joystick' thumb button (or one for each hand, imagine the mischief available to someone with two joysticks), or perhaps a touch screen.

This design uses the following eight Types:

These types were previously introduced in the Command Mode initial design. After much internecine warfare, The two lesser conceptual axes were changed from global-local to data-process and from hardware-software to control-creation. This change has re-organized (or re-randomized) the eight Types into the following order.

User Output:

Control

Making things do what you want.

Thing like remote control and the robotic interface. This is also where the Glyphing Bee, Solitaire, and Fortune games would be accessed, because they are controlled by the user.

This is so obviously the Supremacy function that I can't think of any further explanation.

Markup

Creating information, programs and messages from (sanitized) data.

Instrumentation doesn't exactly require 'spell checking', but Markup will provide the editing utilities needed to select and manipulate terms.

This is the minor thing that the prototype does.

Configuration

Keeping your equipment on track.

Communication

Sending data (mostly messages) to other people and machines.

This is not Control, this is just conversation and answering queries.

This is the major thing that the prototype does.

User Input:

Content

Keeping abreast of current events.

Physically all input will need to go through Quarantine (which is part of Communication), but conceptually Content is the sanitized information that results. This is the fodder for your Decision Support System (DSS).

Help

Getting to know all about you.

This is where the expert system should guide you through the solution to your latest problem. Help should teach you to use the system interactively by providing macros and templates to standardize and automate common tasks.

The AI can also create a system of tautologies that would Help it to anticipate your most likely next action. The command that selects that option is found in this block.

Navigation

Keeping track of the facilities available to you.

This covers things external to your device. Navigation will provide information such as GPS coordinates, WiFi gateway availability or printer availability.

Status

Monitoring housekeeping information.

This is a device hardware function. It will provide information about things such as battery level, signal strength, thermal levels, and processor workload.

Status tells you if your device is running at all (assuming that your device is running at all).

This block requires all the laths. That puts it at the back end of the #FF Specialization area.

The terms are organized into four tables, each containing four sub-tables which consist of sixteen cells. Each cell contains a term,  command, a keyword or a link depending on usage.  The headings before the four tables below and the (unique) element combinations that define each sub-table's purpose show the User Output divisions. The four dark rows within each table separate the the sub-categories or sub-tables and contain the (repeating) four User Input element combinations that define the meaning of each individual cell.

This design only shows positive terms. Negative terms would be the opposite of each 'passive' term listed below. If the term is 'active', the negative form will invoke the function or be used to capture the state or current Value.

Cell #00 contains the name of this block of terms, it is used to create the Specialization "Table of Contents". If you select cell #00, you will lock-in this block of terms and you will need to unplug Command Mode to exit, even if these terms aren't commands. I can't think of a reason to select cell #00 that doesn't involve using the Table of Contents to lock-in this block of terms, so I don't see this as a problem.

The "Basic" sub-table is the default because that is where the most common terms should reside. These are the "Left Hand Only" indices (#0[0-F]). The "Right Hand Only" indices are the first (#[0-F]0) terms in each sub-table. Notice also that '5' and 'D' are the most awkward finger combinations so they are used for less critical events (ideally).