Piggydb V5.1 – Two-way RelationshipsPosted: November 10, 2011 Filed under: uncategorized 14 Comments
Piggydb V5.1 has been released almost a month after I announced via Twitter that it would be released soon.
This release adds Two-way Relationship Creation and Display.
The “Create a relationship” dialog has been updated to provide you with more options for creating a relationship: the direction of a relationship, one-way or two-way.
The display of fragment relationships has also been updated to support two-way relationships.
In the above display of the previous version, the relationships are displayed respectively as one-way while the new version provides a cleaner display for two-way relationships:
The user-related actions (“Change Password”, “Logout”) in the main menu have been moved to the pull-down menu at the login user name.
The tag cloud has been updated to exclude system tags that start with ‘#’ in order to focus on the concepts derived from user content.
Greetings Daisuke. This will be quite handy. Very clean confirmation interface. The truncation of fragment names seems a little severe, but I know you may be accommodating smaller screens.
I had a thought in a related area. What would be the feasibility of putting the pop-up fragment menu on fragment links in the sidebar? So, for example, the fragments under Bookmark and Recently Viewed would have the capability of originating a relationship link. (In time, certain user tags or filters might also be designated for a sidebar display of constituent fragments.)
We were talking a couple of months back about why users sometimes use tags where fragment relationships would be more powerful. I think it’s partly because of the extra steps it takes to get an out-of-view fragment into the hierarchy to be a relationship origin/target. We have fragment links all over the screen, as sidebar entries, context parents, internal references. Only the central ones can be expanded, but I wonder whether some of the others could also pick up the fragment menu and originate relationships in place.
Amazed you got to 5.1 without a beta. It’s working perfectly as far as I can tell.
Thank you for your thoughtful comment as always.
As you pointed out, the fragments displayed in the sidebar are mere links and don’t have any functions that the fragments in the main content area have. I also think it is certainly inconvenient. I’m going to fix it in a fundamental way by changing the interface structure, which is kind of related to your suggestion about additional panes.
Yes, I think you are right. But on the other hand, it could be said that tags are valuable because you can easily refer them as keywords and apply them to wider areas, isn’t it?
Actually, I don’t usually release beta versions. The V5.0 was an exception because it added experimental features which I was not sure would work as expected. And as you know, I usually take small steps, which reduces the need of distinction between stable and unstable.
Yes, tags are keywords, enabling us to find our fragments again. Whereas related fragments are for me typically details or examples describing the parent fragment. And a few fragments tend to be repeated connected up. Sounds like your future interface will keep them easily accessible.
I’m embarrassed to say I only just discovered the #pre tag via your blog archive. Had been using a routine all this time to add the ~ character at line breaks to text on the clipboard!
Actually, the special tags are the most unknown features. I feel I should make them explicit in the user interface. Thank you for reminding me of the issue 😉
I’m beginning to think that a horizontal approach to paning would be very elegant. Imagine a Top Bar that is embedded in border-template. Fragments tagged #sticky would be displayed in collapsed form. Those fragments and their descendents are the ones we want always to be able to reach and link to, whatever other fragments and tags we may have up.
Thanks for considering!
Thank you. It is interesting. I’ve been thinking about the idea of “horizontal” too. Not about the layout of fragments, but at a more fundamental level, it’s kind of related to your mention of wide monitors.
I’ve been experimenting with adjusting the maximum length of a fragment title. It seems to be working very well. But I’ve managed to accomplish this only by hardcoding the new value into fragment-editor.htm . So the greater length is available only on fragment updates, not on creation.
Generally I find Piggydb mod points by viewing page source, then running the terrific PRGrep against the source folder to find obvious keywords and edit the correct file. But the keywords around the fragment creation form don’t come up on the grep. I’m guessing they’re part of Piggydb’s binary substructure.
So my two questions for you today are: 1) Is there any functional reason for a user not to change the title length if he prefers it lengthier? 2) Are $titleMaxLength or the fragment creation form set in the binary realm, or can they be user-edited?
Hope all is going well for you.
You can modify the ‘maxlength’ attribute of the title input at HTML level, but not the actual maximum length of title because it is defined in the database schema (200 is the actual maximum).
As I wrote above, since the maximum length is defined in the database schema, it is not technically easy to provide a way to change it. Although you can do it at HTML level up to 200 characters.
The fragment creation form is defined in FragmentFormPanel.htm:
Currently, I’m working on a new version of fragment form, so FragmentFormPanel.htm will be removed in future versions.
Maybe, the current ‘maxlength’ attribute is too short for a title. I will consider whether I should change it. Thank you for your pointing out.
200 characters is just where I set the max, entirely by chance. That feels like a good length to express one idea naturally and compactly. Much thanks.
I wasn’t able to log in to my piggydb under windows xp.
i used the user “owner” and password “owner” but that seems not to be the right password.
I use firefox 8.0.1 as browser, java JRE 6 is also installed.
Never mind. it works now. had another server running on that port and forgot about it.
I hope the close of the year finds you well. A great year it has been for Piggydb.
Small suggestion for an enhancement on the Batch Operations screen, fragment-batch.htm. When a user selects several fragments for batch operations, those fragments may have a number of different parent fragments and tags. But only those parents and tags which the selected fragments all share in common will be displayed in the “Tag” and “Parent Fragment” sidebar widgets.
These widgets offer an “intersect” view. Could they instead display a “union” view? For an n of seven fragments, Piggydb might display
Tag1 (3) ☒ ☑
Tag2 (5) ☒ ☑
Tag3 (4) ☒ ☑
ParentFragment1 (6) ☒ ☑
ParentFragment2 (4) ☒ ☑
Thus it would show relationships that apply to only some of the fragments, allowing the user either to remove them ☒ or apply them to the whole set ☑. The objective of batch operations is usually to get disparate fragments into alignment, and this enhancement would make it easier to categorize like fragments alike.
Thanks for taking a look.
Thank you so much for your support in 2011, especially in this difficult time.
Sorry for delaying new releases. Being interrupted by unexpected events (what an eventful year it has been!), I’ve been struggling to regain the pace. I hope to release at least one new version in this month. Your comments really motivated me 😉
As for the Batch Operations. I’ve been thinking of removing the (slow) page transition from the feature and I will take your suggestion in consideration with this improvement.
We’re indeed pulled in every direction these days, with financial instability, the non-existent career track, and environmental upheaval. And all the pressures on families and relationships. The tyranny of the urgent. Piggydb is a calling, a living creation, a statement of personal excellence. I know you’re enhancing it even when you take a break from it, and that the smallest of changes can quickly reestablish momentum. Our life’s work brings positive energy to our other engagements.
Wishing you and your loved ones and community a fabulous 2012.