UI design for digital books with extensive footnotes

2 Aug 2006 - 8:49am
8 years ago
25 replies
954 reads
Dan Saffer
2003

On Aug 1, 2006, at 8:43 AM, Steve Toub wrote:

> Web. Everything in XML.
> --SET
>
>
> Dan Saffer wrote:
>> Is this a desktop or web application or something else?

Since it's a web app, one can imagine not only doing as you're
considering--having basically a footnote pane that acts like the
preview/reading pane of an RSS or Email client--but you could also
consider having onMouseOver actions that open floating windows that
contain the footnote, doing an XmlHttpRequest to get the footnote
itself. I'm basically thinking what Netflix does. That's another
possibility.

If you do go with the pane, be sure it can expand or collapse, so
that it can get out of the way if people simply want to read the text
without footnotes. i.e. The footnotes shouldn't be an impediment to
the text itself. You might also have a control that turns the hover
display off as well.

Dan

Dan Saffer
Sr. Interaction Designer, Adaptive Path
http://www.adaptivepath.com
http://www.odannyboy.com

Comments

2 Aug 2006 - 9:15am
Jack L. Moffett
2005

On Aug 2, 2006, at 9:49 AM, Dan Saffer wrote:

> ...but you could also
> consider having onMouseOver actions that open floating windows that
> contain the footnote, doing an XmlHttpRequest to get the footnote
> itself.

> You might also have a control that turns the hover
> display off as well.

Actually, this wouldn't be a good use of mouseOver, as you would
likely accidentally open a lot of floating windows just by moving
your mouse across the page. This would also suggest that they would
close automatically when the mouse leaves the area, which would
easily be done accidentally while the user is trying to read the
footnote. In this case, it would be better to display the floating
windows when a reference is clicked, and have a close button on the
window. This would also negate the need to provide a control that
turns the feature on and off.

I would postulate that the amount of text to be displayed in the
floating window has a direct correlation to which mechanism is used
for showing and hiding the window. If the text is shorter, as a
tooltip, the hover method is more acceptable, as the text may be read
quickly and the size of the window can be smaller, relieving
annoyance at accidental openings. More text requires a longer reading
time, providing more opportunity for accidental closure. More text
also means a larger window, covering more of the main content, which
would result in more annoyance at accidental openings.

Jack L. Moffett
Interaction Designer
inmedius
412.690.2360 x219
http://www.inmedius.com

In our society,
the scarce factor is not information,
it is time to attend to information.

- Herb Simon

2 Aug 2006 - 9:52am
Dan Saffer
2003

On Aug 2, 2006, at 7:15 AM, Jack Moffett wrote:

> On Aug 2, 2006, at 9:49 AM, Dan Saffer wrote:
>
>> ...but you could also
>> consider having onMouseOver actions that open floating windows that
>> contain the footnote, doing an XmlHttpRequest to get the footnote
>> itself.
>
>> You might also have a control that turns the hover
>> display off as well.
>
> Actually, this wouldn't be a good use of mouseOver, as you would
> likely accidentally open a lot of floating windows just by moving
> your mouse across the page. This would also suggest that they would
> close automatically when the mouse leaves the area, which would
> easily be done accidentally while the user is trying to read the
> footnote.

This doesn't seem to be an issue with Netflix or Flickr notes or
Yahoo News. Obviously, you might want a half-second delay before the
opening of the new windows, and you might want a wide margin around
the scroll bar on the left and have the text be large enough so
individual words can be targets.

Dan

2 Aug 2006 - 10:13am
Jack L. Moffett
2005

On Aug 2, 2006, at 10:52 AM, Dan Saffer wrote:
> This doesn't seem to be an issue with Netflix or Flickr notes or
> Yahoo News. Obviously, you might want a half-second delay before the
> opening of the new windows, and you might want a wide margin around
> the scroll bar on the left and have the text be large enough so
> individual words can be targets.

I agree, but again, these are usually relatively short. In Steve's
case, the "notes" are often longer than the content being referred
to. This particular application reminds me of David Small's Talmud
project (http://www.davidsmall.com/talmud.html). The reader will
likely be spending more time reading the notes than the main text.
You shouldn't require the mouse to stay in position to read that
amount of text (especially considering, as we've recently discovered,
that some users always return their cursors to a particular area of
the screen ;).

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.690.2360 x219
http://www.inmedius.com

First, recognize that the ‘right’ requirements
are in principle unknowable by users, customers
and designers at the start.

Devise the design process, and the formal
agreement between designers and customers and users,
to be sensitive to what is learnt by any of the
parties as the design evolves.

- J.C. Jones

2 Aug 2006 - 10:16am
Luke Ball
2006

>>> ...but you could also
>>> consider having onMouseOver actions that open floating windows that
>>> contain the footnote, doing an XmlHttpRequest to get the footnote
>>> itself.
>> Actually, this wouldn't be a good use of mouseOver, as you would
>> likely accidentally open a lot of floating windows just by moving
>> your mouse across the page. This would also suggest that they would
>> close automatically when the mouse leaves the area, which would
>> easily be done accidentally while the user is trying to read the
>> footnote.

It occurs to me that in addition to reading a footnote, user may want
to be able to select the footnote text to copy and paste. This might
eliminate (or at least complicate) the rollover approach.

Perhaps do the same flyout/popup technique, but with the onclick
event rather than onmouseover. (there could be an explicit "close"
command in the window). There's still a lot of directness {good} to
clicking the footnote and seeing the explanation right there, with no
eye movement. But users only see the footnotes they want to see. If
the footnote text is extremely long, you can build a scrolling
mechanism into the flyout pane.

I can only assume that a more direct approach like this is preferable
to a two-pane version (wherein the user has to look down to read the
footnote, then back up to re-find their place and continue reading).
The two-pane makes sense only if the user needs to cross-reference
the primary text and the footnote simultaneously, and if you can
presume that they are constantly interested in reading the footnotes.

My 2¢, at least.

Luke Ball

PS. you could even add some "scent" to the footnote by giving a
little clue on mouseover "click to view footnote", or perhaps the
first line of the footnote. Also make sure the target is larger than
the traditional superscripted numeral.

2 Aug 2006 - 10:39am
Jack L. Moffett
2005

On Aug 2, 2006, at 11:16 AM, Luke Ball wrote:

> I can only assume that a more direct approach like this is preferable
> to a two-pane version (wherein the user has to look down to read the
> footnote, then back up to re-find their place and continue reading).

If using two panes, they should be side-by-side, with the main text
on the left, and the notes on the right. This would be easier than
looking down, as you say.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

If there's anything more annoying
than a machine that won't do what you want,
it's a machine that won't do what you want
and has been programmed to behave
as though it likes you.

- Don Norman

2 Aug 2006 - 12:38pm
Dan Saffer
2003

On Aug 2, 2006, at 8:39 AM, Jack Moffett wrote:

> If using two panes, they should be side-by-side, with the main text
> on the left, and the notes on the right. This would be easier than
> looking down, as you say.

Is this true? Why then is the convention in print for footnotes to be
at the bottom, and, in software, for the display pane to be below the
summaries/listings? Is there a physical, cultural or cognitive
rationale?

Dan

2 Aug 2006 - 12:58pm
Jenifer Tidwell
2003

Maybe because books are traditionally done in a "portrait" aspect ratio, so
as to fit better on shelves? A narrow page obviously makes it impractical
to fit two columns of text -- primary and footnotes -- side by side, and
still have them be a readable width. (Though I think I have seen this in
wider books.) Or maybe it was once harder to typeset? I'm guessing here,
understand...

And in traditional books, it certainly can be difficult to find the right
footnote for a given piece of text. It seems like it would be cognitively
easier to have the text and footnote be geometrically aligned, side by side,
as they could be in an electronic version. Small rollover cues in the text
itself might be a useful redundancy, too. So could "smart scrolling" that
always keeps the correct footnotes in view for the visible text.

Anyway, in software, display panes may be found below *or* to the right of a
summary or listing. I've seen plenty of both, and they both seem acceptable
in most contexts.

- Jenifer

On 8/2/06, Dan Saffer <dan at odannyboy.com > wrote:
>
>
> On Aug 2, 2006, at 8:39 AM, Jack Moffett wrote:
>
> > If using two panes, they should be side-by-side, with the main text
> > on the left, and the notes on the right. This would be easier than
> > looking down, as you say.
>
> Is this true? Why then is the convention in print for footnotes to be
> at the bottom, and, in software, for the display pane to be below the
> summaries/listings? Is there a physical, cultural or cognitive
> rationale?
>

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://designinginterfaces.com
http://jtidwell.net

2 Aug 2006 - 1:11pm
Jack L. Moffett
2005

On Aug 2, 2006, at 1:38 PM, Dan Saffer wrote:

> Is this true? Why then is the convention in print for footnotes to be
> at the bottom, and, in software, for the display pane to be below the
> summaries/listings?

I think these are two different conventions.

Footnotes are at the bottom due to the limitations of the printed
page. However, I also know of examples in which supplementary
information is displayed in a column to the right of the main content
(this is a standard in some military maintenance manuals). End Notes
appear in a separate section of a publication, and the Talmud is a
separate book altogether, for reasons I won't expound upon now.
Digital display frees us from such limitations, for example, by
allowing us to add floating windows, as you suggested.

The display pane below the list, as in most email software, allows
the list to use the full width of the screen to display multiple
columns of information. If we didn't want to see so many columns, I
would argue that a "left list - right display" layout would work
fine, with the added benefit of giving us a shorter line length in
the display (something modern email readers often do anyway), and the
full height of the screen for viewing either pane.

My reasoning is as follows:
1. There is more screen width than height. Therefore it may make more
sense to split it into left and right panes.
2. Full screen width is two wide for ideal line lengths, so making
two narrower columns will improve readability.
3. The users will likely want to read both the main content and the
commentary at the same time. Jennifer's post arrived as I'm typing
this, and I see she covered my point here. It would be easier to
track left to right.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

Questions about whether design
is necessary or affordable
are quite beside the point:
design is inevitable.

The alternative to good design
is bad design, not no design at all.

- Douglas Martin

2 Aug 2006 - 1:14pm
Luke Ball
2006

(caveat: Looks like Jennifer beat me to it, but the email was done
anyway)

I can only assume, historically, it's the form factor of the book.
(1) But even in a modern plain-text medium like an email, it's far
easier to simply drop the notes at the end then do some sort of
inline layout.(2) Plus, they wouldn't be called footnotes were it any
other way ;-)

In an ideal world, you don't need to look anywhere other than where
you're already looking. a sophisticated UI should allow this, IMHO.

Luke

(1). You can't do side-by-side notes in a book without one page or
the other entirely dedicated to notes (or creating heinously narrow
paragraphs). Some annotated Shakespeare I read in high school was
like this. Then you have the challenge of vertically aligning the
note with the primary text. This is no small design challenge,
especially with pagination; the primary text flows on, undaunted, and
the citation text has to "keep up". Better to flow the citation/note
on the same page, and the primary text gets shortened proportionately

(2). see?

On Aug 2, 2006, at 10:38 AM, Dan Saffer wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
>
> On Aug 2, 2006, at 8:39 AM, Jack Moffett wrote:
>
>> If using two panes, they should be side-by-side, with the main text
>> on the left, and the notes on the right. This would be easier than
>> looking down, as you say.
>
> Is this true? Why then is the convention in print for footnotes to be
> at the bottom, and, in software, for the display pane to be below the
> summaries/listings? Is there a physical, cultural or cognitive
> rationale?
>
> Dan
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

2 Aug 2006 - 1:17pm
Dan Saffer
2003

On Aug 2, 2006, at 10:58 AM, Jenifer Tidwell wrote:

> Anyway, in software, display panes may be found below *or* to the
> right of a summary or listing. I've seen plenty of both, and they
> both seem acceptable in most contexts.
>

Hmm, perhaps I'm dense, but aside from folder navigation, I can't
think of a single example of text on the left referring to text on
the right. (I see many examples of top/bottom however.) Can you
provide an example or two?

Dan

2 Aug 2006 - 1:18pm
Jeff Howard
2004

Jack Moffett wrote:
> If using two panes, they should be side-by-side,
> with the main text on the left, and the notes on
> the right. This would be easier than looking
> down, as you say.

I've seen Bibles (printed editions) that use this strategy. I think
that Dake's annotated reference edition has four columns. The two
inner columns for the main text, and the two outer columns commenting
on their adjacent text. It's a shorter distance to jump than
footnotes (and by analogy a lower pane), though four columns are
probably a bit excessive for onscreen.

You could improve on printed conventions by using some visual
connection between the text and the reference. For instance, if you
click a bit of text, it could highlight while you're reading the
reference. That relationship could work back and forth.

2 Aug 2006 - 1:20pm
Dan Saffer
2003

On Aug 2, 2006, at 11:11 AM, Jack Moffett wrote:

> My reasoning is as follows:
> 1. There is more screen width than height. Therefore it may make more
> sense to split it into left and right panes.
> 2. Full screen width is two wide for ideal line lengths, so making
> two narrower columns will improve readability.
> 3. The users will likely want to read both the main content and the
> commentary at the same time. Jennifer's post arrived as I'm typing
> this, and I see she covered my point here. It would be easier to
> track left to right.

I can see your reasoning here, w/r/t screen width v. height. Why then
isn't this the standard instead of left/right panes? A holdover from
print?

Dan

2 Aug 2006 - 1:27pm
Jenifer Tidwell
2003

Well, just by looking at what's on my desktop right now... Outlook does that
with lists of email messages. And a Web-based image viewer is giving me
thumbnails on the left, full picture on the right. Not text, but similar.

I don't suppose a UI that I wrote really counts. :-)

And isn't folder navigation a really common use case for a lot of people?

- Jenifer

On 8/2/06, Dan Saffer <dan at odannyboy.com> wrote:
>
>
> On Aug 2, 2006, at 10:58 AM, Jenifer Tidwell wrote:
>
> > Anyway, in software, display panes may be found below *or* to the
> > right of a summary or listing. I've seen plenty of both, and they
> > both seem acceptable in most contexts.
> >
>
> Hmm, perhaps I'm dense, but aside from folder navigation, I can't
> think of a single example of text on the left referring to text on
> the right. (I see many examples of top/bottom however.) Can you
> provide an example or two?
>

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://designinginterfaces.com
http://jtidwell.net

2 Aug 2006 - 1:41pm
Dan Saffer
2003

On Aug 2, 2006, at 11:27 AM, Jenifer Tidwell wrote:

> And isn't folder navigation a really common use case for a lot of
> people?
>

Very common. But I'd argue it serves a slightly different function.
But anyway...

In any case, the length of this discussion has long exceeded my
interest in it (as I'm sure it has for others). :)

Dan

2 Aug 2006 - 1:46pm
Jack L. Moffett
2005

On Aug 2, 2006, at 2:17 PM, Dan Saffer wrote:

> Hmm, perhaps I'm dense, but aside from folder navigation, I can't
> think of a single example of text on the left referring to text on
> the right. (I see many examples of top/bottom however.) Can you
> provide an example or two?

Examples that come to mind:

The most recent version of Microsoft Word displays notes in a column
to the right of the content.
Omni Outliner allows you to create multi-columned outlines. I often
use a column to the right of the actual outline for notation.
There are many examples of having an Index, Table of Contents, list
of search results, etc. on the left with content on the right, but I
suppose that is the same as "folder navigation," in that it is for
the purpose of navigation, rather than comparison.

> I can see your reasoning here, w/r/t screen width v. height. Why then
> isn't this the standard instead of left/right panes? A holdover from
> print?

In large part, I believe so.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

The World is not set up to facilitate the best
any more than it is set up to facilitate the worst.
It doesn't depend on brilliance or innovation
because if it did, the system would be unpredictable.
It requires averages and predictables.

So, good deeds and brilliant ideas go against the
grain of the social contract almost by definition.
They will be challenged and will require
enormous effort to succeed.

Most fail.
- Michael McDonough

2 Aug 2006 - 1:59pm
Katie Albers
2005

The difference is in the purpose of the notes. Footnotes and endnotes
were conceived as ways of tracking the academic provenance of a text.
They aren't really designed to store commentary on the text.

The goal with footnotes and endnotes is to preserve the readability
of the central text, not to make the notes easy to correlate with the
text.

Talmudic commentary has historically been done by columns on either
side of the text precisely to keep the text and the commentary
easily, simultaneously visible. On a more sectarian side, annotated
versions of popular texts are also printed in the side-by-side
format, for the same reason.

Katie

At 10:38 AM -0700 8/2/06, Dan Saffer wrote:
>[Please voluntarily trim replies to include only relevant quoted material.]
>
>
>On Aug 2, 2006, at 8:39 AM, Jack Moffett wrote:
>
>> If using two panes, they should be side-by-side, with the main text
>> on the left, and the notes on the right. This would be easier than
>> looking down, as you say.
>
>Is this true? Why then is the convention in print for footnotes to be
>at the bottom, and, in software, for the display pane to be below the
>summaries/listings? Is there a physical, cultural or cognitive
>rationale?
>
>Dan

2 Aug 2006 - 3:01pm
Juan Lanus
2005

Hi Steve, All,

I'm joining late, but I have read it all. Almost all what I was
willing to say is already said.
In the vein of taking the foot out of "footnotes."
Also, leveraging the lack of page limits a web application provides.

My first idea is a two-pane with a moveable division, so the reader
can adapt the real estate proportions according to the content's. I
recall some applications that have an option for to switch between
vertical and horizontal division, maybe useless with today's screens.

Second, a means for to slightly highlight the text related to the note
in the right pane (left pane for RTL readers?). There must be a visual
clue telling that the displayed note refers to "this" piece of text.

Third, a highlight on all clickable pieces of text that have notes.
This poses an interesting problem, when some words participate in more
than one "link". For example when there is a comment on a paragraph
and also a comment on a word or two that belong to the same paragraph.

Another question is what to do to the right pane when the referenced
text is scrolled out of sight in the left pane. IMO, nothing. But this
calls for panel synching controls, case when the user is reading an
interesting note and would like to know what text is it applied to.

Related is the search thingie. Search original, notes, both ...
Because of course there will have to be a searching tool.

- - - - -

All this is up-front design. Assuming one can do it with the bare
brain. But users are another thing ...
The best would be to talk with somebody knowledgeable, one who reads
or writes such books, and have an antropologic interview for to find
out some scenarios and then build a use case on it.
Usually there are surprises, things are not what one imagines before
having a chance for to grab them in real.
Sometimes in simpler, almost always is nuch more complicated, and
seldom it's exactly as imagined. Specially if one is "user-sensitive."
--
Juan Lanus
TECNOSOL
Argentina

2 Aug 2006 - 6:19pm
Peter Bagnall
2003

> . In this case, it would be better to display the floating
> windows when a reference is clicked, and have a close button on the
> window. This would also negate the need to provide a control that
> turns the feature on and off.

I did just that here for almost exactly that reason....

http://www.iraqbodycount.org/editorial/defended/2.1.php

The footnotes are dotted underlined links, which show a popup layer.
In this case the slight oddity is that some of the popups just
contain a single link, which means efffectively you have to click
twice to access that link. (we had reasons for this, which I won't go
into here). But you can get the general idea - see if it works for you!

Cheers
--Pete

-------------------------------------------------------------
Voice or no voice, the people can always be brought to the bidding
of the leaders. That is easy. All you have to do is tell them they
are being attacked, and denounce the peacemakers for lack of
patriotism and exposing the country to danger. It works the
same in any country.
--Goering at the Nuremberg Trials

2 Aug 2006 - 6:36pm
Jeff Howard
2004

An analysis of TS Elliot's "The Waste Land" made the rounds a few
years ago. It combines the poem, cross-references, notes, comments
and navigation into a multi-pane interface.

http://world.std.com/~raparker/exploring/thewasteland/exhomef.html#select

The visual design could use some polishing, but there were six (6!)
different interfaces that might give some insight into the pros and
cons of each approach.

4 frames in one window (1 over 2 next to 1)
4 frames in one window (1 over 1 over 2)
4 frames in one window (2 over 2)
3 frames in one window (1 over 2, Notes in separate window)
Plus 2 line-wrap variants.

As to why upper/lower divisions are more common in interfaces, I'd
say it's because lines of text in western languages run
horizontally, not vertically and column depth influences readability
less than line length. If you only have room for a few lines of text,
they can still be separated into upper/lower panes with no line-length
problems. Horizontal divisions aren't nearly so flexible because once
you drop below about 55 characters, readability starts to suffer. You
also can't resize the horizontal divisions without reflowing the
text. Vertical divisions don't have that limitation.

I don't think screen space is as much of an issue now, but text
still runs horizontally in western cultures, so the divisions still
follow those lines.

2 Aug 2006 - 7:05pm
Juan Lanus
2005

On 8/2/06, Jeff Howard <id at howardesign.com> wrote:
> http://world.std.com/~raparker/exploring/thewasteland/exhomef.html#select
> I don't think screen space is as much of an issue now, but text
> still runs horizontally in western cultures, so the divisions still
> follow those lines.
In my 1024x768 pixel screen the right half of the screen remains
almost empty, but instead I see few lines in each frame and have to
scroll a lot.
If the divisions were vertical I'd have twice as much content on sight.
This page seems to have been designed for a 640x480 resolution.

Also, I have to zap my sight up and down, instead of left and right.
I'm used to, and better at, horizontal movements. When I read I move
my eyes horizontally all the time, and vertically not so often. Big
vertical movements are more painful than big horizontal movements, and
I can zero in the spot much faster with the horizontal move.

As in our culture we read "horizontally" we all are more used to
horizontal eye movements.
--
Juan Lanus
TECNOSOL
Argentina

3 Aug 2006 - 3:21am
Eugene Chen
2004

There might be some reason to consider inline expansion. This would work
basically the way people use parthenseses.

"The monkey peeled the _banana_ [a Banana is an oblong shaped fruit] and
smiled mysteriously"

Of course this interrupts the text, but has the least eye movement of all.
Unlike popup layers, none of the original text is obscured. I've seen this
done in some help systems, usually clunky, but with the right visual design
(possible use of dimming, animation) it could have it's place. Would be nice
to be able to collapse by clicking in the exact same location, no mouse
movement. Just another thing to consider. Also, it may be fruitful to
combine some of the approaches that have been mentioned, especially if the
annotations fall into a few different classes.

It would help to understand the tasks a bit better. e.g. is the user
exploring these annotations for serious research, or exploratory play and
discovery. Do they need to come back to them later, etc.

Eugene

Eugene Chen | User Experience Design, Strategy, and Usability
main 415 282 7456 | mobile 415 336 1783 | fax 240 282 7452
web http://www.eugenechendesign.com | aim peastulip | skype eugene-chen

> I'm considering something that splits the two panes and that
> when you click on an area of the "text itself" pane, the
> "explanatory" pane jumps to the footnote that best
> corresponds to that location of the text. And vice versa: you
> can browse the "explanatory" pane from footnote to footnote;
> when clicking on the footnote (or cursor-ing over it?), the
> "text itself" pane jumps to the portion to which that footnote refers.

3 Aug 2006 - 4:43am
peter sikking
2006

Steve et al.

> I'm working on a project that provides access to critical editions of
> literary works. This concept is a bit new to me.

After two days of discussion on widget level, I would say
let's prepare a basis for some architectural decisions.

I would sit down with the guys and gals of the project and
write down a project vision. Why are they doing this, what
value should it deliver and to who specifically.

These are a couple of paragraphs and it takes two hours max.

Then I would move on to investigate what these specific
user groups do exactly with these critical editions, and
what meaning they have within their overall work.

Extract the information from whatever domain experts,
and boil it down to the essentials.

By this time it should be straight forward (if not still
hard work) to select the overall interaction that realises
the project vision and optimises the productivity of the
specific user groups.

--ps

principal user interaction architect
man + machine interface works

http://mmiworks.net/blog : on interaction architecture

3 Aug 2006 - 5:24am
Fredrik Matheson
2005

First of all, what's the goal of the web app? Is the goal to distribute
critical editions in a new way, handle them in a new way (read, work with,
etc) or both?

So far we've got these two alternatives:

Alternative A:

1. A visual cue points to what items in the text have notes
2. The user can toggle these cues on and off to allow reading vs.
close reading (one might even have a variety of "filters" applied for
different views on the text)
3. Clicking on the link in the text opens a small box with space for x
number of lines. If the footnote is longer than this, a "read more" link is
inserted. Clicking on that link reveals the full footnote in some form, for
example in a large floating box that covers the page (and can be moved
around so you can look at the original text at the same time).

Alternative B:

1. The "page" has two panes: one for the text and one for the notes
2. A visual cue points to what items in the text have notes
3. The user can toggle these cues on and off to allow reading vs.
close reading (one might even have a variety of "filters" applied for
different views on the text)
4. Clicking on a piece of text reveals the related note in the note
pane

Each alternative has its merits. Build a simple prototype and test it - and
let us know which works best.

- Fredrik

3 Aug 2006 - 11:30am
Juan Lanus
2005

Peter Sikking wrote:
> After two days of discussion on widget level, I would say
> let's prepare a basis for some architectural decisions.

Peter is right. A design has to be built on a vision.
I'd try to identify some of application's use cases, in real life.
For to design for the users.

The widget-level discussion is for fun, and we get involved in such
discussions frequently in this list, but cannot be taken as sound
advice because we are throwing uncommited, non elaborated, opinions
about the few paragraphs Steve wrote.
In fact the widget-level discussions draw downwards the subject levels
of this excellent list. But I enjoy them ...

The best would be to talk with prople who will use the service and
have goals with it. The questions are like "what do you want to do
with whis?" for to find out what they are willilng to use the thing
for. Not the newwer system, which the users don't visualize in
abstract, but the existing one. Different subgroups of users might
have very different goals, these might be ... hmmm ... students,
teachers, writers, retired men, ...
This questions are for to understand the users "conceptual model" of
the thing, be it on binded paper or on screen.

Once the goals are identified the next step is to ask "how do you do
this?" for to understand the methods and their drawbacks. Because the
new system is expected to have all the strengths of the existing one,
and no drawkacks.

Do not ask "how do you want do do this?" because you end up with a Homermobile.

This methodology is about textual use cases (no diagrams) and you do
not need to be nothing special for to use it, the hardent skill needed
is to write in your language. And to follow a set of guidelines.
--
Juan Lanus
TECNOSOL
Argentina

4 Aug 2006 - 2:20pm
cfmdesigns
2004

>From: Eugene Chen <eugene at amanda.com>
>
>There might be some reason to consider inline expansion. This would work
>basically the way people use parthenseses.
>
>"The monkey peeled the _banana_ [a Banana is an oblong shaped fruit] and
>smiled mysteriously"
>
>Of course this interrupts the text, but has the least eye movement of all.
>Unlike popup layers, none of the original text is obscured. I've seen this
>done in some help systems, usually clunky, but with the right visual design
>(possible use of dimming, animation) it could have it's place.

Yes, RoboHelp has support for this. Click on the highlighted word and the glossary term expands inline, click again and it collapses back down. The big issue with this is that it distorts the content, making the flow no longer readable as a unit

I would like to see an implementation where a note sidebar appears/disappears, displacing the existing text into a runaround. (The point of difficulty there is apt to be clustered notes, where the space used by the sidebar encompasses another note, and the user wants to view it as well. That's a variation on the footnote packing issue for print: what happens when a footnote and its reference point cannot both fit on the page at the same time?)

-- Jim Drew
Seattle, WA

Syndicate content Get the feed