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
