Piggydb V4.21 released
Posted: June 17, 2011 Filed under: uncategorized 5 CommentsThis release changes the fragment interface so that the content toggle is disabled when the content to display doesn’t exist.
In older versions, a fragment node box always has a content toggle button (▽) even when the fragment has no content. But clicking the button shows additional information: update-info and fragment-parents as blow:
In this version, the toggle button is hidden when the content is empty, and the additional information that was placed in the fragment body was moved to the fragment header as below:
This change saves you from unnecessary clicks and allows you to traverse your fragment network more smoothly.
Download Piggydb V4.21 at https://piggydb.net/
Piggydb 
Greetings Daisuke
Thanks for this new release. Momentum restored. View by Title now works splendidly; and making the content toggle button conditional on internal content improves ease-of-use.
I believe Piggydb’s new treatment of context parents and update info needs a bit more refinement. The parents were previously shown only with detail content, but the conditional nature of the content toggle means they’re now usually in view with each listed fragment.
In non-hierarchical displays, we have the slider control, which can be set to hide context parents. In v. 4.21, the point on the slider that triggers display of tags also triggers display of context parents and update info. I think displays would be less cluttered if the trigger point for parents and update info were one notch farther to the right than that of tags.
In hierarchical displays, we can toggle the display of each fragment’s children, but display of all parents is now automatic. This to me breaks the coherence and connectedness of the fragments. In the future direction of the program, parent fragments might actually be treated more like child fragments, toggled and displayed in the same manner, as they are really all members of the larger set of first-adjacent fragments. But parent fragments are also similar to tags, in that they are unordered attributes.
I think the best use of space would be achieved by wrapping parent fragments with the tags, in compressed form: the numeric link, the “remove this relationship” control, and a truncated name with a pop-up caption. That’s a personal preference which I may undertake to implement on my own.
But depending on how others feel about automatic display of context parents, perhaps you’d consider a slider that controls the level of detail in hierarchical displays, as we have in non-hierarchical displays. This control would incorporate the function of the global content toggle on the far right, with more granular options.
As Piggydb is so fabulously customizable, I’ve rendered the “up-arrow” context parents invisible through Stylish CSS, with just a small change to the macro to distinguish them stylistically from the always-needed “down-arrow” context parents associated with the top-level fragment on display. So my preferred look and feel is already somewhat in the bag, but I do believe the general user would enjoy a bit more control.
Warmest Regards
Jerome
Hi Jerome,
>I think displays would be less cluttered if the trigger point for parents and update info were one notch farther to the right than that of tags.
It is a great idea. The strength of the slider control. I added it to the issue list – http://piggydb.lighthouseapp.com/projects/61149-piggydb/tickets/14
>This to me breaks the coherence and connectedness of the fragments. In the future direction of the program, parent fragments might actually be treated more like child fragments, toggled and displayed in the same manner, as they are really all members of the larger set of first-adjacent fragments.
Although it is a necessary step to implement conditional content toggle, I was concerned whether the display of parents by default is a little verbose for some users.
With the slider improvement you suggested, it shouldn’t be a problem in non-hierarchical displays, but in hierarchical displays it needs a bit more refinement as you wrote.
There are some points to consider:
-Should parents be treated as the same as children?
–I suspect the number of parents tends to be smaller than that of children.
-Wrapping parent fragments with the tags, in compressed form
–It might be good idea, but I don’t want to treat tags and parents in the same way because it would be confusing. I’m often thinking about the difference between tags and parents, sometimes the border is quite vague and thus it confuses users. I would rather separate these two concept in the user interface.
-In hierarchical displays, I think that basically it is a good idea to display network structure by default to encourage users to be aware of other relationships
-A slider for hierarchical view
–The same as tags and parents, I think that the non-hierarchical view and the hierarchical view should be treated in different ways. The hierarchical view is intended to allow users to browse organized structure, and on the other hand the slider control is used to browse a large number of fragments in a flat (unorganized) way. So I think that a slider for hierarchical view would discourage users from organizing fragments continuously.
Best regards,
Daisuke
Hi Daisuke
You’re right; a slider would not make sense in the hierarchical view, which is built on expansion and exploration of individual fragments.
But, having thought about it some more, I’m convinced that a toggled, expandable view of context parents would work very well, and offer several advantages over the wraparound, link-only view.
Context parents convey valuable information about a fragment; they show, like tags, the sets of which the fragment is a member.
Making these parents expandable would enable the user to show where the fragment is positioned in its other hierarchies. And it would display, at a click, the fragment’s hidden siblings, the other children of a fragment’s context parents. I believe there’s no sure way to do that currently in Piggydb. These siblings are prime candidates for new relationships, and allow the user to ascertain that he’s treating like fragments alike. Example: 12 songs in the hierarchy of a Sondheim show, but we count only 10 of them in the hierarchy of Sondheim songs.
This feature would require a second expansion toggle, probably adjacent to the content toggle, and conditioned on there being at least one parent other than the one already displayed. Expanded parent fragments could get their rows and distinctive icon, and a rule line to separate them from the child fragments.
I think this would be a great capability for Piggydb. And it’s logical. Piggydb is a flattened, recursive rendition of a mind map; a user will want to traverse each node in every direction and with selective expansion points.
That’s my last feature suggestion until your next release, as changes are so much more easily said than done. Piggydb makes a great thought model, and I hope the project continues to be fun and interesting for its developer.
Thanks always.
Jerome
Hi Jerome,
>I’m convinced that a toggled, expandable view of context parents would work very well, and offer several advantages over the wraparound, link-only view. … it would display, at a click, the fragment’s hidden siblings, the other children of a fragment’s context parents.
I agree with you that traversing a tree bottom-up is awkward and not smooth in comparison to top-down in the current Piggydb. But I think that expandable view of context parents would be a little too much and it would be difficult to keep the UI simple and intuitive with it. How about an additional pane, which you suggested before (I just added it to the issue list: http://piggydb.lighthouseapp.com/projects/61149-piggydb/tickets/15)? It would be useful when you want to get a sneak view of a context parent.
And an interesting question arises from this issue: does a relationship really need a direction by default? I have been thinking about this for long time and my current conclusion is “not necessarily”. If each relationship doesn’t have a direction, then you can traverse a tree either top-down or bottom-up in the same way. And there are often cases when you can’t decide the direction of a relationship easily.
Best regards,
Daisuke
Hi Daisuke
A second pane, whose drag-icons communicate with the first, would be a terrific enhancement for a variety of displays. Ideally, that pane could wrap displays you’ve previously written as standalone, opening up all sorts of combinations.
Using a second pane to access alternate parents and siblings of a fragment in focus sounds like a natural fit. Actually, with Piggydb’s hierarchical tagging mechanism, my style has evolved to where the true siblings of a fragment tend to be those fragments that share tags, rather than those that share parents. So that’s another suitable query for a second pane. As for interface, this might be a good candidate for the clutter-saving pop-up menu that follows the cursor.
I’m still convinced of the inevitability of omnidirectional node navigation in the first pane. Perhaps that’s a ways off. But Piggydb is modular, a series of macros that self-execute within a table structure. Which means that once you’ve written a macro, an advanced user can move it around a little!
The second pane is a great direction for Piggydb. I’ll be thrilled to see your implementation.
Best Regards
Jerome