Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Why isn't there more hyperlinking in web content?

By Louis_Wu in News
Tue Jun 27, 2000 at 09:25:13 AM EST
Tags: Internet (all tags)
Internet

Why isn't the web super-hyperlinked? When an article, a press release, a comment, or a static info page is put on the web, why isn't it saturated with hyperlinks to related information. For instance, if Micro$oft puts out a press release announcing the acquisition of VA Linux, each mention of a person at VA should be a link to her bio on the company website (or a link to her personal website), each company mentioned should also be a link (Slashdot, Kuro5hin, Andover, Freshmeat, ThinkGeek, and of course, SlaughterHouse).


I thought of this when I was looking on the M$ site for info on the .doc format (discussed Sunday on Slashdot), and the press release about the acquisition of Visio by M$. The press release talks about the "Business Productivity Group" which Visio is now part of, Group V.P. Bob Muglia, and even mentions that there are four other business groups at M$, but there is nary a link to these places/people. If I want info, I have to search for it, and that puts off customers/investors. Some intermediate links were on the press release in the M$ press release section, but that info isn't in the Visio page(Bob Muglia is on the executive page, linked on the left side of the press release), but not nearly enough.

I would think that 'High-Tech'(TM) companies would be quick to realize that a Press Release could be used to get More Press if those looking at the press release could easily get to related pages on the web, even if it's just company pages.

Why don't companies do this? Do any? How can we influence people and corporations to make their websites more linkful (full of useful links)?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Slashdot
o Kuro5hin
o Freshmeat
o Micro$oft
o VA Linux
o person
o VA
o personal website
o Slashdot [2]
o Kuro5hin [2]
o Andover
o Freshmeat [2]
o ThinkGeek
o SlaughterH ouse
o M$
o discussed
o press release
o Visio
o Group V.P. Bob Muglia
o business groups
o search
o press release in the M$ press release section
o Bob Muglia
o Also by Louis_Wu


Display: Sort:
Why isn't there more hyperlinking in web content? | 58 comments (51 topical, 7 editorial, 0 hidden)
some reasons (3.40 / 5) (#1)
by bobsquatch on Tue Jun 27, 2000 at 03:36:00 AM EST

N>=2 reasons come to mind:
  1. Changing URLs mean changing the links, or suffering unprofessional broken links on your page. Internal links require maintenance to fix when your site structure changes; external links require maintenance at 3AM when http://www.foo.com decides to push their all-new redesigned site live.
  2. Microsoft really doesn't want to link to linux.com, even if they mentioned Linux in a press release. If you want a competitor's product, you'd best get there yourself, because nobody's going to make it easy for you to give your money to somebody else.
  3. For that matter, the advertising revenue model rewards web sites for keeping browsers at the site. Every internal link is another ad view; every external link is a lost clicker.
  4. It's enough work to write a page; it's another job in itself to find relevant hyperlinks (unless you make liberal use of a search engine, or keep your own list of interesting URLs). I could have hyperlinked every word on this comment, but I have a life.
That's off the top of my head.

Re: some reasons (none / 0) (#32)
by ramses0 on Tue Jun 27, 2000 at 03:14:49 PM EST

So basically the biggest problem with having lots of hyperlinks is that it takes work to maintain them?

This seems to imply that if links were guaranteed to work for free (ie, no maintenance) then people would use them more.

Your point about external clicks causing lost revenue is also a great point as to why external links are not encouraged.

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

Commercial vs. Non-commercial (3.00 / 1) (#3)
by b!X on Tue Jun 27, 2000 at 04:01:36 AM EST

I can understand, although in a cluetrain-inspired sense I disagree with, why commerical/corporate/whatever sites insist either on under-utilizing the medium or on using local links only.

Commercial considerations don't come into play for non-commerical sites, however. But I think there's a general lack of real interest in making full use of the medium across the spectrum.

People are more interested in what new snazzy code-gizmos they can add to their sites than in producing valuable, interesting, and useful content on them.



Yay links! (3.00 / 1) (#5)
by duxup on Tue Jun 27, 2000 at 04:47:14 AM EST

Well when it comes to press releases I think linking probably wouldn't bring much more attention. In my experience press releases are too non technical for most geeks, and too vague for most other people to pay attention. Press releases live in what I call "buzzword limbo."

However, I do agree that more linking would be nice. Personally at work I tend to link fairly gratuitously in documents I create, and often receive complements on it. Part of the problem I think is just lack of knowledge when it comes to work place document linking. Not to say it is hard to do, but it seems that many people just don't know how or see the benefits.

I do think that sometimes too much linking can look ugly. When necessary I index the links at the bottom of the page if there are too many.

obvious... (3.00 / 1) (#6)
by feline on Tue Jun 27, 2000 at 05:43:02 AM EST

in case you hadn't noticed, html coding is a pain in the ass. Who wants to sit around typing '<a href="blah.com">you're not going to come here anyway</a>, it's just a pain. Sure, you can use a shitty editor (as most people that write press releases do anyway), and spend all your time clicking on stuff.

I suppose you could hire some lacky to code all your stuff for you, but that'd just take time.
------------------------------------------

'Hello sir, you don't look like someone who satisfies his wife.'

Re: obvious... (4.00 / 1) (#35)
by Anonymous Hero on Tue Jun 27, 2000 at 03:36:51 PM EST

The answer, as usual, is to automate things. Your organization can compile a database of preferred links, and a user-agent can scan your prepared document to "linkify" it. The operation could even be interactive, if you like, much as a spell-checker is: links are suggested and you can approve or veto them. Categories or templates could be set up and you could choose groups of link categories to include or exclude.

One might even dream of a public link database through which any document could be "linkified", adding annotations for any number of link categories. This is one possible evolution for the classic hypertext search engine. I say that because it's important that link destinations are "trusted", and it seems that public search engines -- and link databases, like Yahoo! -- have generally garnered that status.

A related benefit would be that, as links are increasingly classified and categorized, it would be possible to sort and filter hypertext locations by their link metadata -- including whether or not they are porn. Hence, the user would have more control over the data he/she receives.

Ubu

[ Parent ]
A matter of habituation and tools (none / 0) (#36)
by kmself on Tue Jun 27, 2000 at 03:37:39 PM EST

I disagree strongly. From several years writing on webboards, most of my composition is in HTML, including gratuitous links, and all the rest of it. My editors of choice? -- the text widget in Netscape, and/or vim.

Either a moderate level of technical awareness, or appropriate GUI tools, can make addition of links very painless. I don't think this is the reason for their relative scarcity.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

May cause confusion (3.00 / 1) (#7)
by kahlin on Tue Jun 27, 2000 at 06:40:39 AM EST

I agree that it would be useful in some cases, but I think that people would become fed up with links everywhere. Links are usually rendered in a different color/style, drawing attention from the rest of the content, and that may be annoying after a while (on the other hand, not distinguishing them from the rest of the content isn't a good idea either). A beginner might also be confused by all those links.

Also, for a company with hundreds or thousands of pages, the maintenance of the pages would become very time-consuming as all those links would have to be verified now and then. For advertisement-based sites, linking to other sites isn't always a good idea, as they want visitors to stay at their site.

Used to happen (2.00 / 2) (#8)
by Dacta on Tue Jun 27, 2000 at 06:55:13 AM EST

I remember back in '94 or so lots of articles were written like that. It makes them too difficult to read, because people click on all the links, then come back and can't work out where they were.

It makes much more sense to have a "related links" thing next to a story like kuro5hin does.

Re: Used to happen (4.00 / 1) (#19)
by mcelrath on Tue Jun 27, 2000 at 11:19:34 AM EST

That's why you use two side-by-side browser windows. One to read the original article, and one to read related links. (Netscrape will let you drag a link from one window to another). Salon.com is particularly good at appropriately hyperlinking their articles. Of course, you need a big monitor to do this, but it's a very nice way to browse. ;)

--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 2=0; 1=0.
[ Parent ]

Re: Used to happen (4.00 / 1) (#33)
by mattc on Tue Jun 27, 2000 at 03:22:22 PM EST

I get a lot of use out of the middle mouse button on Linux netscape. It automatically opens the page in a new window. Then I can just alt+tab between netscape windows.

[ Parent ]
It's a lot of work (4.00 / 1) (#9)
by tjansen on Tue Jun 27, 2000 at 07:20:42 AM EST

I used to do this whereever possible when I was an author on linuxticker, but the problem is that it means a LOT of work, and it gets even worse if you do this for permanent documents because links can become invalid. A solution for this would be to use a database that can (for example) maintains persons and their homepages, but that would be a lot of work...

Another problem, at least for commercial web-sites, is that each link that makes the user leave the web-site means less page-views.

Lazy web coders (was Re: It's a lot of work) (4.00 / 3) (#17)
by genehack on Tue Jun 27, 2000 at 10:26:02 AM EST

A solution for this would be to use a database that can (for example) maintains persons and their homepages, but that would be a lot of work...

Actually, it's not that much trouble to maintain such a "glossary", that associates keywords with URLs. Then, before you output 'final' HTML, you do a s/$keyword/$URL{$keyword}/g. (Insert your favorite editor/language version of a global search and replace)

The only problems with this approach are (a) accidentally using a keyword and getting a link instead -- I get around this by only using site names as keywords, or including a 'key' prefix -- and (b) having to re-output your all HTML if a keyword changes -- but that's not a big deal if you're already dynamically generating your pages anyway.

Personally, I like richly linked pages. Many of the reasons I see people giving for disliking them can be summed up as "I'm too lazy" -- link colors/underlining bother me, but I'm too lazy to change my browser prefs, or "it's too hard to code/maintain, so I don't do it" even though decent tools to do it exist, and aren't that hard to develop if you don't like the existing alternatives, or "it's too much information to process/read" which is easiest one to deal with: don't click on the links!

Maybe that's the real problem -- people feel compelled to follow all the links, instead of treating them as suplementary information that's available if you want it

[ Parent ]

Re: Lazy web coders (was Re: It's a lot of work) (5.00 / 1) (#18)
by rusty on Tue Jun 27, 2000 at 11:00:22 AM EST

Actually, it's not that much trouble to maintain such a "glossary", that associates keywords with URLs. Then, before you output 'final' HTML, you do a s/$keyword/$URL{$keyword}/g. (Insert your favorite editor/language version of a global search and replace)

Scoop does something very like this to generate "related links" in the box on the right. It grabs all the links and their text out of the story, but it also looks for keywords and links those if they're found as well. The "glossary" is just a database entry-- "keyword,link" one per line. The admin can add new entries whenever he/she feels like it. That's why you'll notice occasionally website names will be linked in "related links" when they're not in the story. In theory, it wouldn't be very hard to have it stick the links in the story itself, either.

____
Not the real rusty
[ Parent ]

Re: Lazy web coders (was Re: It's a lot of work) (none / 0) (#28)
by genehack on Tue Jun 27, 2000 at 01:38:38 PM EST

Scoop does something very like this to generate "related links" in the box on the right.

That's cool. Is it exact substring matching, or are you doing some fuzzy heuristic stuff? (said the man too lazy to read the code...)

In theory, it wouldn't be very hard to have it stick the links in the story itself, either.

From the general tenor of the replies, you should maybe make that a user-level option. 8^)=

Having the links in the body would be nice -- I typically don't pay a lot of attention to 'peripheral' content like sidebars, unless I'm specifically looking for something -- and it's not really where I'd first go to look for links relating to things in the body text of a story or submission.

john,
just one more feature --- please?

[ Parent ]

Automatic linking (none / 0) (#26)
by mbrubeck on Tue Jun 27, 2000 at 12:54:39 PM EST

The WikiWikiWeb and its WikiWikiClones have an interesting method of creating automagical hyperlinks (somewhat comparable to everything and everything2). Some benefits of the seemingly restrictive WikiWiki LinkPattern are discussed in this page on AccidentalLinking.

[ Parent ]
Re: Automatic linking (none / 0) (#57)
by genehack on Wed Jun 28, 2000 at 04:57:04 PM EST

The WikiWikiThing has also been on my list of Things To Check Out for far too long -- thanks for the reminder.

[ Parent ]

I got something for you (3.50 / 2) (#11)
by Neuromancer on Tue Jun 27, 2000 at 07:25:11 AM EST

Read everything and everything2.

But I wouldn't have to pay the royalties!

Of course, I wouldn't want legal trouble for deep linking either.

Too Much Information.. (3.70 / 3) (#12)
by Pelorat on Tue Jun 27, 2000 at 08:56:27 AM EST

..is not always a Good Thing. Who cares about the bios of the employees of a company that got bought out, if the document is announcing the acquisition and reasons for same to shareholders? It's not a documentary on the lives and times of those employees (who may or may not remain with the company) - it's a business announcement about a large purchase.

Sure, you could hyperlink every word on every page - doing it "because it's there" is great for mountaineers, but isn't always the best course of action for the rest of us. As others have pointed out, it would be hideously complex to maintain.

And there's just no reason at all to have redundant links. If you wrap a link around *every* instance of Microsoft on a given page, you've insulted everyone who views it - you're implying that the reader is too dense to see the first link or to move the mouse back up to it, so it must be repeated ad nauseum to give them a chance to find it.

Because it's annoying. (4.00 / 1) (#13)
by eann on Tue Jun 27, 2000 at 09:31:20 AM EST

It's annoying to create, it's damned near impossible to maintain if you're in charge of more than a handful of documents, and in general, it sucks to try to read, too, because of the way some browsers render things. Ever tried to read a richly-linked page in lynx?

On the other side, however, it's even more annoying to me when press releases, etc., on the web don't link at all. Maybe I do want more information about a company or its officers or whatever, and some domain names aren't always obvious.

A reasonable middle ground is the "related links" that K5 inherited from punctuationland. A nice enhancement would be the ability to add/edit links in that list without actually mentioning them in the article. If I were going to add this here, I'd put something on the "submit story" preview page, and probably work in some syntax for using the <LINK> tag in the original submission:

<LINK rel="related" title="Microsoft" href="http://www.microsoft.com/">

To do it right, as (at least) one other commenter mentioned, there really ought to be a database [table] of external links that can be maintained independently. At that point, it's trivial to have a spider go through the list and check link integrity every so often.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


Knowledge and hassle (3.50 / 2) (#14)
by Anonymous Hero on Tue Jun 27, 2000 at 09:52:04 AM EST

In order to create a link, the page creator must be aware of the target, he must want to link to it, and he must be prepared to create and maintain the link - the latter is a major hassle, especially if the link is external and to a minor site that might move or vanish without warning.

One solution would be to allow out of line links, like HyTime or XLink do. These are links outside the source document that nonetheless link from it it some target (obviously special browser support is needed for this). This would allow one or more databases of links to be maintained separately from the content. www.crit.org (note I couldn't be bothered to do the HTML for that) has such a system for commenting on other people's web pages.

Who wants to be distracted (3.30 / 3) (#15)
by joshv on Tue Jun 27, 2000 at 09:53:10 AM EST

I can type a name into a search engine if I want more info - otherwise the link is too much of a possible distraction.

Ever end of browsing around the web, nested 8 level deep in recursion, and pop back out to where you started, only to find a documented you started to read 2 hours ago (and you are now on the second paragraph)? Not terribly productive.

-josh

Agreed (4.00 / 1) (#31)
by mattc on Tue Jun 27, 2000 at 03:10:44 PM EST

Even a total newbie knows the URL to Microsoft. An article or writeup should be tailored to the expected readership's knowledge level. A kuro5hin or slashdot reader does not need a link to Microsoft home page or the New York Times main page or The Apache Project, because most of us already have their URLs memorized.

What I find most annoying is when there are multiple links in a writeup and I have to hold my mouse over each one to find which really goes to the article the writeup is on. This seems to happen on slashdot more than kuro5hin... someone will have a writeup with a link to the article, but they will also have some of the links going to the company or newspaper that wrote the article. As if we are so stupid we can't figure it out ourselves. New York Times?? Gee, what is that! better bookmark it!

[ Parent ]

Re: Who wants to be distracted (none / 0) (#51)
by Anonymous Hero on Wed Jun 28, 2000 at 05:08:13 AM EST

Ever end of browsing around the web, nested 8 level deep in recursion, and pop back out to where you started, only to find a documented you started to read 2 hours ago (and you are now on the second paragraph)? Not terribly productive.

On the contrary, I usually find that kind of experience very rewarding. It happens to me quite often. If the succession of following links was so interesting that it led me 8 levels deep and made me forget about the orignal article, then the quality of my browsing experience was quite rewarding and productive.

This is one of the things that I find very beautiful about the web: I am not bound by the information found only within one article, nor do I have to read related articles sequentially. Following links can deepen the quality of information I am receiving. Sometimes the other documents add to the original, sometimes following a succession of links satisfies my informational needs and I do not even have to finish reading the original.

Trickster Coyote
(whose newly created account doesn't seem to be working.)

[ Parent ]

Re: Who wants to be distracted (none / 0) (#54)
by Louis_Wu on Wed Jun 28, 2000 at 12:26:02 PM EST

Me too! Uh, whoops, I had an AOL moment there for a second.

When I get that engrossed in a topic, I sometimes forget that there was an original page. And then I go back and finish it, hoping that the original document might have the same quality of information as everything else I was reading. Of course, I sometimes get side-tracked down alleys of sillyness, but that's my fault.

Louis_Wu
"The power to tax is the power to destroy."
John Marshal, first Chief Justice of the U.S. Supreme Court
[ Parent ]

As the guy behind a corporate site (4.50 / 2) (#16)
by error 404 on Tue Jun 27, 2000 at 10:22:13 AM EST

RSViewForum if you are into boring corporate sites about industrial software.

I don't link all that much because I'm not paid to. That site is about my employer's software. I don't want my readers going someplace else. I want the reader to focus on our software. I'm certainly not going to link to a competitor's site. A link to a partner site is a negotiated perk.

That's how it is. I don't like it. The massive linkitude that makes "web" a good metaphor doesn't, IMHO, apply to the WWW we know today. I did a bunch of browsing last night, about half of it commercial browsing for the costume shop my wife owns, and half for fun based on email I received. I don't think I clicked an external link the whole night.


..................................
Electrical banana is bound to be the very next phase
- Donovan

The web page is no longer the proper place for lin (4.00 / 1) (#20)
by SlightlyMadman on Tue Jun 27, 2000 at 11:27:07 AM EST

I think this problem really lies in the evolution of the web. A web page is not what it used to be 5 or 6 years ago (or even 1 or 2 years ago, for that matter). HTML has been stretched too far, way beyond the scope of its design. What we need to do is take a step back, and look towards other technologies to accomplish these goals.

One thing that immediately comes to mind is the little "What's Related" box in the sidebar of Mozilla. I think what we're really heading towards is more things like this. Seperation of content from navigation. We cant rely on the people who are putting up information to create pathways for navigation, as well. Just like you dont go around to hundred of web sites anymore to see if there's anything new up, you check a news site, like this one (or that other site).

I think in 5 years, the "web" will become something totally different, and it certainly will not be entirely HTML and Javascript.

Re: Why isn't there more hyperlinking in web conte (4.00 / 2) (#21)
by Anonymous Hero on Tue Jun 27, 2000 at 11:56:57 AM EST

Because "web" is primarily used to sell s*it, be it products or user's attention (ads). Offering external links would be shooting oneself in the foot.

Which may be used for the Good Thing:

If one had site evaluation s/w (linked to a crawler or search engine interface) that counts external links on a page, some interesting pages can be found. I did some preliminary semi-manual setup, and it seems to work.

You simply set the threshold and use the system to filter, say, search engine results. Sites with proportionaly more external links do tend to be better sites.

This is, of course, the next level of semantic filtering. Relying on the content alone (or meta tags) is not so useful anymore. Other criteria may be the number of animated gifs or "best viewed with this or that html client" etc.

too many links (3.50 / 2) (#22)
by l4m3 on Tue Jun 27, 2000 at 12:21:25 PM EST

Articles are not overly hyperlinked like your example because that is no worse than borderd frames, its a sign of horrid web design. People have a tendancy to follow links, if you fill your text with them they will follow each one, and never make it through what you are trying to say.

It is similar to a legal document they write out the full company name once at the top and from then on refer to them by a short name. Links should be the same way, each time you mention Microsoft you do not need to link to them, its redundant, and confusing.

This is somewhat a matter of taste, but it is also a matter of cultural idioms. Most web users are not able to deal with sites that overly link, they get lost, get frustrated, and they eventually leave.

Re: too many links (5.00 / 2) (#23)
by genehack on Tue Jun 27, 2000 at 12:37:08 PM EST

Most web users are not able to deal with sites that overly link, they get lost, get frustrated, and they eventually leave.

Bah. Following that argument to it's logical conclusion, we should just sit back and let the TV-ification of the web happen by default.

Imagine -- try to imagine, just for a minute -- that there's a point to putting things on the web to inform people. That you don't particularly care if they stay on your site, as long as they're learning something. Imagine that you're out not just to inform your audience, but entertain and challenge them at the same time.

Given the above, I think frequent hyperlinkage is not only useful, it's almost required. Yah, you don't want to turn every "Microsoft" into this, but it should be linked at least one of the times you mention it.

Good, effective hypertextual writing is hard, just as hard as good linear writing, but in a different way. However, just because it's hard doesn't mean people should avoid it -- it just means they have to think about how to do it, and work hard at it, and not assume that good linear writers will make good non-linear writers.

We've already got a hugely popular mass medium for telling linear stories -- it's called television. We don't need the web to be that too.

john,
not old enough to be this crotchity.

[ Parent ]

Re: too many links (none / 0) (#46)
by hypatia on Tue Jun 27, 2000 at 11:35:25 PM EST

Good hypertextual writing is hard, just as hard as good linear writing, but in a different way.

For that matter, good hypertextual reading is hard. The original poster made a valid point. It took me a very long time to learn that whilst reading most heavily footnoted academic works, there is no need to read most of the footnotes.

How best to indicate to the reader/user the status of the links, and the way in which the hypertext was meant to be read? To draw on the footnote analogy again (I know it's not perfect), Virginia Woolf writing in Three Guineas intended that the footnotes be read, since they contain interesting digressions, anecdotes and ideas, as opposed to citations. Many texts contain a proportion of both, and it's annoying to follow a 'link' you thought would be interesting, but is instead, short, dry and factual.

Is indicating the type of different links with visual cues feasible or useful? Probably authors would implement them differently anyway... Should the reader pick it up from subtle cues? One idea is to have an attribute of link tags be a longer description of the content of the link, say a link reading 'Fred Foo' might have a CONTENT attribute reading 'Professional resume of Fred Foo' or 'Fred Foo's vanity home pages - includes large images', or so forth.

But again, we rely on the skill of the author. I guess this is inevitable (and possibly desirable).

[ Parent ]

signal to noise (5.00 / 1) (#24)
by Anonymous Hero on Tue Jun 27, 2000 at 12:41:03 PM EST

Links signal references the author considers important. If there are too many links, you have no way to know what's really important and what's a gratuitous link.

Also, good links take time and effort to track down. I'd rather see one definitive link than ten stupid ones...

I agree that commercial sites tend to skimp links in an attempt to manipulate the reader to their benefit. This sucks, but other things they do suck worse. Next time I see a hardware vendor that forces you to choose between "home/office/commercial" before they let you know what products they have available, I think I'll scream.

HTML Linking Is Too Limited (2.50 / 2) (#25)
by Anonymous Hero on Tue Jun 27, 2000 at 12:52:25 PM EST

The main reason for the paucity of linking is the severely-limited functionality of HTML linking. The potential of linking will explode when XML documents are common, because it will provide advanced features including (but not limited to):

  • two-way links: allow links that can be traversed in either direction, so that linkers do not simply lead readers away from their own content
  • many-to-many links: many different link locations can be associated with individual data components, which allows several different link "meanings" to be embedded in metadata. One viewing mode could simply link to company names, another could link to word definitions, and another could link to historical background
  • better addressing: HTML addressing is limited to individual pages. XML linking can address individual tags within pages or XML databases, meaning that linked information can be compiled in whatever fashion the linker chooses. A database of company profiles could be queried on the fly for a select group of matches with a single link, and could be dynamically built into a separate frame, for instance. Entire documents could be built from other, totally separate documents, by addressing individual components within.
One example I like to use is that of a study Bible, because it is typically extremely thick with metadata. The author could embed multiple links for each content item; one for Greek translation, one for related passages, one for Matthew Henry commentary, one for NIV commentary, &c., &c.

Hypertext linking is actually a pretty well-explored field, outside of the Internet. The oft-repeated adage is that "XML will bring Internet hyperlinking into the 1970s".

Ubu

Re: HTML Linking Is Too Limited (none / 0) (#27)
by genehack on Tue Jun 27, 2000 at 01:04:07 PM EST

HTML addressing is limited to individual pages.

Um, no it isn't. Look in any decent HTML reference about the use of the NAME attribute of A elements. In fact, I bet with the right server set-up, you could use named anchors ( index.html#name ) to pass query info into a database server, to dynamically generate content, as you describe.

As far as two-way links, we also already have that. It's called the 'Back' button. Yes, yes, I realize that that's not quite the same thing. However, I don't care how spiffy XML is, reciprocal linking is still going to require the consent of the authors of both pages -- and given that, two-way links are possible now -- you just have to mail someone and say "I'll link you if you link me". FWIW, in the weblog world, we call that being a 'link slut'.

Finally, many-to-many links sound like a great idea -- how exactly are you going to implement that in a non-sucky way, on the interface level?

john,
musta got up on the wrong side of the bed.

[ Parent ]

Re: HTML Linking Is Too Limited (none / 0) (#30)
by Anonymous Hero on Tue Jun 27, 2000 at 03:00:17 PM EST

The first issue was NAME attributes. NAME attributes are a way of specifying that the browser should scroll to a particular point in the page. That is not the same thing as sub-document addressing for links. It is still per-document addressing with an additional notation for browser presentation.

Furthermore, the NAME attribute indicates nothing more than a dimensionless placeholder. You couldn't use them for database queries because they indicate a fixed position; they're not tied to specific tags, ranges, or other addressable quantities.

Your second issue, the BACK button, is a browser construct used for convenience. I don't think you understand the potential of real two-way links, which can be used by either end of a link to truly tie documents together. This is not a browser issue, it is an information theory issue. The BACK button is simply a stack operation in a particular user-agent; it's hardly comparable. Think about it: for one thing, the BACK button requires physical traversal of a group of linear nodes, in order, for its operation to work correctly. By comparison, two-way links can tie an infinite number of addressable units within as many separate documents to each other, and those links can be traversed out-of-order by any user-agent, not just a human-operated one.

As for the third issue, implementation of many-to-many links, the presentation is up to each individual user-agent, and dependent upon the particular XML application. One of XML's strongest advantages is that it separates data from presentation; likewise, HTML's greatest weakness is that it inextricably ties data to presentation.

In XML, links simply declare a relationship between two pieces of data. How that relationship is interpreted or displayed is entirely up to the user-agent. For instance, the study Bible user-agent could present a selection widget for changing between various link modes, depending on the user's inclination. I would consider this a rather trivial use of the technology. A more complicated user-agent might produce summary reports from large collections of linked data, using link-interpretation heuristics in a user-provided document. If you think about that carefully, you'll realize that I'm describing -- among other things -- a search engine.

Ubu

[ Parent ]
Re: HTML Linking Is Too Limited (none / 0) (#34)
by genehack on Tue Jun 27, 2000 at 03:28:46 PM EST

(clipping quotes extensively...)
You couldn't use them for database queries because they indicate a fixed position; they're not tied to specific tags, ranges, or other addressable quantities.

My point, which you ignored, was that they could be frobbed, at the server level, to do exactly that. Go back and re-read the last sentence of my first paragraph.

The BACK button is simply a stack operation in a particular user-agent; it's hardly comparable.

And that would be why I said "I realize it's not the same thing". I notice you completely ignored the real issue I raised, so I'll bring it up again: how is XML going to make implementation of two way links between pages 'owned' by different people any easier than it is now? The authors are still going to have to communicate, and they could do that now, and set up reciprocal links quite easily. People do do this. It's called a "hey, look, here are my friends with web pages" web page.

As for the issue of non-linear traversal -- I'm interested in making the web better for humans. Humans travel linearly. They can go over multiple paths -- simultaneously -- but each one is linear. If I'm on Page A, and I go to Page B, and I want to go back, I go to Page A -- via the back button. If go to Page C and then want to go back to A, I'd still have to go back to B, even if B had a two-way link with A, correct?

I'll agree, everything you're talking up will be wonderful -- for intra-site navigation. I still don't think it buys us a damn thing for intersite navigation, except more complexity in the authoring and browsing interfaces. How does this help someone who cruises both K5 and the Other Place when a similar topic comes up? Who's going to put in all these multi-level two-way sooper dooper links?

implementation of many-to-many links, the presentation is up to each individual user-agent, and dependent upon the particular XML application.

So, let me paraphrase: "We're physicists; we come up with the stunningly great ideas, and it's up to the engineers to implement them." Newsflash: you can have the greatest hypertextual doodad ever, and if the interface sucks, you're gonna crash and burn (and the field is littered with the craters of poorly implemented systems -- Gopher, anyone?)

As you said previously, hypertext is an old idea -- yet it took quite some time to catch on with Joe Average. Why do you think that is? Do you think that just possibly it had something to do with the WWW being a relatively simple, uncluttered system that (a) most everyone could navigate and (b) most everyone could easily extend? I don't see either of those attributes expressed in anything you've said.

john,
crabby because he's coding C and has become lost in a maze of twisty little pointers.

[ Parent ]

Re: HTML Linking Is Too Limited (5.00 / 1) (#39)
by Anonymous Hero on Tue Jun 27, 2000 at 04:10:36 PM EST

My point, which you ignored, was that they could be frobbed, at the server level, to do exactly that. Go back and re-read the last sentence of my first paragraph.

It would be possible to hack something of the sort by customizing the way the server handles the data. This would make the data inherently non-portable, and it would transgress the principles of XML, one of which is that metadata should be local to the data it describes.

So to answer your objection, yes, you are absolutely correct that it can be done. As to the question of whether there's any merit it doing such a thing, that is a separate issue.

People do do this. It's called a "hey, look, here are my friends with web pages" web page.

Again, there's an issue of information theory here. By providing two separate one-way links you are bifurcating your metadata needlessly. The result would be an explosive increase in "link rot". If a two-way link is intended, then to separate it into two one-way links is to erase the fact that two pieces of data are mutually linked. When any of the link data is changed, it will be necessary to manually re-establish the mutuality of the connection. In other words, two separate one-way links provide a de facto two-way link, but they do not improve the data relationship. Think on this: if the link contains contextual information, such as might be encoded in a link between two nodes in a parent-child relationship, the information will have to be encoded twice. When the information changes, it will have to be changed twice. The integrity problems introduced by this method would be crippling.

As for the issue of non-linear traversal -- I'm interested in making the web better for humans. Humans travel linearly.

Let me explain a distinction has not yet been made clear: because HTML addresses individual pages, Web navigation is fundamentally based on the concept of locations, a particular place in a hierarchy of pages. XML isn't crippled by notions of pages; it simply addresses resources, flexibly and adapatably. It is not necessary that the user be located in any particular place; it is only necessary that he/she be viewing a particular resource. Hence, the notion of "travel" becomes somewhat anachronistic.

If "travel" is a useful metaphor for human viewers, then by all means preserve it. But I am arguing that it should not be necessary to cripple data with that metaphor because data can be separated from its presentation.

How does this help someone who cruises both K5 and the Other Place when a similar topic comes up? Who's going to put in all these multi-level two-way sooper dooper links?

I have been discussing the information theory behind XML's improvements, and it is germane to much of the discussion. I agree, however, that the theory is remarkably muddled by legal entanglement when put into practice. In a separate conversation, I would love to argue about the legal prospects of information, including the reasons I believe intellectual property is a destructive and backward notion. Happily, there are many people in this world who do not hoard information, and I think that the example they set for the others -- specifically, that information sharing has mutual benefits which overwhelm traditional IPR advantages -- we will begin to see a sea change in attitudes toward information.

So, let me paraphrase: "We're physicists; we come up with the stunningly great ideas, and it's up to the engineers to implement them." Newsflash: you can have the greatest hypertextual doodad ever, and if the interface sucks, you're gonna crash and burn (and the field is littered with the craters of poorly implemented systems -- Gopher, anyone?)

Without a solid theoretical basis for its operation, any implementation is doomed to failure. A solid theoretical basis is no guarantor of success, I wholeheartedly agree, but first things must come first. Your objection would have sounded familiar, ten years ago, to proponents of SGML (Sounds Great, Maybe Later). But the XML specification engineers have worked hard to make it scalable and approachable, and the signs that it is taking root are everywhere.

HTML was a fantastic starting place for a World Wide Web, but the information-producers of this world have long since outgrown its crippled information model. XML is both easy-to-use and powerful because it scales from simple documents to complicated webs of information. In time, I think, you will wonder how we ever got by without the advancements in XML.

Ubu

[ Parent ]
Re: HTML Linking Is Too Limited (none / 0) (#41)
by genehack on Tue Jun 27, 2000 at 04:40:21 PM EST

Again, there's an issue of information theory here.

Okay. Point taken; from a meta standpoint, there might be something here -- it's akin to putting commonly used data in a lookup table instead of re-entering it each time. Fine. I grok that -- but you still didn't address the issue of how these links happen (and more on that in a minute).

If "travel" is a useful metaphor for human viewers, then by all means preserve it. But I am arguing that it should not be necessary to cripple data with that metaphor because data can be separated from its presentation.

You know that point in the conversation when you realize the other guy is coming from such a vastly different perspective that 75% of the previous discussion was completely mis-interpreted by both sides? That was it, right there, I think.

I agree, however, that the theory is remarkably muddled by legal entanglement when put into practice.

Not just legal -- practical. The links have to be good -- that is, legitimatly linking related stuff -- or they're worthless. As I said, if the same person writes both pages (or resources, or what ever you want to call it -- the data nuggets on either side of the two way link) this isn't a (huge) problem. As soon as there are two authors involved, even if they're collaborating, two way link quality goes to hell -- even if the linkage is semi-automatic and based on XML organized semantic markup. It doesn't have anything to do with information hoarding or IP -- it was to do with people being different, and therefore relating things together in different ways, which contain information for that person, and maybe others, but not for everybody.

Without a solid theoretical basis for its operation, any implementation is doomed to failure

I still think the web was is a counterexample to this. HTML still bears the hallmarks of it's ad hoc birth (why is IMG not a container tag, for example?). Nevertheless, I don't think most people think the web is "doomed to failure".

HTML was a fantastic starting place for a World Wide Web, but the information-producers of this world have long since outgrown its crippled information model.

See, this is where I know for certain that we're talking about different things. I'm talking about web pages. Not on-line data stores, not inter-application data transfer. Web pages. With words, and pictures, and links. To other web pages. Ya know, the kind some hopelessly archaic people still hand code? Does anybody sane hand-code XML?

XML is both easy-to-use and powerful because it scales from simple documents to complicated webs of information. In time, I think, you will wonder how we ever got by without the advancements in XML.

I'm sure it'll be used in all kinds of funky ways -- but it'll be automatically generated, automatically parsed, and most people won't give two figs about any of the details. You're not going to see people reading "Dummie's guide to XML" on the subway. You're not going to see topic based discussion boards allowing XML-based comments. (/me dreads the enivitable counter-example...)

I haven't heard anything that makes me think XML is going to replace HTML for making web pages -- they're two related languages, with historically similar roots, but completely disparate purposes.

john,
old skuul,HTML-hand-coding curmedugeon

[ Parent ]

Re: HTML Linking Is Too Limited (none / 0) (#43)
by Anonymous Hero on Tue Jun 27, 2000 at 06:35:50 PM EST

It doesn't have anything to do with information hoarding or IP -- it was to do with people being different, and therefore relating things together in different ways, which contain information for that person, and maybe others, but not for everybody.

Here's the part where I have to explain XLink two-way links. I'm going to borrow from a Sun article:

XLink solves both of these problems. How? In HTML you have to surround the starting point with your link markup, and then provide a URI to the ending point; you have to own the resource containing the starting point in order to do any linking at all. In XLink you simply provide a URI for both the starting point and the ending point -- no permission required for either half, and no need to edit the starting points to fix them when the ending points get moved around.

Of course, when you store a link apart from its own starting point, then anyone viewing the document containing the starting point needs explicit access to the link information -- because if they can't find the link, the starting point just looks like undistinguished text. XLink defines some ways that browsers can hunt down the relevant links for a document, so that the links can be loaded and revealed to the user, for example by making the starting-point text blue and underlined.

With XLink, a site organizer could simply store a database of links to associate with his/her content. If the user uses one of these links to go elsewhere, he can continue to use the link database, in which case two-way links are operational whether or not the new site's organizer has been involved.

Even better, a third-party could store a database of links for users to browse when they want to find information on, for example, digital cameras. None of the actual content providers need be involved in the creation of these associations.

I still think the web was is a counterexample to this. HTML still bears the hallmarks of it's ad hoc birth (why is IMG not a container tag, for example?). Nevertheless, I don't think most people think the web is "doomed to failure".

HTML has a solid foundation, but it's limited and simplistic. Idiosyncracies aside -- like the <IMG> tag -- HTML is a very good, very valuable implementation. It's simply outliving its usefulness.

Web pages. With words, and pictures, and links. To other web pages. Ya know, the kind some hopelessly archaic people still hand code? Does anybody sane hand-code XML?

I've hand-coded all of these replies in XHTML, except for the <br> tag, which is <br/> in XHTML. Regardless, this is where HTML and XML will seem most different for the average user. I hate to have to harp on this, but you need to remember that data and presentation were/are unified in HTML. The author had to be part writer, part geek, and part graphic designer to write HTML code. The only tools that proved any good at automating the authoring process were WYSIWYG editors, which -- you will doubtless agree -- were pretty clumsy.

XML, by comparison, will enable the use of much, much more metadata, and that metadata will be focused in its use. The separation of data and presentation will mean that XML lends itself to workflows: a writer, a pagesetter, an artist... all of these people can be collaboratively involved in the production of documents using tools and XML applications (note the XML meaning of that word) that lend themselves to the appropriate tasks.

To bring this down to earth, we could posit an example involving a regular-Joe Web page... MP3.com, for example. A content manager is responsible for decisions over what the site will contain. A writer types up the copy in a WYSIWYG text editor, an artist creates the imagery, and the content manager lays these out in the traditional pages. Link analysis tools are used to establish the site's structure and to connect resources. He works with a database programmer, who organizes data for retrieval according to the site's established query interfaces.

All of these people are working with XML documents, but none of them ever need know the details of the XML code. The robust and flexible nature of XML applications enables user-agents that can act like day-to-day software: graphics programs, text editors, network analyzers, page-layout tools, and others. When these user-agents output XML documents, they can be embedded easily without a single hand-written line of code. Two major applications, SVG and MathML, are already enabling this kind of workflow.

I haven't heard anything that makes me think XML is going to replace HTML for making web pages -- they're two related languages, with historically similar roots, but completely disparate purposes.

I suppose it depends on what you think HTML is for. XML is for data -- any kind of data. I consider that to be little more than an generic expansion of HTML's role. For a more eloquent description, the Sun article mentioned before may be of interest:

Back in the early days -- that is, two years ago -- XML was most often compared to HTML, and in the eyes of many, XML came up short. HTML was a simple language anyone could learn; XML had complexities that could confuse developers. HTML had built-in formatting; XML needed a style sheet to be displayed as anything other than raw code. HTML had built-in hyperlinking with the <A HREF> tag; XML didn't even give you a linking starter kit for embedding hyperlinks into XML in a standardized way.

Today, we know that XML is scalable and flexible in ways that would stretch HTML to the breaking point, allowing XML to become the universal solvent for all data, not just the narrative information that HTML was originally designed to hold. However, if XML is to capture one of the most important features of the Web, it still needs to offer a standardized way to do linking. The goal of the XML Linking Working Group of the World Wide Web Consortium is to provide exactly this, and we're closing in on our goal.

The rest is at http://www.sun.com/software/xml/developers/xlink.html

Ubu

[ Parent ]
Re: HTML Linking Is Too Limited (none / 0) (#44)
by genehack on Tue Jun 27, 2000 at 07:45:58 PM EST

(Meta: What's the longest running K5 thread? 8^)= Are we into the right margin yet?)

So, I've been converted, via this thread, from skeptical to skeptical but curious. I'm still stuck on some implementation details (E.g., I think Mozilla demonstrates that new web browsing technologies can be a PITA to implement.), but I'll let those go, for the moment.

I just have a few more comments:

Even better, a third-party could store a database of links for users to browse when they want to find information on, for example, digital cameras. None of the actual content providers need be involved in the creation of these associations.

That, of course, is where the legal issues rise up and bite you firmly on the ass. Did those 'web annotation' software makers ever get taken to court?

I hate to have to harp on this, but you need to remember that data and presentation were/are unified in HTML.

Actually, I'm down with you on this point. I think our difference lies in the degree to which we regard this 'feature' as a problem.

To bring this down to earth, we could posit an example involving a regular-Joe Web page. {snip example}

That's about as far from a 'regular Joe' web page as I could imagine! 'Regular Joe' means one person, who's not a professional web anything -- just somebody with ideas to share. HTML lets that happen. It sounds like that might still be possible in the future, but the barrier to entry is going to be much, much higher, which I don't see as particularly good. You might argue that the increase in difficulty will be offset by new tools, but (as you note) the record is pretty dismal there too.

Anyway, I think I'm going to end it here -- I'll give you Right of Last Post, if you so desire. I'd offer to take it to email, but you appear to be cloaked. ;^)=

Thanks for the discussion, and I'll see ya 'round the K5 spread, I hope.

john.
happier now that he's home, and away from his grotty C code.

[ Parent ]

Re: HTML Linking Is Too Limited (none / 0) (#47)
by Louis_Wu on Wed Jun 28, 2000 at 12:16:22 AM EST

I believe that what AH meant by "Regular Joe" is that MP3.com is the kind of page that a "Regular Joe" would go to, and the people making content are not hard-core geeks.

Will XML and HTML be able to peacefully coexist on the same network, interacting with each other, or will XHTML be necessary everywhere?

BTW, this will teach me not to post a question to K5 and then not check back for 24 hours. Good Grief, that's a lot of discussion! And, genehack, you and AH each posted 4, total of 8. One of the biggest two-party discussions I've seen.

Thanks for the info!

Louis_Wu
"The power to tax is the power to destroy."
John Marshal, first Chief Justice of the U.S. Supreme Court
[ Parent ]

Re: HTML Linking Is Too Limited (none / 0) (#52)
by genehack on Wed Jun 28, 2000 at 07:11:56 AM EST

BTW, this will teach me not to post a question to K5 and then not check back for 24 hours. Good Grief, that's a lot of discussion!

It was a good one, wasn't it? I'd speculate about how we could have more stories/discussions like this, but, frankly, I wouldn't get any work done during the day... ;^)=

Oh, and I count 7 posts by me under this topic; 4, as you say, in the thread with the Ubu entity. There are 6 posts signed Ubu (== this particular AH).

Not too bad -- learned some things, and got to add a site or two to the "Read this in your copious free time" list.

john,
much better this morning, thanks for asking.

[ Parent ]

Re: HTML Linking Is Too Limited (none / 0) (#38)
by Alhazred on Tue Jun 27, 2000 at 04:03:00 PM EST

SORRY, I agree with the previous commentator, its NOT due to limitations in HTML. Certainly they do exist, but 2 way links STILL require cooperation by both parties, and multi-way linking and some other nifty XML link types that people have proposed will be useful but probably not for site to site linking due to the sheer difficulty of the logistics (not to mention the fact that the interface will be a bear).

I think the reason Xlink hasn't gone very far yet is just this. Its MUCH more important right now to deal with issues like schemas and metadata. Linking will make a lot more sense once those things are dealt with and the smoke clears.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Re: HTML Linking Is Too Limited (none / 0) (#40)
by Anonymous Hero on Tue Jun 27, 2000 at 04:21:47 PM EST

As I explained elsewhere, fixated notions of "sites" are orthogonal to information management. If site operators cannot recognize the benefits of true resource addressing, they will become islands in an increasingly-interconnected Web of information.

Right now, site operators prefer to consider their information as if it were a multi-page Yellow Pages advertisement or a brochure. Those who are disabused of such notions will benefit as they realize that their information gains value as a function of its accessibility.

As always, these changes in perspective follow generational die-off; as cruel as it sounds, attitudes toward information are not likely to change profoundly until the baby-boomers retire to their yachts and gardens and offsprings' residences.

Ubu

[ Parent ]
Re: HTML Linking Is Too Limited (none / 0) (#42)
by Alhazred on Tue Jun 27, 2000 at 05:05:40 PM EST

hehehe, well I'm not quite THAT pessemistic!

I think there are quite legitimate technological hurdles to be overcome before this kind of thing is really viable.

I do agree with your statement about information value, but the truth is that file systems as they exist today are MUCH too primitive a storage mechanism. There is a lot of basic work to be done still. Essentially 98% of the web is in flat files, a technology invented in the 1950's and little changed since then. In fact its one of THE most backward areas in computer science today, though that is starting to change.


That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Two words (3.70 / 3) (#29)
by GeoffinIdaho on Tue Jun 27, 2000 at 02:31:27 PM EST

Two words:

link rot

Links are hard (none / 0) (#45)
by scriptkiddie on Tue Jun 27, 2000 at 09:49:12 PM EST

Except in a small section of Web content, it's really difficult to maintain links. A few hundred links are a horror whether you control the linked sites or not! Of course, there is a solution. Me and a couple high school friends made a WikiWeb, using our own CGI scripts. For those who don't know, a WikiWeb is a set of hundreds of pages, linked to pages with similar keywords at loading time instead of at creation time. It's here.

Twenty Four hours of comments. Wow. (4.00 / 1) (#48)
by Louis_Wu on Wed Jun 28, 2000 at 01:12:59 AM EST

As I said a half hour ago, that'll teach me to not post to K5 and not check for 24 hours.

I've seen a lot of talk about databases of links/sites, methods for making link maintenance easier, and a big talk about XML vs HTML (BTW, what IS the record for longest discussion, how many parties, length of comments, etc?), and the only answers to my question that I seem to have found are that putting in many links is:

1) Hard to do initially. Someone has to find all of those sites to link to, the links have to be checked to make sure they still work at the time of uploading, and the code has to be written, 'href' and all.
2) Hard to maintain. Link rot sets in, and that cool site you referenced last year just went under, "now in which article did I link to them?" Keeping your own site high quality requires keeping all of your links active, so it is sometimes easier to not link in the first place.
3) Bad for revenue. Advertisers don't want people leaving the site, they want people staying.
4) Hard on the reading. All of that blue and underlining makes it hard to read the articles.
5) Confusing. How do you decide which link(s) to follow? Saturating an article with links makes it hard to find the links the author thinks are really important among the ones which might be good references.

I probably missed a few, but these stuck out. Here are my ideas about each:

1) Links might be hard to do (I don't find it hard, but I don't code documents all day or fix up documents technophobes have written.), but I find that linkful pages are worth the inconvenience. Finding that really cool page may be a pain (my bookmark file is currently 833KB, and I'm just re-organizing 3 years of bookmarking everything I like), but writers usually (good writers almost always) have a firm grasp on what the most important links are, and often have bookmarks from research.
2) Link rot. Hard to overcome. For your own site (if it's professional, or you are a compulsive organizer & geek) you will probably have a record of what pages link to which others on your site. I know that Dreamweaver 3 does this, IF you create/manage the whole site with Dreamweaver. I've been thinking that wide-spread linking would lead to more stable site architecture, and fewer pages with URLs like this: http://www.kuro5hin.org/?op=displaystory&sid=2000/6/27/3714/26498", or if the pages have to be that complex, then the URLs would be static. I know that wide-spread linking won't happen till pages are more permenant, but I wanted to find out if there was a way around that Catch-22. BTW, TOS redirects you if you go to the active story page, and it's passed into archive format, but that's only a patch on the problem of impermenance. Could impermenance be solved? Would we want to?
3) Revenue loss would explain not linking off-site, but why not link on-site? The surfer will probably read most of the page he started on, and maybe others you link to; that's more ad-time.
4 & 5) Well, lots of blue can be confusing, especially if you don't know what the author thinks is really important. The comments about putting the truly important links in the article, and the referential links at the end or in a sidebar are great. Hypatia had a good point, learning to read without clicking on every link is important for serious web crawlers.

No perfect answers. Why doesn't that suprise me?
(Note how few links I put in. Ironic. :)

Louis_Wu
"The power to tax is the power to destroy."
John Marshal, first Chief Justice of the U.S. Supreme Court

Re: Twenty Four hours of comments. Wow. (none / 0) (#56)
by jovlinger on Wed Jun 28, 2000 at 02:32:26 PM EST

It's rather that the person reading the document will likely be overwhelmed by the non-linear flow of information. When I'm reading a page and need to know who Bob Mulla is, f.ex., then a link to his bio would be great, later on, the link under Bill Gates' name leads not to a bio, but rather to a short aside -- an extended footnote. Since I know who he is, I have to identify it as pointing to a related page, not background info.

We've all done mouse-overs to try to figure out from the URL what info a link provides.

The difference is that in the first case, I knew I needed the background information that wasn't part of the main information flow. In the second case, the link offered another narrative.

What we need is really a second kind of link -- visually distinct -- so that we can distinguish these cases. I think the mouseover is one way to deal with this. Since we don't have a standard for identifying one type of link, there's no way of getting one for two.

Instead, I propose design guidlines:
Optional background info like bios and word definitions should be behind links that are invisible until mouseovered.
Information-flow links should be clearly identifiable (like most links today) because they are part of the narrative.

It would be really nice if both links had provisions for a tooltip like summary feature. Oh, and the optional links might be a good candidate for automatic generation -- maybe even on the client side.

A decent (perhaps still hypothetical) natural language processor (like the ever impressive hubat) should be able to figure out enough context to divine what to search for when I click on a word or phrase. For example, the hubat link should have been figured out immediately from the proximity to "natural language" so that had I clicked on it, it would have tried the "I'm feeling lucky" search on google. I'd provide that link too, but it was counter productive :-( Ok, so maybe generating them on the client should wait awhile.

Not that I'm a designer or anything. I just surf alot.

[ Parent ]

Saturating texts with hyperlinks. (none / 0) (#49)
by nicksand on Wed Jun 28, 2000 at 02:10:41 AM EST

The only time I really load down a webpage with hyper links is if its meant to be documentation which covers a broad range of topics. For the last couples of days, for instance, I've been writing documentation for the new network admin at work (who will be taking over my job after I leave on thursday). The new guy is competent, but he is not, by any means, a unix/linux/*bsd guru. Therefore I'm writing pretty general network documentation which relies on external sources when extra depth on a particular topic is needed.

Its times like this when I find it useful to saturate pages with links. For instance, my page describing the firewall setup has links to (locally stored) copies of the firewall-howto and ipchains-howto. It also has a link to the homepage of gfcc, a link to Suse's homepage (the distro being used), a link to OpenSSH's homepage (installed the client, not the server portion).

I keep two things in mind when linking this much. (a) If you can store and link to it locally, do so. (b) If its an external site, make sure that it will still be around at least twelve months from now, or link to a page that will probably keep abreast of changes (eg: Freshmeat). The corrolary for point b is that you should avoid extremely complex or dynamic content URLs, since they are more likely to change.

Overall, beyond specific types of documentation, I think the uses for embedded hyperlinking is quite limited. What is useful, IMHO, is creating a bibliography or "related links" section which can be used to follow up after your content has been read.

When over-hyperlinking is good. (none / 0) (#58)
by Inoshiro on Wed Jun 28, 2000 at 07:35:05 PM EST

I posted this humour piece to K5 some time back. In it I'd gone and linked all the important points I could find to stories giving more depth (such as Microsoft's "Blackbird" project from 1996, which no one seems to remember). In this situation, the hyper linking gives extra depth to the story, and ensures that everyone reading the piece has the same background knowledge.

On the flip side, once you pass 1 hyperlink per sentence, you begin to overload the user with too many options. Plus, with the changes in font size/colour/etc (or worse for those who get the web via a text to speach engine which must repeatedly say "LINK" or similar), you begin to distract the user from your content.

For more info, see Alertbox articles by Jakob Nielsen (a great web usability guy).



--
[ イノシロ ]
Why isn't there more hyperlinking in web content? | 58 comments (51 topical, 7 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!