Architectural abstractions
Jim
possible aspects:
- Information presented
. Textual
. Visual
. Auditory
. Compound (i.e. combinations)
- System external behavior (see above and below)
. Display/present information
. Take input
. React to events
. Support various devices, both in and out
. Support varying client software?
- User behavior
. Keyboard actions
. Mouse actions
. Tablet actions
. Screen actions
. Voice input?
. Other audio input?
. Video input?
. Device movements? (Wii, iPhone)
Jay Collier
- The content being presented
- The ways people use it, and
- The systems and devices that facilitate the interaction
-Jay
Jim
go to:
http://www.digibarn.com/collections/movies/knowledge-navigator.html
=============
"System" may have been a problematic word choice. If we change the
last sentence to, "The devices that facilitate the interaction", it
may be clearer that we're discussing different ways of thinking about
that which is _observable_. Where the information/content comes from
and goes to is a "magical, invisible realm". (How else could one
describe the Wii experience? ;-)
Until now, we've built our information systems around a set of
functions. Even the most popular Internet sites have developed around
a single medium or a discreet, usually small, set of functions.
Perhaps we can co-opt some psychology terms, and refer to this as the
"functional model".
Clearly, we wouldn't be having this discussion if we thought the
current paradigm were best. What if we looked at our digital world
from the point of view of human actions? A "behavioral model"?
This isn't a new idea. How many of you have seen Apple Computer's
"Knowledge Navigator" video? John Sculley (no, not Steve Jobs) and
crew saw the future two decades ago. You should take a look if you
haven't seen it.
history: http://en.wikipedia.org/wiki/Knowledge_Navigator
video: http://www.digibarn.com/collections/movies/knowledge-navigator.html
Does it change your perception about what we're doing? What's
desirable? What's possible with current technology? Why some
wonderful technologies didn't make it in the marketplace?
We're typing with our thumbs rather than writing cursively with a
stylus. Very, very few of us talk to our computers, for either
commands or dictation. Apple had these technologies. Now they're
either gone or carry on in rudimentary form.
Electronic white boards. Video chat. Electronic drawing tablets.
Available today but hardly used.
Touch screens with gestures, on the iPhone.
All of these technologies were integrated into the Knowledge
Navigator. Which ones really matter in our IKE and which ones don't?
Jim H.
Jay Collier
I think you've gotten right to the heart of the matter. I infer two
questions from what you wrote.
First question, what are the human needs that should be met by an IKE?
Second question: what might that environment look like?
Second question, first. The Apple Knowledge Navigator movie is a great
find; I have seen that in years. More spot-on visions from Alan Kay
and PARC. (I'd recast the actors and choose a different score, though ;)
<http://video.google.com/videoplay?docid=100196171226719096&hl=en>
<http://weblog.infoworld.com/udell/2003/10/23.html>
I hope other conceptualizations will surface, too. Here's one other.
<http://www.youtube.com/watch?v=QcYrPkFe2J0>
As to the first question, I'd like to build on a paper I wrote a while
back.
<http://www.jaycollier.net/portfolio/strategy/fourth-generation.html>
Here's a hypothesis to be considered. Perhaps the experiences chosen
by each individual -- personal, mediated, abstract -- will be the ones
that best satisfy their needs for exchanges that help them thrive.
I'm not a psychologist (although I'd like to play one on TV), so I
would humbly suggest that a simple place to start could be a model
such as Maslow's spectrum of human needs. (I am describing this theory
as a spectrum, because I understand a hierarchical relationship
between them is not supported by quantitative research.) Another
variation of this model has been used by SRI research since the 1980s.
<http://www.sric-bi.com/VALS/types.shtml>
Nevertheless, as an organizing principle, we could state that there
may be realms of human needs which arise throughout a lifetime:
survival/physical, safety/space, belonging/emotion, esteem/mind,
meaning/purpose. (Please look past the specifics for now, if
possible.) Each one involves an exchange with the environment, whether
that environment is physical, personal, or social.
How does this relate to an integrated knowledge environment? I think
we'd benefit by thinking about satisfactory exchanges between people
in these various ways as critical in serving our constituents.
The attributes I've described correlate loosely to a spectrum of human
needs.
<http://sites.google.com/site/ikeproject/home/discovery/attributes>
- Be dependable (survival) -- Is this environment dependable when I
need it, even in an emergency?
- Be intuitive (safety) -- Can I safely navigate this environment
using only my innate intuition?
- Be useful (safety) -- Does this experience help me meet my basic
needs, such as basic procedures?
- Be engaging (belonging) -- Do I feel like participating in this
experience?
- Be personalizable (belonging) -- Can I create my own particular
experience of this environment?
- Be welcoming (esteem) -- Am I valued for who I am?
- Be meaningful (meaning) -- Does this match my values and is it worth
my time?
So, I've stretched this analogy way too far, here, but I wanted to
make the point that, to be successful, I believe we must seek to
better understand human needs, personal and social, first.
From here, I would hand off to those who might engage in debate about
the hypothesis!
-Jay
Steve Moitozo
about abstractions of a system. The three main view-types, and some example
styles within them, used to document aspects of an architecture are:
1) Module - describes the non-runtime software elements (classes, packages,
systems/sub-systems, layers, uses)
Example styles within the Module view-type:
Decomposition - shows how the code decomposes into systems, subsystems,
subsubsystems, etc.
Generalization - think UML class diagrams
Layered - shows the layers of the system and the rules of engagement for each
layer
Uses - shows dependency relationships
2) Component and Connector (C&C) - describes the runtime elements (executable
components) and their relationships (connectors)
Example styles within the C&C view-type:
Shared-data - think persistent data in a single, or consolidated, data repository
Publish-subscribe - think event-driven communication
Client-server - components interacting and requesting services from other services
Peer-to-peer - peer components interacting and exchanging data and services
3) Allocation - describes the mapping of software elements to the elements of
the environment (computer hardware, file systems, development team)
Example styles within the Allocation view-type:
Deployment - maps processes on to hardware
Implementation - maps modules to a development environment
Work Assignment - maps modules to human resources or teams who will
develop/maintain them
As you can see each of the view-types has a number of styles that can be used
individually or in combination in order to present an aspect of an architecture.
A view packet containing one or more views from each of the three view-types
above can be extremely helpful for communicating about the architecture of a
system. Such a packet also provides a way to evaluate both the architecture
itself as well as the implemented systems, or the components being considered
for use as part of the architecture.
For more information about documenting software architecture I recommend the
work coming out of CMU/SEI
<http://www.sei.cmu.edu/architecture/documentation_methods.html>, specifically
the book Documenting Software Architectures, Views and Beyond.
-S2
--
Steve Moitozo II
Software Architect and Manager of Internet Software Services
Bates College
"Opportunity is missed by most because it is dressed in overalls and looks like
work." --Thomas Edison
Are you an Outlook user having problems replying to my messages? Read this:
<http://www.geekwisdom.com/dyn/outlookusers>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "IKE Project Forum" group.
> To post to this group, send email to ikepr...@googlegroups.com
> To unsubscribe from this group, send email to ikeproject-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ikeproject?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Jay Collier
going through it very carefully to do my best to understand.
I've also realized that this thread is moving in two important
directions: architecture of learning (or human development) and
software architecture. I was following the first in reference to Jim's
earlier comment.
Both are important and interesting, and they are certainly
interrelated.
I'm going to close this thread and suggest that these become two new
threads with titles clearly indicating those two areas.
-Jay
> 1KDownload
>
> smime.p7s
> 7KDownload