[Design] Visualizing data, Grokking data

[Mimi Yin]

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.
>