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.
Well, the midmapping visual presentation is more easily comprehensible than linear outlines. It doesn't have any special functions that help with that beyond just putting all the nodes you want to see on the same page and grouped according to a scheme in the user's mind, that the user wishes to convey to others sometimes. But the user is herself arranging things, turning complex parts into hyperlinks to separate mindmaps or documents as she chooses; it's not the result of any special functions that handle that intrinsically or automatically. I think I am also suggesting that if you have direct analogues for use type, link type, use and link, then adding the ability for users to assign their own use type and link type to the core relation in the interface (and possibly to the relations for individual subbranches, making them distinct kinds of relations), would provide the ability to use those same use types and link types in the future, making sets of mindmaps (or other interfaces) commonly accessible according to those same terms. You could add that to the standard, "semantics-less" mindmapping that doesn't have any special meaning to the app for the branches other than parent-child isRelatedto. One thing I like is the idea that specific interfaces can be used for particular contexts, as defined by a particular use type and link type combination. So you could assign specific interfaces to specific kinds of contexts, and doubleclicking on a subbranch that's been assigned a certain use type and link type, could automatically open up in an assigned default interface that's tailored well for that "relation." As an example in the graphics I posted on the wiki page, the application at the end designated as "Position Papers" with "Paragraphs" might have a default interface that doesn't look like that screen, but instead a word processing interface. You could also switch to mindmap or outline, etc. as you please . . . As users develop use types and link types that have their associated attributes and interfaces (and as they share such use type/link type contexts so they start becoming "standards" within communities), then I guess I'm saying they would 1) learn to communicate in terms of use types and link types, and 2) create the ways in which information is grokkable, while also universally interoperable. Later I'll peruse the principles you enumerate and see if I have good things to say about them. 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. > > > > > > > Seth > > > > > > > >> Mimi > >> > >> On Jan 20, 2006, at 4:58 AM, Seth Johnson wrote: > >> > >>> > >>> See my comments at: > >>> > >>>> http://wiki.osafoundation.org/bin/view/Journal/ > >>>> TheProblemWithHeterogeneousInformation > >>>> http://wiki.osafoundation.org/bin/view/Journal/ChunkingOverTime > >>>> > >>> > >>> > >>> Seth > >>> > >>> > >>> > >>> Seth Johnson wrote: > >>> > >>>> > >>>> It is possible to think of mindmaps as relations. > >>>> One-to-many > >>>> relations of a parent to children. > >>>> > >>>> I think of relations as particular instances (a "use") of a > >>>> "use > >>>> type" (the parent or "one" side of a one-to-many relation), > >>>> combined with multiple items ("links") of a "link type" > >>>> (the > >>>> child or "many" side). > >>>> > >>>> So let's say you have a mindmap of a project to organize a > >>>> conference on the "unitary executive theory." > >>>> > >>>> The Use type would be "Project" > >>>> The Link type would be "Task" > >>>> The Use would be "Organize Unitary Executive Conference" > >>>> The Links would be individual tasks. > >>>> > >>>> Or: > >>>> > >>>> The parent or "one" entity is "Projects" > >>>> The child or "many" entity is "Tasks" > >>>> > >>>> The links, the "tasks" here, need to be outlinable (unlike > >>>> the > >>>> traditional flat table relational data structure). Hence > >>>> they > >>>> would be mindmappable. > >>>> > >>>> But you can speak generically about relations in terms of > >>>> use > >>>> types, uses, link types and links. I refer to a specific > >>>> use > >>>> type combined with a specific link type as a "context." > >>>> > >>>> Since this is a universal data structure, you can put > >>>> everything > >>>> in it, and since you can outline, you can mindmap as well. > >>>> > >>>> Of course, mindmapping doesn't presuppose that the child > >>>> nodes > >>>> are just one entity type. This is just a good generic way > >>>> of > >>>> talking about and understanding how to model things. > >>>> > >>>> If in fact you want the nodes to be multi-use, you call the > >>>> link > >>>> type something that conveys that, like "Project component," > >>>> and > >>>> the associated attributes would be used to designate what > >>>> kind of > >>>> node they are. > >>>> > >>>> The main thing is that you can speak generically about all > >>>> relations with these terms, knowing that all application > >>>> data can > >>>> fit the abstractions. You just designate the context in > >>>> terms of > >>>> specific use types combined with specific link types. > >>>> > >>>> Seth > >>>> > >>>> Seth Johnson wrote: > >>>> > >>>>> > >>>>> Build a universal data store, and if it provides for > >>>>> outlining, > >>>>> you can put a mindmapping front end on it. > >>>>> > >>>>> I would use the mindmapping interface. The key isn't so > >>>>> much > >>>>> what features will communicate as much as possible, as it > >>>>> is the > >>>>> radial arrangement of manipulable nodes around a center. > >>>>> > >>>>> It can replace the table, so long as your architecture > >>>>> provides > >>>>> for outlining. In fact, I endorse the idea of distributed > >>>>> data > >>>>> architectures that essentially distribute metadata about > >>>>> relations among "entities" while leaving attribute values > >>>>> in > >>>>> place at various servers. > >>>>> > >>>>> Seth -- 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
