One of my previous contributions to PmWiki is a skin called SimpleSkin which, among others, features a popup menu to replace the sidebar, and it works equally well on IE, Firefox, and Safari.
The problem is, and you certainly know the issue, to make it work on IE, I have to resort to special, additional Javascript code to handle it. Not that it is a bad way to do things, but I'm just really dissatisfied with the fact that I have to do special case programming when a perfectly good standard is available, except that it is not implemented well in IE, and have been like that for a very long time already!
The truth is, if there is enough demands from the real and interested users, I will be "enhancing" the multilink code to support IE in the manner that you described in your posting. I'm just not going to do that voluntarily without expressing my view. Remember, this is an open source, unpaid work, so I have the opportunity to make the statement without hurting me financially--and so I did it.
I do understand that making similar statements in a commercial context is much harder. But I have done so as well, and succeeded, in the past, in my role as a Chief Architect and Project Manager in a number of commercial projects. I just want to encourage people to take the risk of being rejected, but try it anyway, rather than not say anything and accept the status quo. You'd be surprised as to how willing the customer will listen to you when you present the option (of not supporting IE completely). This is especially true in *very controlled environments* such as corporate intranets and perhaps open source projects.
I appreciate your suggestions, accept your apologies, and will definitely give your ideas a consideration in refining the multilink implementation.;-)
If everyone insists that being compatible with a broken system is an important goal, then we will never get out of having to write hacks to get a *simple* thing implemented.
We will all be better off standing up and saying, you know what, this does not work well in this environment, so I'll switch and I recommend that you do the same. That's what will change the situation.
Repeating their mantra and saying that we have to follow because they have 80% of the marketshare will simply not help making the situations any better, and will not change the statistics.
Make a difference, be brave, and make a statement about your preferred browser.
If you do that, you will find this a very useful way to organize your links.
With this, you could have many bookmark menus spread in a page that you author yourself, so that you could put all the appropriate context that you want around the bookmarks.
You'll appreciate the usefulness once you give it a try. PmWiki is a very simple to install, and will run locally on your laptop or desktop if you don't have a server. Believe me, I collect a lot of contextual links myself for a living, because I do a lot of research. And the combination of a wiki and multilinks is tremendously useful.
You don't need to apologize, there is nothing wrong in having a civil discussion on an interesting subject.
Let's be clear, it is about an existing, non-revolutionary concept, that has been around since the 60's.
The particular implementation that I have created *is* a dropdown menu. The same kind that you use everyday for accessing many functions in your computer applications--no new or special knowledge is required to use them. But, unlike the typical use, it is made to show multiple destination addresses for a collection of words that appear in a web page and let you follow the ones that seem interesting. What's cool about this is *not* that it is a dropdown menu--as you've pointed out any twelve year olds can do that--but the kinds of pages that you could now easily create that can contain many of these multilinks. I said easily, because the feature is integrated with a wiki, and so creating a new multilink is a simple act of marking up the sentences minimally. Again easily, because the underlying wiki does the independent maintenance of the targets metafile. You do that with your 12 lines of Javascript code one at a time for a few pages with a few drop down menus, each one unique and arbitarily defined by the web user, and you'll soon discover that you need and want a more manageable method to do it. Which is what this allows you to do.
If you don't see the interesting implications there, then, unfortunately, you're not the right audience for this--and for that, *I* would apologize.
Because this is a wiki solution, the targets are stored in a file separate from the context page. The use of a wiki makes it tremendously simple for the end user to define new multilinks and their targets, and also for the web developer to provide and maintain the service--because, as with any wiki, the end users become the maintainer of the context file, the multilinks, and the multilink targets. That is the reason I think wiki is a great platform for implementing multilinks.
Also, each multilink exists as a metafile and has the ability to store numerous other attributes. I'm working on support to record the target contributor's ID, user-voted ranking, and number of click-throughs, to name some useful ones. Also I thought it will be useful, as a proof of concept, to construct a densely linked site on a particular subject, which could demonstrate the usefulness of multiheaded links.
I personally think this is great because this can be used to exercise and test some of the more general hypertext concepts, so we can advance the research effort further with widely available tools.
Sadly, your lack of creativity has prevented you from seeing the benefits of this feature.
This is not about a new concept. As a matter of fact, it is about an existing one that has been a subject of much debate and discussion for many years. Search for generalized multilink, xlink, or extended link if you care to really learn more about the subject.
This is not about being compatible with a popular browser, but about providing the ability to easily create densely linked information contents with a wiki and an implementation of the multilink concept. A wiki is meant to be easily editable. This feature provides a simple markup to put a collection of addresses under a single term, in the context of a page.
You collect addresses in a browser bookmark menu, don't you? When's the last time you actually follow a link from the forest of addresses that you have in your bookmark menu? Never? That's likely. The hierarchical menu is inadequate as the sole method for organizing links.
Instead, this feature will allow you to have many bookmark collections in the context of a page. Therefore you will be able to have meaningful ways to organize the links that you find interesting. More than one way to represent interconnected knowledge, and in exactly the ways that you--the collector and consumer of that information--would want organized. Because you author the collections.
The "mass" is not the people who stubbornly cling to a broken browser. But it includes everyone who are interested in using a simple tool and a good browser to organize information.
This is in no way saying that the current implementation does not need to improve. The great thing is, it does not require magic to make it better. There *are* many existing coding techniques from which this feature can draw improvements, and perhaps even support for other browsers. Noone claims that this is the final answer in multilink implementations.
What you need to do is rethink your employment arrangements and get out of your cube more often so that you could exercise some of your creative muscles more often and stop being shortsighted.
Slashdot Mirror
It is... The code is available at:
n k.php
http://www.pmwiki.org/pmwiki/uploads/Cookbook/mli
One of my previous contributions to PmWiki is a skin called SimpleSkin which, among others, features a popup menu to replace the sidebar, and it works equally well on IE, Firefox, and Safari.
;-)
The problem is, and you certainly know the issue, to make it work on IE, I have to resort to special, additional Javascript code to handle it. Not that it is a bad way to do things, but I'm just really dissatisfied with the fact that I have to do special case programming when a perfectly good standard is available, except that it is not implemented well in IE, and have been like that for a very long time already!
The truth is, if there is enough demands from the real and interested users, I will be "enhancing" the multilink code to support IE in the manner that you described in your posting. I'm just not going to do that voluntarily without expressing my view. Remember, this is an open source, unpaid work, so I have the opportunity to make the statement without hurting me financially--and so I did it.
I do understand that making similar statements in a commercial context is much harder. But I have done so as well, and succeeded, in the past, in my role as a Chief Architect and Project Manager in a number of commercial projects. I just want to encourage people to take the risk of being rejected, but try it anyway, rather than not say anything and accept the status quo. You'd be surprised as to how willing the customer will listen to you when you present the option (of not supporting IE completely). This is especially true in *very controlled environments* such as corporate intranets and perhaps open source projects.
I appreciate your suggestions, accept your apologies, and will definitely give your ideas a consideration in refining the multilink implementation.
Hey, no hard feelings... :-)
I always welcome comments and suggestions.
One more thing...
If everyone insists that being compatible with a broken system is an important goal, then we will never get out of having to write hacks to get a *simple* thing implemented.
We will all be better off standing up and saying, you know what, this does not work well in this environment, so I'll switch and I recommend that you do the same. That's what will change the situation.
Repeating their mantra and saying that we have to follow because they have 80% of the marketshare will simply not help making the situations any better, and will not change the statistics.
Make a difference, be brave, and make a statement about your preferred browser.
If you do that, you will find this a very useful way to organize your links.
With this, you could have many bookmark menus spread in a page that you author yourself, so that you could put all the appropriate context that you want around the bookmarks.
You'll appreciate the usefulness once you give it a try. PmWiki is a very simple to install, and will run locally on your laptop or desktop if you don't have a server. Believe me, I collect a lot of contextual links myself for a living, because I do a lot of research. And the combination of a wiki and multilinks is tremendously useful.
You don't need to apologize, there is nothing wrong in having a civil discussion on an interesting subject.
Let's be clear, it is about an existing, non-revolutionary concept, that has been around since the 60's.
The particular implementation that I have created *is* a dropdown menu. The same kind that you use everyday for accessing many functions in your computer applications--no new or special knowledge is required to use them. But, unlike the typical use, it is made to show multiple destination addresses for a collection of words that appear in a web page and let you follow the ones that seem interesting. What's cool about this is *not* that it is a dropdown menu--as you've pointed out any twelve year olds can do that--but the kinds of pages that you could now easily create that can contain many of these multilinks. I said easily, because the feature is integrated with a wiki, and so creating a new multilink is a simple act of marking up the sentences minimally. Again easily, because the underlying wiki does the independent maintenance of the targets metafile. You do that with your 12 lines of Javascript code one at a time for a few pages with a few drop down menus, each one unique and arbitarily defined by the web user, and you'll soon discover that you need and want a more manageable method to do it. Which is what this allows you to do.
If you don't see the interesting implications there, then, unfortunately, you're not the right audience for this--and for that, *I* would apologize.
Because this is a wiki solution, the targets are stored in a file separate from the context page. The use of a wiki makes it tremendously simple for the end user to define new multilinks and their targets, and also for the web developer to provide and maintain the service--because, as with any wiki, the end users become the maintainer of the context file, the multilinks, and the multilink targets. That is the reason I think wiki is a great platform for implementing multilinks.
Also, each multilink exists as a metafile and has the ability to store numerous other attributes. I'm working on support to record the target contributor's ID, user-voted ranking, and number of click-throughs, to name some useful ones. Also I thought it will be useful, as a proof of concept, to construct a densely linked site on a particular subject, which could demonstrate the usefulness of multiheaded links.
I personally think this is great because this can be used to exercise and test some of the more general hypertext concepts, so we can advance the research effort further with widely available tools.
Sadly, your lack of creativity has prevented you from seeing the benefits of this feature. This is not about a new concept. As a matter of fact, it is about an existing one that has been a subject of much debate and discussion for many years. Search for generalized multilink, xlink, or extended link if you care to really learn more about the subject. This is not about being compatible with a popular browser, but about providing the ability to easily create densely linked information contents with a wiki and an implementation of the multilink concept. A wiki is meant to be easily editable. This feature provides a simple markup to put a collection of addresses under a single term, in the context of a page. You collect addresses in a browser bookmark menu, don't you? When's the last time you actually follow a link from the forest of addresses that you have in your bookmark menu? Never? That's likely. The hierarchical menu is inadequate as the sole method for organizing links. Instead, this feature will allow you to have many bookmark collections in the context of a page. Therefore you will be able to have meaningful ways to organize the links that you find interesting. More than one way to represent interconnected knowledge, and in exactly the ways that you--the collector and consumer of that information--would want organized. Because you author the collections. The "mass" is not the people who stubbornly cling to a broken browser. But it includes everyone who are interested in using a simple tool and a good browser to organize information. This is in no way saying that the current implementation does not need to improve. The great thing is, it does not require magic to make it better. There *are* many existing coding techniques from which this feature can draw improvements, and perhaps even support for other browsers. Noone claims that this is the final answer in multilink implementations. What you need to do is rethink your employment arrangements and get out of your cube more often so that you could exercise some of your creative muscles more often and stop being shortsighted.