DOC: Considerations and Definitions regarding »Interaction Control«
..this collection of ideas, terms and conclusions has been shaped since some time within the TiddlyWiki. Since I've now started even some supporting implementation regarding these concepts, its time to publish them in the design documentation section of the Website
This commit is contained in:
parent
ed76151d14
commit
322467159f
2 changed files with 142 additions and 5 deletions
137
doc/design/gui/InteractionControl.txt
Normal file
137
doc/design/gui/InteractionControl.txt
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
Interaction Control
|
||||
===================
|
||||
:Author: Hermann Voßeler
|
||||
:Email: <Ichthyostega@web.de>
|
||||
:Date: Summer 2017
|
||||
|
||||
This overarching topic is where the arrangement of our interface components meets considerations about
|
||||
https://en.wikipedia.org/wiki/Interaction_design[Interaction Design]. The interface programming allows us
|
||||
to react on events and trigger behaviour, and it allows us to arrange building blocks within a layout framework.
|
||||
And beyond that, there needs to be some kind of coherency in the way matters are arranged -- this is the realm
|
||||
of conventions and guidelines. Yet in any more than trivial UI application, there is an intermediate and implicit
|
||||
level of understanding, where things just ``happen to happen'', which can not fully be derived from first principles.
|
||||
|
||||
It is fine to have a convention to put the »OK« button right -- but how do we get at trimming a clip?
|
||||
How are we assumed to get at trimming a clip? if we work with the mouse? or the keyboard? or with a pen?
|
||||
or with a hardware controller we don't even know yet? We could deal with such on a case-by-case base
|
||||
(as the so called reasonable people do) or we could aim at an abstract intermediary space, with the ability
|
||||
to assimilate the practical situation yet to come.
|
||||
|
||||
interface has a spatial quality::
|
||||
the elements within an user interface are arranged in a way that parallels our experience when working
|
||||
in real world space. With the addition of some minor dose of __ ``hyper'' __ -- allowing for cross connections
|
||||
and shortcuts beyond spatial logic...
|
||||
|
||||
locality of work spaces::
|
||||
but the arrangement of the interface interactions is not amorphous,
|
||||
rather it is segregated into cohesive clusters of closely interrelated actions.
|
||||
We move between these clusters of activity the same way as we move between several
|
||||
clearly segregated rooms confined within a building.
|
||||
|
||||
context and focus of activity::
|
||||
most of what we could do _in theory,_ is not relevant _right now_ most of the time.
|
||||
Yet only when the inner logic of what we're about to do coincides with the things at hand _right now,_
|
||||
only then we might feel _enabled_ to perform our work.
|
||||
|
||||
shift of perspective::
|
||||
and while we work, the focus moves along. +
|
||||
Some things are closer, other things are remote and require us to move and re-orient and reshape our perspective,
|
||||
should we choose to turn towards them.
|
||||
|
||||
the ability to arrange what is relevant::
|
||||
all day long, we do the same stuff again and again, and this makes us observe and gradually understand matters.
|
||||
As we reveal the inner nature of what we're doing, we desire to arrange _close at hand_ what belongs together,
|
||||
and to expunge the superficial and distracting.
|
||||
|
||||
|
||||
Foundation Concepts
|
||||
-------------------
|
||||
|
||||
|
||||
The primary insight is _that we build upon a spatial metaphor_ --
|
||||
and thus we start out by defining various kinds of _locations._
|
||||
We express interactions as _happening somewhere..._
|
||||
|
||||
Work Site::
|
||||
a distinct, coherent place where some ongoing work is done +
|
||||
the [blue]#Work Site# might move along with the work, but we also may leave it temporarily
|
||||
to visit some other [blue]#Work Site#
|
||||
|
||||
the Spot::
|
||||
the [blue]#Spot# is _where we currently are_ -- taken both in the sense of a location and a spotlight.
|
||||
Thus a [blue]#Spot# is potentially at some [blue]#Work Site#, but it can be navigated to another one
|
||||
|
||||
Focus::
|
||||
the concrete realisation of the [blue]#Spot# within a given [blue]#Control System#
|
||||
|
||||
Control System::
|
||||
a practical technical realisation of an human-computer-interface,
|
||||
like keyboard input/navigation, mouse, pen, hardware controller, touch
|
||||
|
||||
Focus Goal::
|
||||
an _order_ or _instruction_ to bring something _into focus,_
|
||||
which also means to move the [blue]#Spot# to the designated location.
|
||||
|
||||
UI Frame::
|
||||
the overall interface is arranged into independent top-level segments of equal importance.
|
||||
Practically speaking, we may have multiple top-level windows residing on multiple desktops...
|
||||
|
||||
Perspective::
|
||||
a set of concrete configuration parameters defining the contents and arrangement within one [blue]#UI Frame#.
|
||||
The [blue]#Perspective# defines which views are opened and arranged at what position and within which docking panel
|
||||
|
||||
Focus Path::
|
||||
concrete coordinates to reach a specific [blue]#Work Site#. +
|
||||
The [blue]#Focus Path# specifies the [blue]#UI Frame# (top-level window), the perspective, and then some canonical
|
||||
path to navigate down a component hierarchy in order to reach the anchor point of the new [blue]#Work Site#
|
||||
|
||||
the Spot Locator::
|
||||
navigating means to move the [blue]#Spot Locator#, in order to move the spot from [blue]#Work Site# to
|
||||
[blue]#Work Site#.
|
||||
The [blue]#Spot Locator# is relocated by loading a new [blue]#Focus Path# leading to another [blue]#Work Site#
|
||||
|
||||
The concept of a __[blue]#Focus Goal#__ has several ramifications:
|
||||
For one it implies that there is something akin the __ ``current Control System'',__ which also could be the
|
||||
_currently active Control System(s)._ Simply because Focus, as the realisation of the _abstract notion_ of the Spot,
|
||||
is always tied to a Control System able to implement it. And when we're able to define generic location coordinates
|
||||
and then __ ``move there'',__ with the help of the `SpotLocator`, we draw the conclusion that there must be a Focus
|
||||
(implementation), somehow getting shifted towards that location.
|
||||
Like e.g. the desired entity to gain the keyboard focus.
|
||||
And, beyond that, the second thing we may conclude is that there need to be some degree of leeway in the way
|
||||
such a Focus Goal can be reached. Since the inner logic of Control Systems can be quite drastically different
|
||||
from each other, we are well advised to leave it to the actual Control System how _actually to fulfil the focus goal._
|
||||
|
||||
To point out an obvious example: it is not a good idea to move the mouse pointer forcibly onto a screen element.
|
||||
Rather, we must use the established mechanisms of switching, scrolling and unfolding to bring the desired
|
||||
target element into the visible area, leaving the last step to the user, which must actively move the mouse
|
||||
onto the target. And we must give good visual clues as to what happened, and what we expect from the user
|
||||
(namely to direct her attention onto the element brought into focus).
|
||||
|
||||
|
||||
Building the framework
|
||||
----------------------
|
||||
|
||||
To create such a system is an ambitious goal for sure.
|
||||
We can not reach it in a single step, since it entails the formation of a whole intermediary layer,
|
||||
on top of the _usual UI mechanics,_ yet below the concrete UI interactions.
|
||||
Especially, we'd need to clarify the meaning of _Perspective,_ we need to decide on the relation of top level frame,
|
||||
individual view, layout, focus and _current location within the UI._
|
||||
On a second thought, building such a system implies we'll have to live with an intermediary state of evolution,
|
||||
where parts of the new framework are already in place without interfering with common conventional usage
|
||||
of the interface as-is.
|
||||
|
||||
UI coordinates
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Especially the focus navigation entails the use of some kind of ubiquitous coordinate system within the user interface.
|
||||
In fact this is more of a topological navigation, since these coordinates describe the decisions and forks taken on
|
||||
navigation down the _Focus Path._
|
||||
|
||||
* [optional] top-level Window (UI frame)
|
||||
* [optional] Perspective
|
||||
* Panel
|
||||
* View-ID
|
||||
* [optional] Group or Tab
|
||||
* local path: `component.component.component`...
|
||||
|
||||
|
||||
|
|
@ -3551,12 +3551,12 @@ The InstanceHandle is created by the service implementation and will automatical
|
|||
&rarr; see [[detailed description here|LayerSeparationInterfaces]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201709091320" tags="design decision Concepts GuiPattern draft discuss" changecount="27">
|
||||
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201710082338" tags="design decision Concepts GuiPattern draft discuss" changecount="36">
|
||||
<pre>This overarching topic is where the arrangement of our interface components meets considerations about interaction design.
|
||||
The interface programming allows us to react on events and trigger behaviour, and it allows us to arrange building blocks within a layout framework. Beyond that, there needs to be some kind of coherency in the way matters are arranged -- this is the realm of conventions and guidelines. Yet in any more than trivial UI application, there is an intermediate and implicit level of understanding, where things just happen, which can not fully be derived from first principles. It is fine to have a convention to put the "OK" button right -- but how to we get at trimming a clip? How do we how we are to get at trimming a clip? if we work with the mouse? or the keyboard? or with a pen? or with a hardware controller we don't even know yet? We could deal with such on a case-by-case base (as the so called reasonable people do) or we could aim at an abstract intermediary space, with the ability to assimilate the practical situation yet to come.
|
||||
|
||||
;interface has a spatial quality
|
||||
:the elements within an user interface are arranged in a way that parallels our experience when working in real world space. With the addition of some dose of //"hyper"// -- allowing for cross connections and shortcuts beyond spatial logic
|
||||
:the elements within an user interface are arranged in a way that parallels our experience when working in real world space. With the addition of some minor dose of //"hyper"// -- allowing for cross connections and shortcuts beyond spatial logic
|
||||
;locality of work spaces
|
||||
:but the arrangement of the interface interactions is not amorphous, rather it is segregated into cohesive clusters of closely interrelated actions. We move between these clusters of activity the same way as we move between several well confined rooms within a building.
|
||||
;context and focus of activity
|
||||
|
|
@ -3593,12 +3593,12 @@ The primary insight is //that we build upon a spatial metaphor// -- and thus we
|
|||
:the focus path specifies the UI frame (top-level window), the perspective, and then some canonical path to navigate down a hierarchy to reach the anchor point of the work site
|
||||
;the spot locator
|
||||
:navigating means to move the SpotLocator, in order to move the spot from work site to work site
|
||||
:the spot locator is relocated by loading a new focus path to another [[work site|WorkSite]]
|
||||
:the spot locator is relocated by loading a new focus path leading to another [[work site|WorkSite]]
|
||||
|
||||
The concept of a //focus goal// has several ramifications: for one it implies that there is something like //"current cotrol system",// which also could be the //currently active control system(s).// Simply because focus, as the realisation of the abstract notion of the spot, is always tied to a control system able to implement it. And when we're able to define generic location coordinates and then //"move there",// with the help of the SpotLocator, we draw the conclusion that there must be a focus (implementation) be moving towards that location. Like e.g. the desired entity gaining the keyboard focus. And the second thing we may conclude is that there is some degree of leeway in the way how such a focus goal is reached. Since the inner logic of control systems can be quite drastically different from each other, we need to leave it to the actual control system //how a focus goal is reached.// To point out an obvious example: it is not a good idea to move the mouse pointer forcibly onto a screen element. Rather, we must use the established mechanisms of switching, scrolling and unfolding to bring the desired target element into the visible area, leaving the last step to the user, which must actively move the mouse onto the target. And we must give good visual clues as to what happened, and what we expect from the user (namely to direct her attention onto the element brought into focus).
|
||||
The concept of a //focus goal// has several ramifications: for one it implies that there is something akin the //"current cotrol system",// which also could be the //currently active control system(s).// Simply because focus, as the realisation of the abstract notion of the spot, is always tied to a control system able to implement it. And when we're able to define generic location coordinates and then //"move there",// with the help of the SpotLocator, we draw the conclusion that there must be a focus (implementation), somehow getting shifted towards that location. Like e.g. the desired entity to gain the keyboard focus. And, beyond that, the second thing we may conclude is that there need to be some degree of leeway in the way such a focus goal can be reached. Since the inner logic of control systems can be quite drastically different from each other, we are well advised to leave it to the actual control system //how actually to fulfil the focus goal.// To point out an obvious example: it is not a good idea to move the mouse pointer forcibly onto a screen element. Rather, we must use the established mechanisms of switching, scrolling and unfolding to bring the desired target element into the visible area, leaving the last step to the user, which must actively move the mouse onto the target. And we must give good visual clues as to what happened, and what we expect from the user (namely to direct her attention onto the element brought into focus).
|
||||
|
||||
!Building the framework
|
||||
To create such a system is an ambitious goal. We can not reach it in a single step, since it entails the formation of a whole intermediary layer, on top of the //usual UI mechanics,// yet below the concrete UI interactions. Especially, we'd need to clarify the meaning of //perspective,// we need to decide on the relation of top level frame, individual view, layout, focus and //current location within the UI.// On a second thought, building such a system implies we'll have to live with an intermediary state of evolution, where parts of the new framework are already in place without interfering with common conventional usage of the interface as-is.
|
||||
To create such a system is an ambitious goal for sure. We can not reach it in a single step, since it entails the formation of a whole intermediary layer, on top of the //usual UI mechanics,// yet below the concrete UI interactions. Especially, we'd need to clarify the meaning of //perspective,// we need to decide on the relation of top level frame, individual view, layout, focus and //current location within the UI.// On a second thought, building such a system implies we'll have to live with an intermediary state of evolution, where parts of the new framework are already in place without interfering with common conventional usage of the interface as-is.
|
||||
|
||||
!!!UI coordinates
|
||||
Especially the focus navigation entails the use of some kind of ubiquitous [[coordinate system within the user interface|UICoord]]. In fact this is more of a topological navigation, since these coordinates describe the decisions and forks taken on navigation down the //focus path.//
|
||||
|
|
|
|||
Loading…
Reference in a new issue