I totally agree with you and did not take it as a judgment at all. I also completely agree with,
I’ve noticed that the act of internalising the app vocabulary often helps some users ‘get’ aspects they hitherto misunderstood
As I reflect on the idea of learning any language, like Italian Vs. Japanese or San Franciscan vs. New Yorker, this internalizastion idea is important. In the later, while they both are using English the dialect, style, and cultural influences and differences between the two often make true communication and exchange harder than one may think. There is HUGE value in learning the native language and terms of a tool or a specific culture. As I write this, I think I’ll add to the Tinderbox for Dummies effort a Rosetta Stone guide. This may help the newbie map their familiar terms to the native language of Tinderbox. Again, specific and native terms are important. As laungauges evolve and specfic terms begin to be used the get specific so that those specific terms, once understood, can be packed with meaning, nuance, and clarity of purpose.
I think one useful thing we can do, prompted by this discussion is perhaps map some of the more popular vocabulary misconceptions differences. It can’t be exhaustive, but I have a sense of several discrete ‘types’ of new joiners. It is a mix of terminology, e.g. someone’s ‘card’ is likely a note (or note text? or both?). On a more structural axis, a note is like a database records and its attributes are like a record’s fields. In broad database terms a TBX is like a flat file database - every record has every field, or for the older, less tech folk, like a pre-printed library index card or rollodex item†.
†. Anyone have a good pic of either of those - might be good illustrations for the proposed docs.
Something useful that might flow out of this is a way to tease out these different starting perceptions so that we can, in broad terms say "if your frame of reference is in these term then you want understand these Tinderbox terms as a rough equivalent and these Help docs, aTbRef pages, etc would help you get started. The point being these will likely differ slightly depending on your start point.
Another axis to capture is the stating task perspective: “I got it as it seems cool and I like what others do”, “Need to build a X” (X being zettelkasten, class schedule, reporting matrix, etc.).
Another angle is coders vs non coders. The former are often confused by what Tinderbox doesn’t have, whereas the others are overwhelmed by what it does have. So yet more start paths.
I’ve no idea if such an approach will work but it might and it may be some of the starting points for some groups don’t exist yet, but we’ll know the useful things to write for that.
Yes, I think that would be very helpful. I think all you approaches are applicable.
As noted on the Saturday call, the breakthrough for me was to realize that a note could have and in fact does have all attributes. Once you understand this you can then better understand the use of prototype as they are helpful in tailoring the visualization and values of a notes’s attributes for a specific note’s context, as in my case organizations vs. features vs. products vs. benefits ecosystem map project. Put another way, all notes are existentially the same, they’re “stemcells.” It is when you put them into context and into purpose that they become a “heart-cell” “muscle cell,” etc.
I especially like the idea of start with a problem, i.e. a “job to be done.” I encourage people to frame their problem with the three Ps: Big P, Med P, SM P. Here is an example, from my personal project,
Big P - Build an industry ecosystem map (orgs, products, features, benefits, people, etc.)
Med P - How do I use conditional queries and actions to manipulate my notes, i.e. use multiple capabilities to perform an outcome.
SM P - how do I use links to pass data back and forth between notes, i.e. how do I sue a specific capability for a specific discrete purpose
Another thing I’m coming to see is lots of people don’t understand (why should they, before the fact) that views are essentially different visualisations of the same underlying data and this cements them unnecessarily into their use of a particular view or subset of views.
So perhaps views also need more explanation in the getting started phase. Not in terms of what they portray but how they simply show the same data in different ways.
Yes, I think that is a good idea. That is one of the points I brought up in the demonstration last Saturday. For instance, for me, I use the different view to visualize the same data and by so doing I can 1) see errors in the data that I would have missed by just using one view, and 2) draw, stumble upon, new insights that I would have missed by just staying in one view. Personally, I find a lot of value in the different views. I still have to play more with the crosstabs and hyperbolic view.
One AHA moment thanks to what @CSH has done: realizing that prototypes are views. All the attributes defined by the Tinderbox system and user are available to each note and so users can ‘view’ attribute sets using different prototypes. A note need not be fixed to one prototype, different facets of the ‘attribute space’ can be activated by selecting a desired subset. @JFallows has often spoken about the value of the ‘attribute browser’ view. We can activate different ‘attribute browser views’ by swapping out different ‘lenses’ . I come from a programming background - it was easy for me to ‘forget/overlook’ that a prototype doesn’t remove any attributes from a note - it just filters a subset of attributes.
Me too. Absolutely loved the recording, sorry I missed the meet-up. Not one but three demo, all advancing the existing usefulness of the app. Excellent and stuff.
Thanks to everyone, and especially the demonstrators.
stuff.