Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!apple!dan
From: dan@Apple.COM (Dan Allen)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: What to do about > 32K of data?
Message-ID: <27714@apple.Apple.COM>
Date: 22 Mar 89 18:21:52 GMT
References: <938@Portia.Stanford.EDU>
Distribution: usa
Organization: Apple Computer Inc, Cupertino, CA
Lines: 64

In article <938@Portia.Stanford.EDU> davef@jessica.stanford.edu (David Finkelstein) writes:
>I'm writing a stack that has to deal with > 32K of data.  Basically
>I've got a really large text file located on a file server that I need
>to read in and store, so I can display any part of the file to the
>user.  [I need to load the entire file into HyperCard because network
>access is too slow to read through the file to get to each line of
>information I want.]  No problem really; I just use three fields.
>
>However, the user of the stack can choose to view any part of the text
>information, meaning potentiall *all* of the information, or large
>disjoint subsets, at once.  I can't just throw the information into a
>scrolling field; I'm limited to 32K.

The problem is trying to squash linear text into a hypertext model.  I
think many people try to make HyperCard a word processor, which it is
not.

If the person has a really large text file to read, then read it with
the MPW Shell which can open and work with files in the megabytes
without any problem.

If someone want to use a hypertext system, then the information should
be broken down into hypertext sized chunks.  Hypertext is supposed to be
fast, and HyperCard has a card as the unit of information.  It may seem
limiting (and indeed it is when thought of as a word processor), but if
the new paradigm of hypertext is used, then having cards is seen as a
bonus.  Let me explain...

Each card in HyperCard should have a reasonable amount of information,
where reasonable has been tentatively defined as that information that
can all be seen at once in 512x342 pixels.  Scrolling fields extend this
range, but were put in by Bill Atkinson only under duress: his personal
stacks have no scrolling fields in them, and few of mine do.  Hypertext
has (in our implemetation in HyperCard) a different model than the
endless scrolling done in a word processor.  If you like scrolling, use
a word processor; if you like queries, use an SQL database; if you like
clicking and free associating, then use HyperCard.

There are great advantages to looking at your information in light of
card chunks of material.  Presenting the browser with more than a cards
worth of information is not good because the user gets overwhelmed: too
much information.  The best hypertext stacks present material in a
card's worth of space, and then the user is given the option to explore
different areas in greater detail.  If the topic at hand is music, for
example, a timeline of music could be shown with Classical, Jazz, Pop,
and Country shown.  The user could then explore more about the type of
music that he/she likes rather than having to explore the types they
don't like.

Hypertext gives people choices and freedom to move about, not the need
to read and wade through 32K chunks of text (at 2K per page thats 16
pages of text!) trying to find what they want.

Now I realize that we have archives of big chunks of text which are not
immediately and automatically convertible to hypertext-style stacks.
That's why we gave people scrolling fields in my mind: they are a
holding area while experts parse through the text and break it up into
non-scrolling fields worth of info.

END OF PERSONAL DAN ALLEN SOAPBOX ON THE PROPER USE OF HYPERTEXT.

Dan Allen
HyperCard Team
Apple Computer