Theory: "content-stubs"
Jorn Barger
But if they're hidden _entirely_ they won't be accessed.
So you leave a 'stub' on the main page, that people can select, to
reveal the hidden part.
The stub tries to _imply_ what's hidden (using the fewest possible
pixels).
(The second time you see a stub it could be drawn much smaller-- but the
first time it should be self-explanatory.)
For hypertext, the stub is link-text, and current practice is very
wasteful-- usually giving the 'title' of the site rather than a
description of its special (hidden) content.
The most efficient general structure for a hypertext 'main page' is a
broad overview of the topic, because very small stubs (eg, 'text
buttons') can be inserted at the appropriate points.
theory: http://www.robotwisdom.com/web/
examples:
otzi the 3300BCE iceman: http://www.robotwisdom.com/science/iceman.html
james joyce: http://www.robotwisdom.com/jaj/
joyce timeline: http://www.robotwisdom.com/jaj/timeline.html
joni mitchell: http://www.robotwisdom.com/jorn/joni.html
--
http://www.robotwisdom.com/ "Relentlessly intelligent
yet playful, polymathic in scope of interests, minimalist
but user-friendly design." --Milwaukee Journal-Sentinel
b.kligerman
> In designing an interface, some functions must be hidden.
> reveal the hidden part.
I've been experimenting with "content stubs" for some research
pages/lists(experimental) I'm working on, and find that a 2 tiered
approach to link description offers the most information while
occupying the smallest space. In theory-- _title or description of
linked element - type of site or article the link pertains to_.
Example: http://www.archinter.net/archinternet/bhole.htm#links
> The stub tries to _imply_ what's hidden (using the fewest possible
> pixels).
I want the whole entry to take up one line. I'm vacillating, though,
on which tier, title or description, should be the link-object??
> (The second time you see a stub it could be drawn much smaller-- but the
> first time it should be self-explanatory.)
Maybe the most important point-- standardize the 2nd blurb so that it
becomes a *code* on the page, once understood becoming a scan/search
item on the page for specifically this type of reference... (ie. site,
prtl, rsrch, lctr nts...)
bradKLIGEMAN
archINTER.NET
Jorn Barger
> I'm vacillating, though,
> on which tier, title or description, should be the link-object??
First, try to minimise the quantity of blue-underlined text, because
that's much harder to read.
But in general, the links will be sorted by topic (cf your 'titles'),
and one topic can have links of many types (cf your 'descriptions'), so
you have to make the description (or content-type) be the link/stub.
b.kligerman
> But in general, the links will be sorted by topic (cf your 'titles'),
> and one topic can have links of many types (cf your 'descriptions'), so
> you have to make the description (or content-type) be the link/stub.
After reading this last sentence c a r e f u l l y (ie. matching your
terminolgy to mine), I understand better what you mean by link/stub.
Its' use in a list type situation is efficient and orderly, but it's a
bit problematic in a body of text, where I'd also like to put it to
work as a means to specify content-type.
As opposed to a list, where the content-type is the link/stub, in a
text body it is the **descriptive phrase** that somehow begs to be
_underlined & blue_. The content-type object looses significance and
interupts the readability of the text.
bradKLIGEMAN
archINTER.NET