|
|
| |
|
|
| |
|
|
| |
 |
| |
| Input
Device | Input Device Driver |
Menu | Cursor
Control | Keyboard |
Output | Environment
|
|
 |
|
| |
| The Input device
will be a minimum of a two-way or binary switch
(having only two states – ON and OFF) for
both navigation as well as data entry. Common
devices like the mouse are very cheap and
already have the necessary ergonomics and
engineering reliability to take the action
of a binary switch with readymade connectivity
in terms of cabling and device drivers.
We will use one of these, limiting action
to the basic click, either left or right
button, configurable on demand. Support
for even more sophisticated levels of the
mouse and other pointers, and for specialized
gadgets like head-movement devices, that
may have multiple switch functions, can
be added later. |
| |
 |
|
| |
| The Input Device
called Binary Switch will be connected to
the Serial Port of the system.The Input Device
Driver will ride above the system’s default
serial driver. The Driver will have to provide
events such as ON and OFF. In addition, the
driver will also have to provide a fixed number
of user configurable timeout events. For example
the user may configure the driver to return
four timeout events – 10 milliseconds, 50
milliseconds, 750 milliseconds and 1 second
for the OFF position and two timeout events
– 25 milliseconds and 500 milliseconds for
the ON position. In case there are multiple
staggered events, like the example used, the
driver will keep sending the events until
the system eats up (reacts to) an event. If
the system does eat up an event, then the
driver will reset its internal timer. |
| |
 |
|
| |
| The Menu will only
have two levels of options – categories and
sub-categories. If the device is in the OFF
position for <timeout1> period, the
system will automatically cycle through the
categories. When the switch is releases the
option is selected. To cycle through sub-categories,
the switch is maintained in an OFF position
for <timeout2> period. On release the
sub-category is selected.
We must look at ways to utilize the standard
menus built into programs, so that we combine
the functionalities of data entry and navigation
simultaneously. This way we ensure that
a person using the Hawking Communicator
can blend into an organization without necessarily
needing specialized software or hardware.
The concept outlined below calls for the
Hawking Communicator to be a seamless combination
of data entry and command interface, so
that the user is able to enter data directly
into an active application whenever necessary. |
| |
 |
|
| |
| The cursor control
is the default control that is activated when
the system starts up. Basically, the control
has four positions – North, East, South and
West. To cycle through these options, the
switch is kept in the ON position for <timeout3>
period. On release the direction is selected,
and the cursor moves in that direction. On
clicking the switch movement of the cursor
stops.
Alternatively, use a combination of radial
and linear movement. When the cursor is
activated, it will start working, either
from the top left-hand corner, or from wherever
the cursor is at that point, sweeping the
screen, with a transparent line or shadow.
When it points in the right direction, a
second click <timeout3> will activate
the linear action, moving down the radial
line till it reaches the desired area, when
releasing the button will stop it, and the
next click <timeout1> will select
the letter (word, phrase, sentence, command
button). This should get the user to the
desired point faster, with less clicks. |
| |
 |
|
| |
| Option
1 The screen keyboard
will be simulated using the keypad behavior
on modern mobile phones. The keyboard is
a 4x4 matrix of multifunction keys. The
behavior of each key will need to be elaborated,
but will be based on the Siemens S 35 phone.
Also the keys will have different interpretations
based on the current state of the system.
For example — the keyboard will represent
the English alphabet (the default language
of the system) only when the system is in
a mode accepting input — when document is
active, when file names are to be specified.
At other times the keyboard could function
as short cuts to menus — categories and
sub-categories.
Option
2
In the basic data entry mode, sets
appear in easy to navigate palettes. Each
set comprises letters, words (nouns and
verbs etc presented in a standard form each,
the option to modify being automatically
invoked once a choice is made) and phrases
and possibly even complete sentences, plus
extension sets of characters, including
numerals and punctuation marks, depending
on the user’s own preferred patterns of
usage, modeled over time. Thus the “keyboard”
is much more intuitive than an emulation
of a standard QWERTY-based 104-key device
would be.
If the Display area is centered in the
middle of the screen, the palettes can be
placed around it, the exact size of each
palette depending in the number of choices
possible for that path. To get started,
we must have preset standards for assemblages
of words and phrases, which will either
be available in the public domain or will
need to be analyzed from historical data. |
| |
 |
 |
| |
| We need to offer
two basic types of output at all times, viz.,
voice and text. Text should be available in
an environment that allows for easy transfer
to either mode, hence the need for typical
menu items as Cut, Copy, Paste, etc to be
easily accessible. All other standard output
modes will be controlled from the application
being used. Thus Communicator will incorporate
two built-in output modes, and all standad
platform output modes will be accessed by
invoking the commands built into the active
application. |
| |
 |
|
| |
| The Environment
is a transparent overlay on the active screen.
Thus, two applications (Communicator and one
other) are functional and accessible at all
times. Communicator also controls activation
of the other application’s functions, as in
menu items and cursor control. It must always
be trivial to identify where text is being
pasted, thus enabling the process of writing
directly in the other application. Switching
between control of Communicator and control
of the other application needs to be defined
for simplicity.
However, the Environment has a second,
important, context as a text interface.
In this aspect of its functionality, the
user will choose an Environment that will
preselect the most likely choice of words
and phrases needed at that point. Thus,
the user may be in a social situation, or
in the work environment and so on. The throughput
in data entry should therefore be much faster,
since suitable choices will be generated
and displayed rather than inappropriate
ones.
|
| |
 |
|
| |
| Device
Manager|Communicator Driver|Message
Handler|Register Device
Callback|Device Callback
|
| |
|
|
| |
| The Hawking Communicator
interacts with the Input Device(s) as shown
in fig 1.1 below. |
| |
 |
|
| |
| The Device Manager
is responsible for installing and configuring
the various input devices supported by the
system (not detailed here). |
| |
 |
|
| |
| The Communication
Device Driver is the component responsible
for communicating with simple drivers like
the Serial Port, COM Port and the USB driver. |
| |
 |
|
| |
| The Message Handler
manages all the messages for the system. It
handles the messages for Input Devices through
Callback Functions.
Interface
between Message Handler and the Communicator
Device Driver.
|
| |
 |
|
| |
| The RegisterDeviceCallback
function registers a Callback function with
the Communicator Device Driver. This is to
be used by the Communicator Device Driver
to send events back to the Message Handler.
int RegisterDeviceCallback (WNDPROC lpfnDeviceCallback,
int iParams);
Parameters
lpfnDeviceCallnback
[in] Pointer to callback within the Message
Handler.
iParams
[in] Zero for now. Later could be used to
send some parameters.
Return
If the function succeeds the function returns
a non-negative value. If it fails it returns
a negative value with the error code. |
| |
 |
|
| |
| The DeviceCallback
function is the callback that is used by the
Communicator Device Driver to send messages
and events to the Message Handler.
int far DeviceCallback (int iDeviceId,
int iMsgId, long lParams, int iStatus);
Parameters
iDeviceId
[in] The Id of the device sending the message
/ event
iMsgId
[in] The Id of the message
lParams
[in] The low order word will provide the
position (if relevant) of the device in
X coordinates (lower byte) and Y coordinates
(higher byte) respectively in pixels.
The high order word will provide a time
stamp for the event.
iStatus
[in] Will provide status information, zero
for now
Return
If the function succeeds the function returns
a non-negative value. If it fails it should
return a negative value with the error code. |
| |
| FIG
1.1 |
| |
|
| |
Legend:
Orange area represents the unique code that
will be written in the Communicator.
Green area is the comprehensive device driver
for each platform.
Cream area is the standard code and drivers
supplied with devices and platforms. |
|
|
| |
|
| |
 |
|
