|
|
#16
01-13-2005, 08:59 PM
|
|||
|
|||
|
It seems that when one opposes the addition of a feature, it is dictatorial. How else to explain why my position makes me an "ultimate arbiter," while your position is something else? People usually have greater investment in getting their pet features added than in having features excluded, so it follows that the impetus behind opposing features is dictatorial. The consequences are well known. But opposition to features is usually more disinterested than advocacy.
I don't start with the assumption that in-context links are of no use. That would be as "ridiculous" as your beginning with the assumption that they are needed, with the only 'argument' being that "it doesn't take a genius to see the value of being able to link from within a document, rather than creating child links outside the document and having to search through all your child links to find the one document that is related to the keyword of interest." The problem lies your belief that no analysis, no rigor, is required to figure out what features to include, that they can be left to an opinion poll. After all, if software developers think about the product in an integrated fashion, they may end up causing people to change the way they think! Let's stick with UR instead of MyInfo. Some ways UR would suffer if hyperlinks were introduced and users applied them in place of logical linking is 1) The user would lose a synoptic overview of his data structure, because some linkages would fail to be revealed in the child or parent windows or in the data explorer. A separate listing of linked items would fail to disclose the existing hierarchical relations the hyperlinks conceal; 2) Additional procedures that could capitalize on logical linking would either not be developed or would be stunted in their application. For example, logical linkages could be involved in searches, particularly if simultaneous searches on multiple categorical attributes are eventually developed in the program. This would be less apt to get developed, because it would be less powerful and therefore less inviting, if users were tucking away their linkages in hyperlinks. The ability to easily spot things, like the textually based linkages among the child info-items, is what flags are for. Again, make use of what the program offers at its core and develop it, not a string of extraneous ideas imported from NoteStudio. No, I'm not dictating anything. I'm just being cognizant of the complexities of integrating features, including the lack of synergy between some feature sets, as opposed to representing my personal preferences as ideal, without serious argument, and supported only be the popularity of certain features. To me, pounding the podium for certain features because YOU want them is the dictatorial practice. My _argument_ that your style of work is unsound could be weak, but it isn't dictatorial. It only seems so because it is directed against what you WANT. Stephen R. Diamond Quote:
|
|
#17
01-13-2005, 10:11 PM
|
|||
|
|||
|
Stephen,
My comment about your dictatorial tone has nothing to do with your opposition to my feature request. Anyone is welcome to support or oppose any particular feature request, so long as they provide a good argument in support of their position. For example, if I had submitted a feature request for an embedded email client, you would have been able to argue against that feature on the basis that it would lead to bloatware and that email was not consistent with the purpose of UR. The reason I said you were being dictatorial was because your argument against hyperlinks was based on the absurd notion that there is only one correct way to use UR --- YOUR way. We are all individuals and we all have our own organizational strategies. What makes perfect sense to me, may not make any sense to you and vice versa. It doesn't mean that I'm right and you're wrong, it just means that we have different approaches. When you try to impose your approach on me, that's being dictatorial. It seems to me that UR was intentionally designed to be flexible and to accomodate almost any organizational strategy imaginable. Unlike the email example, hyperlinks are indeed consistent with the purpose of UR as they provide the user with an alternate and complementary means of organizing his data. Since UR is a data organization tool, this is consistent with its purpose. So if you don't want to use hyperlinks, don't use 'em....but please don't tell me that I'm wrong for wanting them. Anyway, this horse has now officially been beaten to death. 'Nuff said!
|
|
#18
01-14-2005, 05:51 PM
|
|||
|
|||
|
How much guidance a program ought to give the user in optimising its effectiveness is necessarily a question of degree. It isn't advanced by accusations that the person advocating best practices is for that reason a dictator. As you said in your initial comments, UR's strength is its combination of flexibility and structure. But what combination is optimal? Your lead posting didn't answer that question, and maybe left the impression that optimality is apparent on the program's face. Maybe you even think that; I don't know.
But given that we're after a balance, I think finding and refinding the point of optimal balance will be the result of analysis . Your proposal takes UR in the direction of still greater flexibility, with less structure. I don't know if you are prepared to admit that much, but the weight of my postings on this subject has been to argue that including hyperlinks sacrifices structure too much in favor of flexibility. That we have different positions on this is apparent from the programs we have considered using and where the features we propose come from: Notes Studio versus Idea!--a less structured program and a more structured one (but still relatively quite flexible). It is no doubt true that different points on the continuum are optimal for different users, but that still leaves a question of what's optimal for a particular program, a question that I think sometimes but not always has an answer. It lowers the level of discussion to reduce to an epithet a technical and ultimately quite abstract discussion about whether a feature introduces excessive flexibility at the expense of structure. Stephen R. Diamond Quote:
Last edited by srdiamond; 01-14-2005 at 05:57 PM.
|
|
#19
01-14-2005, 06:09 PM
|
|||
|
|||
|
I think structure is useful up to a certain level of complexity. As my tree hierarchy gets more and more deep and crowded with items, navigating the tree is a less appealing proposition. Not that I won't ever do it, but it begins to take up more time than it did when I had a fairly simple tree.
Logical linking helps quite a bit. I can link items or branches I know I will need to access a lot and put them in a couple of key branches near the top of the tree. I think where the usefulness of hyperlinks comes in is actually at a level that helps tame the complexity of a huge tree. In a sense, it is a way to locate related items by simply using the content of your current item rather than locating and then linking external items. In other words, creating a hyperlink is like a shortcut for: "I know I have 'item x' in my database, and I want to relate it to my current item. So, I'm going to search for 'item x', copy the item, navigate back to my current item, and then paste the logical link." The hyperlink version of this could be as simple as: [item x] To me, it's simply a matter of granularity rather than competing or overlapping approaches. Some users won't need or desire the finer granularity, but many will. Also, different information management tasks require different tools to be immediately available. Filing and retrieving information is well-served by hierarchy and search. Brainstorming or writing alternate interfaces into a set of data is well-served by hyperlinking.
|
|
#20
01-15-2005, 02:20 AM
|
|||
|
|||
|
If I understand you correctly, you really aren't saying "its _simply_ a matter of granularity" (emphasis added), but you are saying there are at least two virtues to hyperlinks, the mentioned granularity and the ease of creation. I'm more persuaded by the ease of creation reason than the granularity one, because the representation of more granular information is one of the standard uses of child items. And I wonder how much hyperlinks can do to tame the complexity of a tree when the main complaint against programs based on hyperlinks is that they become chaotic when the linkages become numerous. Its true--actually a result of some work in network theory--that a combination of ad hoc linkages with hierarchy can greatly reduce complexity, but it isn't clear that this purpose is better served when the linkages take the form of hyperlinks as opposed to logical links.
I think probably when the tree gets too complex even for logical linking, then its time to rethink one's categories and possibly redraw them so they are more like true facets. But the idea of creating a linkage by merely typing an expression is very appealing. If it's possible, I would personally prefer to see faster ways developed to create logical linkages, including by typing an expression. And this is then another way in which hyperlinks would compete for developer time with logical links. Stephen Diamond Quote:
|
|
#21
01-15-2005, 09:30 PM
|
|||
|
|||
|
I guess I was thinking of the web as a point of comparison. While the web could certainly work if browsers simply showed a list of related/child pages in a separate pane, I think that would be less useful than the way it currently works; i.e., hyperlinks within the content.
I'm still not convinced that it has to be an either/or proposition. Granted, functionality should not become so fractured as to compete against itself, which is what I am understanding your objection to be. Perhaps it is counter-productive to mix metaphors, but I always imagined the ideal information manager would allow multiple "overlays" on top of a common data store. For instance, viewing data as a chronology, a hierarchy, a network (web), a list, etc. as shifting needs dictate. I confess I am less interested in strict representations or structures of information than I am in immediate context-sensitive usefulness. Strict schemas do not seem to work that well for shifting, ephemeral data like ideas, brainstorming, etc. For tasks, technical knowledgebases, etc., more rigid structure is of greater benefit. I guess I'd like to meet both needs at once. Quote:
|
|
#22
01-17-2005, 12:12 AM
|
|||
|
|||
|
I also like having different views of the same data. Not just different representations but with different information structuring the data, as with chronologies versus hierarchies and perhaps versus a network view, although I haven't thought much about that. I guess a network view would be like what I understand PersonalBrain presents.
What characterizes a view in this sense is the immediate transformation of the data from one view to the other, which requires in turn that each view contain the same information. What varies from view to view is the salience of particular information. This differs from where different parts of a data structure are represented by means capturing different or partial information. Stephen R. Diamond Quote:
|
 |
|
|
Linear Mode
