Hi Seth,
I have a feeling what you're describing is highly relevant to this
issue, but I'm having a little trouble understanding your proposal.
Could I ask you to define some terminology you use and put them in
the context of specific usage examples?
On Jan 31, 2006, at 2:21 PM, Seth Johnson wrote:
Yes, I did go through and try to come up with something to say,
but didn't have anything in particular. I don't have a head for
visual design so much as for data architecture -- and these days
I "see everything as a nail," if you know what I mean. I do have
some more notions about how attributes and categories that have
"scopes of relevance" translate into useful ways to categorize
data and retrieve it. I'm pretty sure these notions would help
for understanding how to get that high level view that you're
looking for, but I don't know exactly how that works out in
interface terms.
What do you mean by Scopes of relevance wrt attributes?
Assume all "entities" and "relations" are contained in one core
data structure with use types, link types, uses and links that
are definable by users. You indicate that Chandler's data model
is like this.
What constitutes an entity versus a relation? Use types, link types,
etc.
Let's suppose that you can also assign certain scopes of
relevance to attributes ("named labels" that can hold values
associated with a particular "record" -- like "fields"). So you
can have attributes for "child records" (links) that are relevant
(available for capturing appropriate values) to:
any context with x use type
any context with y link type
any context with x use type and y link type
any context with z use of x use type
any context with z use of x use type with y link type
(that is, the attribute would therefore only be relevant
to all links in this particular instance of a generic
context)
v link when used in any context (with any use type, link type or
use)
v link when used in any context with y link type
Etc.
I also apply the same scopes of relevance to categories (I think
these are basically like Chandler tags). Basically, named labels
you declare that can be marked yes or no to indicate whether the
label applies to a "record." Then suppose you could declare that
every time you work on a link (a "child record") in a context
that fits a certain cateogory's scope of relevance, you will be
prompted to indicate whether that category applies to that link
("record").
Is this a proposal for determining whether a particular attribute
applies to an item based on the Kind of that item (ie. All emails
have a From field).
My impression is that a process of designating categories and
attributes that have scopes of relevance like this:
1) will foster people increasingly using common attributes --
and attributes that aren't really specific to flat file
"records," but to any links in any contexts that fall within
their scopes of relevance; and then
I think you've lost me at 'aren't really specific to flat file
"records"'.
Thx! Mimi
2) will foster the development of tools that let you survey
what contexts are using what attributes and categories.
I think that 2) may lead the way to the "10,000 foot, eagle-eye,
contextualized view of our [heterogeneous] data" that you're
looking for.
Seth
On Jan 30, 2006, at 5:45 PM, Seth Johnson wrote:
Mimi Yin wrote:
Yes, what you're describing is Chandler's data model which is then
enriched with a content model that understands about specific kinds
of user data and specific types of relationships between items.
The proposed topic of this thread was to explore ways of
visualizing
this data/content model in a way that is easily comprehensible for
both personal use as well as collaboration.
You can import information of all sorts into the highly generic
framework of relations described as use types, linktypes, uses,
links and their attributes. Then all of them are intrinsically
interoperable. And my point is that these generic notions can
provide the conceptual backbone for the interface, a framework
that is easily understandable, which you make accessible to the
user within any interface you build.
It feels like there are a couple of threads running through your
comments below, let me see if I can address them individually
(please
correct me if I misrepresent what you said):
+ I agree that our approach is to focus on end-user
comprehension of
data visualizations.
+ I agree that this approach is not at odds with ideas about mind-
mapping. Instead it is intended to improve on mind-mapping UIs.
+ The generic framework you describe exists today in Chandler's
data
model (see comments above). I think I was a little confused by your
comments because that wasn't the proposed topic of this thread.
+ In your last point, are you saying that mind-mapping IS easily
comprehensible without further improvements? This would be
interesting to explore further in relation to the design principles
laid down in the wiki write-ups.
A better response than my previous reply:
When I say:
I mean the way you're thinking is in terms of trying to find some
functionality that the app will provide, that will do the
simplifying for grokking that you seek. I suggest that thinking
this way foreshortens:
< SNIP >
3) for mindmapping again, seeing that mindmaps are great for
grokking on the basis of seeing nodes' grouping and arranging and
interpreting that as a human, rather than the app understanding
the grouping and arrangement.
. . . I mean yes, it IS easily comprehensible. I also suggest
some further improvements, specifically to add the semantics you
point out are missing. Since the page in question is about
chunking over time, I'll beg off the visual interface design
question for now and continue to point out some things about data
architecture with respect to genericity, grokkability and
mindmapping. I just added the following comments to the page
(http://wiki.osafoundation.org/bin/view/Journal/ChunkingOverTime):
<Pasted from wiki>
What I think I'm saying is that you can have a generic data
structure and also have semantics. Mindmapping software does not
currently have this, but there's no reason why it can't be added.
The "IsRelated" generic relation can be expanded to terms that
allow users to apply specific semantics to specific relations.
Instead of:
"this node is related to these children"
we have:
"this particular use (Make a birdhouse) of this particular use
type (Woodworking project) has these particular links (get some
wood, measure it, cut it, hammer it together) of this particular
link type (Project steps)"
When people begin sharing contexts defined by these abstraction
they will begin using common use types and link types, thereby
allowing chunking over time that's interoperable. One user will
be able to chunk over time any way she pleases.
Mindmapping in which each branch can be designated with specific
use types and link types, making them each unique relations,
would let you play with information and also begin to make
information usable across particular contexts.
Add to that the ability to visually represent specific such
combinations of use types and link types in their own assigned
default ways. Then make the visual interface (whether mindmap,
email folder, Gantt chart or any other visual interface) provide
access to the use types and link types of the relations.
This doesn't answer the design question of how to visually
represent such disparate types of relations, whether all at once
in one interface or in separate ones, but I hope that it does
give an idea how you can have completely generic relations and
semantics at the same time.
Now, regarding mindmapping -- this interface gives users the
ability to arrange things visually to see relationships by
grouping and to work with and access information that's in flux
as far as how it will ultimately be organized, even if to the
application there are no special semantics to the relations being
created. Now, to add semantics as I describe above and below,
would only augment the traditional mindmapping concept and
interface, as well as all other interfaces. Plus provide the data
structure for chunking.
One note: taking chunking as a function of our human ability to
comprehend visual information, we can observe that mindmapping
naturally leads to that, though without semantics in the
traditional form.
</Pasted from wiki>
Seth
I mean the way you're thinking is in terms of trying to find some
functionality that the app will provide, that will do the
simplifying for grokking that you seek. I suggest that thinking
this way foreshortens:
1) for mindmapping, seeing that it's the particular kind of
functionality it provides that makes it valuable, moreso than the
criterion of how well some functionality intended to simplify
grokking, meshes with mindmapping functionality;
2) thinking about how more genericity in conceptualizing
information, not some function, might give you a better framework
for getting to better grokkability; and
3) for mindmapping again, seeing that mindmaps are great for
grokking on the basis of seeing nodes' grouping and arranging and
interpreting that as a human, rather than the app understanding
the grouping and arrangement.
--
RIAA is the RISK! Our NET is P2P!
http://www.nyfairuse.org/action/ftc
DRM is Theft! We are the Stakeholders!
New Yorkers for Fair Use
http://www.nyfairuse.org
[CC] Counter-copyright: http://realmeasures.dyndns.org/cc
I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication.
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
--
RIAA is the RISK! Our NET is P2P!
http://www.nyfairuse.org/action/ftc
DRM is Theft! We are the Stakeholders!
New Yorkers for Fair Use
http://www.nyfairuse.org
[CC] Counter-copyright: http://realmeasures.dyndns.org/cc
I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication.
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
