Forum Posts Feed
Who are you? I'm next. (Uly App, Devonthink, Export, Variants, Tags...)
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Jul 3, 2022 at 10:32 AM
43 years ago, I viewed Apocalypse Now (1979): Oh, man! So yesterday, I viewed it again, but it was the about 3:15 (hours, mind you) “Redux” version now, i.e. the new, greatly extended (sic!) cut from the end the last Century.
The brilliant citation is from the added Play Mates in the copter scene, and that already slowed down somewhat, and especially took away the flabbergasting effect of the concert going havoc just before, and which previously had one of the most impressive moments in the movie - so there had been several good reasons to leave this copter scene out of the “original”.
Then, much worse even, the almost “interminable” French plantation scene, much later, about half an hour or so, with lots of the typical, endless, typically French rhabarber-rhabarber from the mouths of the Frenchies in there…
I understand that the co-writer-director wanted to “educate” the viewers of his original-cut masterpiece a little bit, but moviegoers are not into educational broadcasting, for that they have got television - cf. “The Revolution Will Not Be Televised” (1971) though.
I admit Aurore Clément’s eyes were wonderful then, but all those French men, oh my!, and when we finally got into Kurtz’ country, I was literally exhausted, and that’s probably the reason why in some moments then, with Kurtz, I was - now! not in 1979, mind you! - a little bit amused, instead of horrified or whatever…
The reason for this not being my “knowledge” of the film, I had almost forgotten about anything, but certainly not about the doggie scene, and even after 43 years, I “foresaw” it now in whole when it came… it’s certainly one of the most powerful scenes in film’s history - while technically, it’s dispensable, subtext-wise (what was, and did, Viet-nam, “man-to-man”), and also for setting that very same “intimate horror” mood for the viewer, in preparation for “Kurtz county”: just awsome!
And yes, that preparative effect is gone now, too, by that half-hour of “put it down, put it down” with the Frenchies (i.e. scene badly written, don’t blame the actors alone…)... (Cf. Barry Lyndon, cf. Novecento I/II…)
Why this intro? Because
THEY KILLED THE ORIGINAL
After the viewing, I found the wikipedia site, dedicated to this version, and it says that https://en.wikipedia.org/wiki/Apocalypse_Now_Redux that they not only elongated the original version, but re-cut the “master”, they did what you never-ever are supposed to do: They did
DESTRUCTIVE REWRITE
And that’s my point here: How malleable is your “variants management”, how difficult makes your software recouping?
As we have seen from my previous developments, the Uly App makes it tremendously difficult, as difficult as if everything you will have written before was typed on paper, in parts (photo-) copied, and copied, and copied again, and now you will have got a pile of 2,000 pages from which you will have to do even more copies, but from where, and which micro-variants my then be in those parts, while you’re after some other micro-variants but don’t remember that well…?
In other words, Uly App, for serious writing (implying rewriting), is a nightmare: It’s all there, but buried within a mountain of unwanted duplicates, near-duplicates… you’ll become a reader, of your own, discarded stuff, instead of writing, and you will have, in case, to export mountains of text, and then run those hundreds of pages in some “differ” tool, but in a really good one, please, since e.g. the renowned “Beyond Compare” is not able to identify repositioned paragraphs / passages: Hopefully, you have a secretary do help you then, since the girls in that profession don’t know what nerves are, you as a writer might very well do know though.
You will have understood now that backups are necessary to combat drive fails, but not as an acceptable way of your writings’ management: For that, you need cloning instead (not available from Uly App), and ways to group, and filter, items (both “originals” and “clones” - Devonthink = DT calls them “replicants” if I remember well, or was it, better, “replicates”? whatever), and, as said, UR for exemple has got 8 item tree formats by which you can then filter, which is very sparse indeed, but also comes with additional “user attributes” which will help for further “macro” variants management, and the above-mentioned “micro-variants” management, you’ll do mostly within (sic!) your items (you’ll just use the separator lines I mentioned before, not only within the tree, but also within the content fields, together with some “comments”), not by creating a plethora of new items…
In other words, do your editing / rewriting not the “pile up backups which will quickly become inscrutable” way (i.e. do backups for backup purposes, don’t try to misuse them), but the smart, the NON-DESTRUCTIVE way. (The example above will have taught you that “later decisions” are not necessarily better decisions than earlier ones; also, comment all of your decisions in writing, in order to not repeat, or even hang on, mistakes: Always have your own, previous “arguments” for anything ready, for decisions for something, and for decisions against: you might revise both, or find even better reasons to uphold them.
_______________
DT, just like Uly App, is another proprietary and Mac-only db (database), but less so marketed to writers, much more for research and even for office work; there are some very instructive videos on YT for its former use, and that’s obviously the one it applies best to.
They did away with the intermediate tree pane, as is discussed by lengths in the web, and that’s catastrophic indeed for people who want to use it for multiple “projects” or whatever, all within the same db, and so the typical DT user (i.e. the big majority of DT users do that) - judging from what we can learn from the web - divides their stuff into multiple DBs - with decidedly had not been the original idea of DT developers indeed…
Yes, it comes with cloning, as said above, and it also applies different tree entry formats to different tree entries, by (just???) factory-wise, i.e. clones get some special formatting in the tree, etc. - and that’s just one example among several others where this special formatting of the tree entry does NOT make any sense, but, on the contrary, just diverts you from your work-flow, and as my question marks imply, I don’t know for sure if the user can also define their own tree entry formats, according to their specific needs, but I greatly doubt it, so much of what I have said above above Uly App, also applies to DT.
Then, their so-called “AI” is touted by some, but many users tell you it’s (in it current state that is) overrated, and does much less than they would have expected, “just some rules but no real AI” they say - I don’t know anything about it, but those assertions would confirm what I have said repeatedly here, that real AI is just available to big corporations, and they will have a tendency to not give it away, so as to empower competition - you can also see this tendency by any “intelligence” on your “smartphone” needing the “servers” of the app provider, and e.g. by MS having bought Dragon, but without selling as an updated desktop software anymore while on the other hand offering more and more “language services”... online…
So, DT seems to try to “guess” into which “folders” some “document” should be filed, by - probably - counting and weighting words in title, content… and then perhaps comparing with concordance lists it will build; a somewhat trimmed-down “version” of such a concept is offered by some tools, mostly MS Outlook add-ins, which try to file your (outgoing and incoming) e-mails.
DT’s “tagging” concept is similar to what I had thought about tags, too: They say tags are just listings in additional folders (my wording), and that’s indeed what I had and have in mind, since, as I said here, traditional tagging does not preserve any manual, i.e. logic order, presents the “tags” (be that in a tag tree or simple list) just in some mechanical: date of creation of the items or even of the tag for that item, alphabetic / alphanumeric, possibly even in (primal) tree order, or whatever, but in any case, it’s not possible that the user, for some tag or even less so for some tag combination, creates some manual, “logical” order, and that not even for the “current session” = current work situation, let alone a persistent one for the next day, and to whatever a tool currently offers as “stored search”, the same observation applies: You can’t then order the “search results” in a (let alone: persistent) order which would suit your (current, specific) needs -
it’s obvious that the paradigm “a tag is just another listing in an additional folder” can, in theory at least - i.e. not necessarily also in DT’s implementation - make available that, much-needed, according to me, manual sorting, but then, for just ONE tag indeed, unfortunately not yet for tag combinations, so you see there’s room for further research, and I’ve got some ideas indeed on that matter but have not found the time to do the necessary tries with real data; in fact, today, no vendor offers multiple filing (by clones, obviously), those combinations, or, let’s say, the “pertinent” ones among those, then automatically being presented orderly (again simili-tree-wise, i.e. “graph” in so-called tree form), and ready to be manually ordered within these combinational folders, just “new arrivals” then there being added top or bottom, separated by a separator line…
And for one, the difficulty is not so much technical, but conceptional: What system would really be helpful, and “manageable”, for the user, for the management of 5-, 6- and 7-digit numbers of “documents” / items?
And, obviously, such “filing” / “tagging” “targets” (i.e. categories) should be presented to the user when filing, and with a minimum of time required for the actual, multiple filing.
In other words, and I have mentioned this before, it’s the concept of a malleable “tree” (i.e. always “graph”, appearing as tree, with cloning), similar to what askSam tried to do, before its demise, and in its case with just 1, 2 or 3 fields to be combined in any order (of the fields), and then though in linear order of the (creation date of the) “cards” / items, unfortunately - as implied above, multiple, concurrently existing orders, situation-wise, would be no problem whatsoever, technically, with sql (you better use Postgres over SQLite indeed, though), but as said above, DT already did away with the intermediate “tree” pane, despite mostly addressing academics, so the concept described above obviously is very demanding, marketing-wise, risking to overwhelm most users from start on.
_______________
Just a word on export: Most of today’s “text” applications are xml, e.g. Uly App, “modern” versions of MS “Word”, Final Draft (FD), etc., and e.g. UR has - reliable - xml export, so writing in your “presentation” application is not necessary anymore, except if you need internal, exportable links - I’m not sure about DT in this respect though, but probably, more writers would use it, instead of using MS Word, if its internal link management was as good as the latter’s is (at least when you buy some Word add-in)? And it’s interesting that, given in most cases, both applications are xml, i.e. even the exporting one, so few applications have got FD (format) export (the FD format being the standard, much more even than the tool), i.e. developers - except for Scrivener’s and rare others - obviously don’t know how simple it is to write the necessary code, even incl. the “character arcs” and other “newer” FD goodies.
And yes, even in the character arc respect, the above-mentioned, resolutely linear masterpiece was a deliberate exception: “Willard” having specifically killed before, it wasn’t the “river” (’ events) that had to teach him then.
Posted by 22111
Jul 3, 2022 at 02:58 PM
Re multiple-tagging (also touches the atomization problem and the usefulness of one, or even more than one, intermediate “tree” pane; this is obviously about information management, not about “writing”):
You know tag clouds, tag lists, tag trees; the latter present the very same, unwanted characteristic of our “outliners” ‘s: the tree is built just in one specific way then (see above for askSam, etc., to overcome this, also see MS Excel’s and other’s “pivot” functions).
Let’s have an example, a compound of press clippings for “Corona” facts & policies in and from several countries (mid-5-digit number of items for this alone), within a compound of “politics” press clippings. (And no, no “politics” here, you’re safe!)
We have multiple countries, more than 10 even when we “consolidate” most countries into continents, so let’s take u for U.S., e for E.U. (not the set of countries, by the organization and its policy), d for Germany (D is their car plate code), f for France, c for China, and r for all the rest (which is obviously greatly oversimplified already) = 6 values for the geographic dimension.
Then, “national policy” for each of the above? Problematic, since they have distinct policies / applied “measures” with regards to (l = little “L”) “lock down”, to (t) “testing”, to (v) “vaccination in general / recommended vaccination”, to (c) “compulsory vaccination”, etc., and you will also have one (p) “press” category for articles by the press of those countries / regions from above, but which do apply to facts outside of those countries (e.g. German press article re French “corona” policy: geographic code f for France, but policy code d for “from Germany”) - or you even make that an independent dimension, with the consequence that you will multiply “all the rest” (I’ll explain this below) with the number of this dimension (again multiple countries and regions…).
Then, the non-policy but disease and vaccination facts or assumptions, problems or alleged problems with the disease, ditto with the several vaccinations (since they come from 3, 4, 5… different manufacturers, so you will have to differentiate, and will have combinations, i.e. articles which treat some kind of vaccination, but for 2 manufacturers) - besides problems and alleged problems, you will have benefits and alleged benefits, and you will have articles that treat benefits as fake news, and articles that treat problems or alleged problems as fake news, correctly so or incorrectly, who knows, i.e. for each “value”, you have to indicate “pro here” or “contra here” or “balanced” (which is a purely technical “value”, since if later on, a “balanced” article may in fact have been “pro” or “contra”, be that having been on purpose or accidentally)...
Then you have “comparison” articles, which e.g. compare just some aspect, or several aspects of national policy in two or more countries, e.g. “lock-downs” in Germany vs. similar in France, so they are region-wise tagged d and f, and measure-wise (i.e. in the “measures/policies” dimension) l for lock-down, but is it a real (i.e. weighted, commented) comparison, or does it just mention those measures in those countries? The former should get its own additional tag, since otherwise, you would find yourself with too many, indistinct “hits”.
Also, here again, you have the problem to distinguish between application of the measures, and their possible outcome / results, etc., not only “at the end of the day”, i.e. long-term, but you also would need a category “police-related repression”, e.g. of demonstrations against specific measures.
Now, if you try to build up a “tree-form” for this, you’ll get lost, since your main, i.e. “parent”, and for practical reasons, geographic list or sub-tree (regions, “flat” for main regions as list, and then with sub-trees in there for other continents e.g.) will hide all the other dimensions, more or less, or, when “extended”, those will hide all those for any other region, i.e. the switch between the (current) main dimension’s “values” (i.e. categories, but “category” is a term that could mislead, by being mixed up with “dimension” or “sub-dimension”) will not be immediate(ly available), and will “kill” your current “tree” display.
Thus it becomes obvious that you should have available multiple, standard (i.e. stored) (in fact, sub-) “tree displays”, for filing situations, for looking-up situations, with 1-key switching between the different values of the “main dimension” (i.e. you would change by just u, d, f between U.S., Germany, and France e.g.), and it’s evident, too, that these “standards sub-trees” should be created on-the-fly, again and again (and not up-front, by yourself and manually, by copy-and-paste), but only as far as they make sense, e.g. (sub-) dimensions which only apply to specific “parent-” dimensions, should not be automatically replicated where obviously not needed.
Technically, you could implement that in the way that there would be (similar to menu systems) a “full-view” - specific for those “sub-trees”, i.e. for the full tag set - upon request (toggle), and a “rational view”, the latter only displaying those sub-dimensions which you will have either designed (in the full-view) as “standard”, i.e. “show anyway” (because you want this, e.g. while expecting possible entries for those, to come), or, of course, which already have entries, and if ever you have to process an item / document / whatever which will need a non-standard and non-yet-displayed “sub”-dimension, you activate the toggle, so that that dimension will become visible, and henceforward, it will stay visible there (even without being “standard”), since then it’ll have “content”.
When I say “parent” and “sub”, that’s not conceptionally correct, since those dimensions are independent from each other, but “parent” and “child”, and “sub-item”, etc. are traditional terminology of outlining “trees”, independently of the fact that for example, level 2 in your tree or “tree” is a geographic dimension, and level 3 is not another, finer-grained geographic one, but “something completely different”.
And now for endless “pivoting”: Any dimension, or even just “value” within a dimension (e.g. “France”, within the geographic one), should be able to become “tree parent” of any other dimension, and so on, for some “indentation”, “situational parenting” levels, e.g. a tree
- geographic (with the sub-dimensions)
—measures (with the sub-dimensions)
—- reception and evaluation (with the sub-dimensions),
or then, the “same” tree, content-wise, but
- measures (as before)
—reception and evaluation
—- geographic
or
- reception and evaluation
—measures
—- geographic
or even
- measures
—geographic
——reception and evaluation
etc.
And then, attribute- or manually sorted “-”, “—” and “—-”, whatever they may currently be, i.e. we present, and store, “views”, and their elements can be automatically sorted, or then sorted by some “standard but manual” way, e.g. you want countries, or measures, always or in most “contexts” be displayed in some way “of your own” (which is stored as “standard” for some “standard” situations, or even in a “special sort”, in some particular “context”: here again, to store this sort should be possible for the user (and is technically no problem with sql), ditto then for the sorting of the “items”, i.e. those items which do not serve as “dimension values”...
And of course, the latter, as well as the former, should also be user-formattable, not only user-sortable, specific to their respective “context” (situation)...
In other words: Current software just presents you one fixed, prefigured tree display, the different dimensions being captured within their respective indentation level: our “outliners” are 2-, not 3-dimensional.
Then, the developers try to overcome this very noticeable technical limitation (of their code, not of the sql concept), but adding “tagging” and / or “stored searches”, and / or they do “tagging” up-front, i.e. no (fixed) tree-building; in all those escape situations (from the unique, fixed tree or simili-tree, i.e. with cloning, but which doesn’t change the fixed character of your “taxonomy” = top-down, one-way only), the “result” is a more or less flat, and automatically ordered list, not an ephemeral (but in case storable), additional tree.
(Please note that in most situations, it would NOT be necessary to build the whole “tree”, again and again, but just those parts of it which are pertinent to the task at hand, and diminished even by all the items and dimension “values” (“sub-categories”, see above) which don’t correspond to the current, stored “standard” you’re after.)
When, for the tags, I say, ” just automatically ordered”, I had commented on that above, and when I say, “almost flat”, it’s because I don’t know if out there, there’s at least one tool that will somewhat indent the list, which would be technically very simple indeed - I just haven’t seen it yet:
1 tag > you get a flat list of all the items which are tagged that way
2 or 3 tags, etc. > you currently (i.e. from most or all??? tools) get a flat list of the items which are tagged with both / all terms
Instead, tools could factor in the order and combination of the tags in your “search”, and then, build an ephemeral hierarchy (but stored tag-search, obviously, upon request) accordingly, e.g.
france(f)/germany(d) - measure1/measure4 - follow-upA
>
- title f
—title m1A then all f1A hits
—title m4A then all f4A hits
- title d
—title m1A then all d1A hits
—title m4A then all d4A hits
and so on (further and/or deeper);
obviously, you could enter the 5 tags in my example above in different order and/or different combinations, to obtain the same results, but in a totally different “tree”, and please note that in my example, the three different “AND” “groups” are, for clarity reasons, from different dimensions, whilst the two “OR” “combinations” combine tags from the same dimension each, but that you could mix them up freely, the former as well as the latter.
Please also note that for such a system, there would not be any technical enhancements necessary on the tag-store side, just some additional code in the tag-search routine -
you will want to find, and find quickly, any pertinent item, without excluding wanted hits, but excluding unwanted ones indeed, and with current tagging systems, given enough items, you will either end up with unmanageable list, or then with pertinent items being left out because you will not have “tagged extensively enough”... perhaps because of the comparatively bad “availability” of one or some of the necessary tags…
the usual “tag trees” (do not confound the traditional tag tree with my above example of tree-building for tag search results!) often not presenting (all of) the “necessary” tags in the vicinity of the others, and then, the above-detailed “climbing up and down within a too large visible, and mostly containing not currently pertinent (here: for finding the relevant tags to click) part of the tree” problem shows up again: For people who abhor folder trees, and then continuously fight with very similar problems in tag trees…
And you will remember that one of our honoured contributors, just months ago, gratefully informed us that e.g. (his previously beloved tool) CintaNotes didn’t scale that well after all - in fact, its tag tree system is considered to be one of the best out there in the market… but then, traditional tag trees become practically unmanageable by growing (as just explained), and necessarily and in most use cases, your tag needs will accrue with the growing number of your items, and thus, at the end of the day, why should a tag-only based system then be that robust, input-wise, since in that case, the “natural” (not technical but interactional) limitations of the traditional tag (be it tree, be it cloud) concepts (i.e. administration and especially assignment management) would show.
Whichever limit is attained first, as they sometimes say for cloud services of all sorts… ;-)