|
|
#1
01-12-2011, 10:50 AM
|
|||
|
|||
|
UR as 3-pane outliner
UR does make a difference between double-clicking an item, and single-clicking an item. From this starting point, a lot of possibilities arise, and I'm glad they do.
Thus, it's possible to NOT expand an item, in the usual way of other outliners, but in UR you must double-click if you want this behavior. In UR, by just single-clicking, you do not expand the item in the tree, but you just display the the content of the item = text field, for example, and, and here the point of interest shows, at the same time, the item's sub-items = direct children (but not grand-children) are displayed in the related items pane. First, to have this list on the right of your screen, and to the right of the text pane, is not really logical, once you want to use this list not in an accessory way but as an integral part of your working flow. But this is in no way a problem, since that list can perfectly be docked between the tree and the text, so as to show the the "level minus one" of the item selected in the tree. This does not make UR a 3-panes outliner, but it came close... IF you added a rather tiny feature to it. In fact, the above-described workflow would allow users to LEAVE ALONE the sub-items in the tree, thus preserving the aspect of their tree, instead of expanding too many sub-levels in it; it goes without saying that users that want to use UR in the way I'm describing here, should refrain from using too many levels in their tree anyway. But then, there is a real problem, even if people show some necessary discipline in their use of multiple levels: You never know if any of such an sub-item in the related panes list is parent of another sub-tree, or even to one more child only. I know it would ask for much programming efforts to not only display the direct children in the related items pane, but the whole subtree of each selected item - in fact, my other suggestion, i.e. to leave the original tree inchanged whenever you open an item = subtree in another tab (= instead of the original = source tree becoming by any expanding the "outsourced" sub-tree a total mess, in which searching for anything other, e.g. in order for displaying it in yet another tab, is a real pain, as it is the situation up to now, regarding that matter), would do this perfectly, and no real need any more then for my today's suggestion given hereafter - but I think of a solution many people searching for a 3-pane outliner (but not wanting a convoluted graphical interface for this like in Zoot) could perfectly live with: In fact, why not at least program the display of a little SIGN / SYMBOL before any direct child in the related items pane showing, in case, that the direct child in question has (one or more, even multiple) sub-items? This way, people showing some discipline in constructing their different topics in their tree, could use UR as a 3-pane outliner indeed, and when they made the mistake to not flatten out some too tiny sub-trees / single grand-child, UR would thus REMIND them that here and there, there would be sub-items / grand-children they risk to overlook. By "discipline" I mean that whenever it's not necessary to built up a whole sub-tree, people should flatten out their sub-tree, in the way of not doing AAA (= unnecessary parent item), AAAa, AAAb, etc. = unnecessary children, but AAA some thing, AAB ditoo other thing, AAC ditto and another again: I want to say, minute "sub-trees" can most often be replaced by several parallel items in the way of "a," "ditto b", "ditto c", and this way, people could use flags or other symbols for their "topics", so that they would know clicking on them would then display a flat list of those topics' children, but in the meantime, when people need to rearrange many of their topics this way, UR should show then, by such a symbol, that they risk to overlook some sub-features not flattened-out yet. If UR doesn't do this, the related items pane could not be used in the proposed way yet, since people would risk to overlook important information in their tree, proceeding like this; thus, they would unnecessarily have to open, by double-click = expanding the tree, every topic / subtopic in order to make sure there ain't any unseen sub-items. Could you give your opinion, please, regarding this idea? I'm sure a lot of people would be very pleased by its realisation, even when the majority of the current users of a program don't bother to read, let alone comment on, any new feature, may it even greatly enhance the usefulness for other users, e.g. all those who are craving for a 3-pane outliner but do not want the bells and whistles and graphic overdose of Zoot, e.g. (For readers not knowing the outliner market, it should be added that even if we amputated some of your fingers of your right hand, you'll have enough right fingers left to count the few stable 3-pane outliners existing world-wide.) 
|
|
#2
01-12-2011, 10:58 AM
|
|||
|
|||
|
You could display the Has Children attribute in the Related Items pane, and set that customized layout as the default for all templates so that it is always shown.
http://www.kinook.com/UltraRecall/Ma...ditemspane.htm http://www.kinook.com/UltraRecall/Ma...attributes.htm
|
|
#3
01-12-2011, 03:16 PM
|
|||
|
|||
|
But this is tremendous! Couldn't be better!
Unfortunately, as every time I try to understand something from the explanations of the help file, I cannot imagine how to make it work. In fact, I've always been unable to make use of attributes, user or system ones, since I do not understand how to access them. Unfortunately, the caption of the related items pane shows, when an item's direct children are displayed there, doesn't display, by right-click, but "Close", "Floating" and "Auto-Hide", not any way to apply any other command to it; in the line just below, a right-click brings possible columns to choose from (= in the direct list and by "More", but no "Has Children" or something similar to opt for ("Has Reminder" yes, but no "Has Children"), I looked there for some minutes. The same for the menu "View", and then "Columns": seems to be identical, and no "Has Children" attribute there either. In the "Virtual Attributes" page of the help file, there is "These Virtual Attributes include: • Has Children: this yes/no value indicates whether the associated Info Item has Child Info Items or not." but the "Has Children" IS NOT A LINK, so I don't understand how to display it. Of course, I could show the attributes pane and see it there, perhaps, but then, the attributes pane is identical with the "Related Items Pane", so I cannot see the attribute in the former if I want to have my list in the latter. In the above citation, "Info Item" IS a link, but nothing in the target explains my problem. And "Child Info Item" is another link, without any explanation, and it refers to the Data Explorer Pane where there is no explanation again, and this way to the end of my day. Unfortunately, I turn round and round for the most basic things, and please let me say, I NEVER encountered this problem that a complete help file was totally useless for me, with ANY other software in 25 years now of pc use. This is a very unhappy state of affairs since how could 50 p.c. of would-be users benefit of it, suggesting optimistically that the other half at least of them would understand something there? Anyway, a solution-driven approach in the help file would perhaps be useful for many users, in the manner of "You can do this, here's how: step, step, step..." for most regular uses of UR; for the time being, the help file is constructed in the utmost technical way, without my getting what do to by which steps. But be it with the help file as it is, could you please tell me how to display the "Has Children" attribute in the related items pane? Since indeed, it would be the solution to my 3-pane-outliner use of UR, I'd be really glad with that! Oh, and I forgot, since UR HAS the feature I asked for (even if I don't know yet how to make it work), General Discussion would be better than Suggestions, except if you think that "Suggestions" would also apply to suggestions of extended use of existing features...
|
|
#4
01-12-2011, 03:44 PM
|
|||
|
|||
|
See screen recording at http://www.kinook.com/Download/Temp/HasChildren.zip
|
|
#5
01-16-2011, 04:40 PM
|
|||
|
|||
|
Quote:
|
|
#6
02-03-2011, 04:58 AM
|
|||
|
|||
|
yes, goggin, my idea even started some discussion on outlinersoftware com, without giving any credentials of course as it is quite normal for the so-called elite. btw, the thread's move here, from suggestions, clearly indicates that kinook, unfortunately, is not inclined to do anything about enhancing this feature which could indeed be tremendous if developed, pushing UR into a league of its own (cf. the stolen-ideas discussion on that site); but then, this leaves room for other developers to get that concept right, instead of just doing things halfway and by accident.
|
|
#7
02-24-2011, 07:09 PM
|
|||
|
|||
|
My UR display is, from left to right, a) tree, b) children and then, beneath, parents, and c) text (and attributes pane unbound when needed); parents because I rely heavily on clones. And so I discovered that you display that so-much-needed "plus-sign" (for "being parent to at least one child") in the parents pane, where in fact this is redundant information, since if an item is featured in the parents pane, that fact alone proves it has at least one child... whereas in the children pane, that plus sign would be of tremendous help
(in fact, the edit command in the children pane even tries to "edit" the "has children: no/yes" attribute (if you have it as first column) where in reality there's nothing to edit, and editing the title isn't possible, so the earlier we can get rid of that column there, the better). Since the plus sign is possible in the parents pane where it's of no use, it should be realizable in the children pane where it would make UR a real 3-pane outliner! Please consider!
|
|
#8
02-24-2011, 07:15 PM
|
|||
|
|||
|
"Since the plus sign is possible in the parents pane where it's of no use, it should be realizable in the children pane where it would make UR a real 3-pane outliner!"
Sorry, its use in the parents pane is to be clickable, and thus allowing for navigating to siblings of the child item in question: smart! But then, just imagine, this same plus sign in the children pane, not just as an indicator "has / has no children"... but being clickable there, in order to expand that second tree: unbelievable! Please realize that, you're perfectly capable of it, or who would be if it weren't you? (And no, I'm not asking for moving items in the children pane, next, even if I tried and failed...)
|
|
#9
05-01-2011, 03:59 AM
|
|||
|
|||
|
3-pane-outliner
After reading the first post in this Topic, I changed the look of UR I had for 4 years now - and really was surprised about UR again! Good Idea schferk!
Now I am somewhat obsessed to refine this 3-pane look, and after partly-not-so-constructive chat above, I'd like to add my view to UR's 3-pane-useability: Why 3 panes: mostly because the data explorer gets too difficult to navigate when a folder contains dozens of items (in the lowest hierarchy in the data tree, i.e. the leafes of the tree). IMHO we should have an option to exclude this leafes of the tree in the data explorer, and only show them in the child items pane. With that, and the great hoisting features, the useability of the data explorer is back! So the "only" but essential 3 development steps would be, in my opinion: 1) Most important: Option to exclude the lowest hierarchy in the data explorer tree, as stated above (dynamically refreshing!...). I know this is not a new idea, and I do not have any idea what the development problems would be, but as we have hoisting for the roots, this is the logical clean up for the leafes! 2) Correcting the Backspace / "Up One Level" behaviour in the Child items window: When an item is selected, the Up-Button should logically deselect the item = go back to its parent. What it does right now: it jumps back to the parent of the items shown in the child items window (that is: jump up two levels). 3) Graphically appealing: kinook showed nicely how to show the has-children attribute in the child item window. A nice little graphical indicator instead, placed left of the item icon, would just make it feel right! I explicitly do NOT ask for expandability of the tree in the child items window, as I do not see this pane made for it, in my logical understandig. But: the idea of schferk and others for enhancing UR's 3-pane-useability is a great thing (I really think I won't go back to use it in another way most of the time!) Last edited by pawe; 05-01-2011 at 04:26 AM.
|
|
#10
05-03-2011, 03:25 PM
|
|||
|
|||
|
Thank you, pawe. Please let me explain how I use UR.
I I did a lot of favorites, not assigning shortkeys - there are too few of them -, but by expanding the favorites toolbar into a rather long bar, having 2 to 4 clustered symbols in each line of this bar, and then a line before the next cluster, and so on, question of being able to memorize dozens of favorites' symbols. In order to be able to place this bar onto the screen, as a part of the main screen - which normally would not be possible since in this form, the toolbar can NOT be placed into the main frame, but only superposed onto any other element of it! -, I placed a "search menu" to the left of my main tree (= and then, to the right, the main tree, then the children's tree, then the text), that I do NOT need there, but which is a placeholder upon which then I can superpose the favorites toolbar. (The underlying caption of that search menu remains visible, must that's the price to pay.) Then, of course, I activated the option "hoist when showing a favorite", and then, I collected dozens of such favorites, which I activated by mouse click there; this setup not only gives me the additional LOW level (= the children), but also the additional HIGH level, a project level if you might say; of course, it's not possible to place the same favorite symbol, then, into several such symbol groups, but then, you can, of course, place clones of the same CONTENTS into optically identical symbols in different such symbol groups... And then I quickly ran into a limitation of UR: You cannot do but 50 such favorites, even without keyboard shortcuts! (And I would have needed some 150 or so; perhaps 128 would have done...) II Thus, I did a thing I never had imagined I would do someday: I split up my monster UR database into several databases, and of course, I now encounter those information repartition problems UR's strength of being able to handle monster databases without fault was originally intended to avoid. But there are some repartitions that are quite logical, with only a few cloning problems: You can do your computer and programming stuff into one database; you can do your net and telephone stuff into another; you can do your legal stuff into a third one; you can put your tax and social legal stuff into a fourth; you can do your private / psychological stuff into a fifth; you can put your stuff of business 1 (= but without the legal resources and without the site programming but including the site contents) into a sixth; ditto for your business 2 and database seven; you do your religious things (= if there are any) in database 8... and you do a general inbox into database 9, 10... thus, the response times for putting new clips from the web or other are not as overwhelming any more as they were when you had all your stuff in one database... And I have a database for planning and "things to do", but then, in every normal content database, there is a special inbox (= favorite), and another favorite being called "Net / To Do", and which take the clones for any review / task / edit / other needs deep down in the tree there. Thus, I try to do my planning in the planning database, where I strictly refrain from putting any resources in, but of course, this "distributed information architecture" has that weak point, up to now, that my referencing any details in the "real stuff" databases has to be done by hand (= since up to now, inter-referencing in UR is sub-optimal), thus the need for browsing daily the ToDo-Boxes of every real-stuff database, on top of my "general efforts"; here, a "master level", INCLUDING really simple (= and automatically updated!!!) referencing would make UR one of the top programs worldwide, way beyond just outliners. In every of these databases, you can have up to 50 favorites, but in practice, I now use "normal" favorites menus in them, that do not need the additional use of a placeholder menu beneath, but I put that menu vertically to the left upper corner of my screen, and as long downwards as it gets. As for the dozen or so of databases I'm currently using, I've got an additional keyboard where one click will put the database in question onto my screen (I do it by macros control-o filename return, not by going by the UR Window menu, since thus, it works equally if the database in question is loaded into memory yet or not; I admit there are some databases I do NOT check daily, then...). Thus, by the limitation of UR's allowing only for 50 favorites per database, I now encounter a lot of further limitations, being created by UR's not having addressed the question of inter-database referencing yet. And indeed, if UR could give us more than 50 favorites per database, I would re-integrate most of my dozen databases, just having a separate inbox (= from which I distribute the new items 2 or 3 times a week into their right places everywhere, and possible into the more specific inboxes, first, since there's time to do the more specific sorting out when those materials will be needed there), my monster file, and a separate customers' file - those very specific files are always better as files of their own, instead of being interwoven with all your other stuff. Can we have more than 50 favorites per database, since that'll be a lot easier to implement than automatically maintained inter-database referencing, to start with?
|
|
#11
05-04-2011, 08:05 AM
|
|||
|
|||
|
EDIT of the above (cannot edit but within 720 minutes, so here):
1 ) Of course, of my database(s), the root item is a favorite also, and this "hoist when going to a favorite" being ON, I can see the tree in its entirety, or any specified subtree (= by declaring it a "favorite" that is), as quickly as I can do a mouse click. It has not to be said anymore that quick access to any of your actual things, and / or to your "standards", from any point of your work, is of prime importance. 2 ) My menu / toolbar explanations were a little bit opaque, perhaps, thus: Normally, the favorites menu is in menu form, and in this form, you can either have a one-dimensional horizontal symbols line, or a vertical one, but, in both cases, there's only one symbol row / column, you don't have the option to place several, 2 or more, symbols as non-linear groups (= you can use divider lines, but your symbols are one after another only, and even when screen space is not sufficient, you can open an additional menu by mouse click, but there will not be a second row / column). But then, you have the possibility to have your favorites menu in toolbar form, but that toolbar is unbound only, i.e. it cannot be put into the screen mask, but you must put it onto some else element, where, of course, it will bother you, normally. Thus, I took that by-way with placing a (bound) search "menu" as a placeholder, as a ribbon on the left border of my screen, upon which I then placed the favorites "toolbar", also in ribbon shape. Of course, if we had more than just 50 favorites (= and favorites' symbols, then), in such a ribbon, that ribbon must take some more place, but with up to 4 or 5 symbols in a row, on modern landscape screens, that's not a problem, and I would happily sacrifice that screen real estate for that purpose. But then, since my placing of the favorites' symbols onto another menu serving as just a placeholder to imitate a bound behavior of that toolbar, is just a by-way in order to overcome a functional limitation, UR should make it possible to place the favorites menu, also in its toolbar variety, in BOUND way, so that there won't be any other placeholder menu beneath it any more... for 50, for 128, or for any other symbols number's limit in that toolbar.
|
|
#12
08-04-2011, 09:51 PM
|
|||
|
|||
|
Quote:
Thanks, Mark.
|
 |
|
|
Linear Mode
