visual cues for thumbnails

2 Feb 2004 - 5:56pm
10 years ago
5 replies
588 reads
mprove
2004

Dear ID/As,

in his wonderful book "Tog on Software Design" Tog wrote:

"Thumbnails will replace generic-looking document icons, providing users with visual cues as to the nature of the material inside a container. Their appearance will go beyond today's thumbnails to reflect the amount of material they contain." [p. 196]

This is exactly what I like to do for OpenOffice.org/StarOffice thumbnails representing documents. My idea is to code the number of pages as a stack of sheets.
My question is: Does anybody know about papers or studies on this subject?

thanks,
Matthias

--

User-Centered Software Design http://www.mprove.net

Comments

2 Feb 2004 - 8:00pm
cfmdesigns
2004

Matthias Mueller-Prove <mprove at acm.org> writes:

> in his wonderful book "Tog on Software Design" Tog wrote:
>
>"Thumbnails will replace generic-looking document icons, providing
>users with visual cues as to the nature of the material inside a
>container. Their appearance will go beyond today's thumbnails to
>reflect the amount of material they contain." [p. 196]
>
>This is exactly what I like to do for OpenOffice.org/StarOffice
>thumbnails representing documents. My idea is to code the number of
>pages as a stack of sheets.
>My question is: Does anybody know about papers or studies on this subject?

I don't have info on actual studies, just real experience that pertains.

Coding a number of pages (or a file size) visually will prove
difficult, I think. You'll probably find that the user can really
only differentiate between three values: 1, 2, and many, or small,
medium, and large. (Well, four values, if you include 0 or empty,
which probably isn't a valuable value to include.)

I worked on the RCA eBook (and the SoftBook Reader it grew out of).
We had two sets of "size" icons on the device. Across the top was a
"bookshelf" which filled with books to represent how much space was
used on the device. (Different memory cards could be inserted,
giving different amounts of virtual space.) This representation
worked adequately, giving a good sense of "lots of room", "half
full", "some room", and "just about full" without being specific (you
could get actual numbers elsewhere in the UI). I'm not sure what the
granularity was on this; probably 10% or so.

We also had "book" icons next to the title/author info of each eBook
on the device. There were at least 4 or 5 variant icons showing
different "thicknesses" of books. However, because of the similarity
in the icons, the user could really only tell the difference between
"thin book" and "non-thin" book, maybe as much as three size
differences. Even more, though, was that once you got into the realm
of "thick book", there was no longer any differentiation possible.
The icon size corresponded to rough page count jumps, I think,
something like every 10 or 20 screens/pages jumping to the next size.
Which meant that you could usually see the difference between a 10
page eBook and a 20 page one, but from the icons, there was no
apparent difference between a 100 page eBook and one that topped 1000
pages.

So there's definite value in having your thumbnails and icons and
such give hints to size, multiplicity, and other content info, but I
think there are practical limits to what can be presented in such a
visual manner. Better might be to encode (aka "get displayed") real
values along with the rough visual indicators.

Jim Drew
Seattle, WA

4 Feb 2004 - 7:56am
Alain D. M. G. ...
2003

Hello!

Yes, it is true, giving proportionally sized thumbnails will not give
any significant help for finding documents or distinguisign them . Or
at least, that alone will not sufice but this is another question .You
should read what Tognazzini just wrote on the subject of significant
thumbnails in his analysis of the most recent Mac OS X update. He
seems to have given up hope of seeing any significant thumbnails now or
any time in the near future. It is in three parts on his site:
www.asktog.com.

And he has a good reason for having lost hope. For the last eight
years or so I have been doing research on the topic of generated images
such as enhanced glyphs or enhanced thumbnails and all the papers I
have read and the studies of human cognition of such images (including
things like Chernoff or DeSoete faces) all point out that small, single
images cannot be really useful on our current systems (things might be
different with zoomable user interfaces though, dependding on how they
are implemented) when they are completely automatically generated.

On the other hand, when vou combine small generated images such as
enhanced thumbnails with some measure of interaction with the user,
such as when a search is done and the criteria pop up in the thumbnail,
things are more promising. And if you combine this with information
"collages" then you stand a better chance of geting significant
results.

Take a look at what Alison Wooodruff has done at PARC, and go through
the bilbiographies of her articles. They are very welle done:

This is one of them:
Woodruff, A.; Rosenholtz, R. E.; Morrison, J.; Faulring, A.; Pirolli,
P. L. A comparison of the use of text summaries, plain thumbnails, and
exhanced thumbnails for Web search tasks. Journal of the American
Society for Information Science and Technology. 2002; 53 (2): 172-185.

Alain Vaillancourt

--- Jim Drew <jdrew at adobe.com> a écrit : > Matthias Mueller-Prove
<mprove at acm.org> writes:
>
> > in his wonderful book "Tog on Software Design" Tog wrote:
> >
> >"Thumbnails will replace generic-looking document icons, providing
> >users with visual cues as to the nature of the material inside a
> >container. Their appearance will go beyond today's thumbnails to
> >reflect the amount of material they contain." [p. 196]
> >
> >This is exactly what I like to do for OpenOffice.org/StarOffice
> >thumbnails representing documents. My idea is to code the number of
> >pages as a stack of sheets.
> >My question is: Does anybody know about papers or studies on this
> subject?
>
> I don't have info on actual studies, just real experience that
> pertains.
>
> Coding a number of pages (or a file size) visually will prove
> difficult, I think. You'll probably find that the user can really
> only differentiate between three values: 1, 2, and many, or small,
> medium, and large. (Well, four values, if you include 0 or empty,
> which probably isn't a valuable value to include.)
>
> I worked on the RCA eBook (and the SoftBook Reader it grew out of).
> We had two sets of "size" icons on the device. Across the top was a
> "bookshelf" which filled with books to represent how much space was
> used on the device. (Different memory cards could be inserted,
> giving different amounts of virtual space.) This representation
> worked adequately, giving a good sense of "lots of room", "half
> full", "some room", and "just about full" without being specific (you
>
> could get actual numbers elsewhere in the UI). I'm not sure what the
>
> granularity was on this; probably 10% or so.
>
> We also had "book" icons next to the title/author info of each eBook
> on the device. There were at least 4 or 5 variant icons showing
> different "thicknesses" of books. However, because of the similarity
>
> in the icons, the user could really only tell the difference between
> "thin book" and "non-thin" book, maybe as much as three size
> differences. Even more, though, was that once you got into the realm
>
> of "thick book", there was no longer any differentiation possible.
> The icon size corresponded to rough page count jumps, I think,
> something like every 10 or 20 screens/pages jumping to the next size.
>
> Which meant that you could usually see the difference between a 10
> page eBook and a 20 page one, but from the icons, there was no
> apparent difference between a 100 page eBook and one that topped 1000
>
> pages.
>
> So there's definite value in having your thumbnails and icons and
> such give hints to size, multiplicity, and other content info, but I
> think there are practical limits to what can be presented in such a
> visual manner. Better might be to encode (aka "get displayed") real
> values along with the rough visual indicators.
>
> Jim Drew
> Seattle, WA
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca

4 Feb 2004 - 2:44pm
Michael R. Bernstein
2003

Jim Drew wrote:
>
> I don't have info on actual studies, just real experience that
> pertains.
>
> Coding a number of pages (or a file size) visually will prove
> difficult, I think. You'll probably find that the user can really
> only differentiate between three values: 1, 2, and many, or small,
> medium, and large. (Well, four values, if you include 0 or empty,
> which probably isn't a valuable value to include.)
>
> [snip] Which meant that you could usually see the difference between
> a 10 page eBook and a 20 page one, but from the icons, there was no
> apparent difference between a 100 page eBook and one that topped 1000
> pages. along with the rough visual indicators.

In the examples you cite, I get the impression that the values were hard
coded. It seems to me that this feature would be more likely to be
useful if the values were dynamic, based on a simple statistical
analysis of the document sizes, for example if the medium icon was used
for all documents in the 25-75 percentile range, etc., and the small and
large icons were only used for the outliers.

- Michael Bernstein

4 Feb 2004 - 6:54pm
cfmdesigns
2004

Michael Bernstein <webmaven at cox.net> writes:

>Jim Drew wrote:
>>
>>I don't have info on actual studies, just real experience that
>>pertains.
>>
>>Coding a number of pages (or a file size) visually will prove
>>difficult, I think. You'll probably find that the user can really
>>only differentiate between three values: 1, 2, and many, or small,
>>medium, and large. (Well, four values, if you include 0 or empty,
>>which probably isn't a valuable value to include.)
>>
>>[snip] Which meant that you could usually see the difference between
>>a 10 page eBook and a 20 page one, but from the icons, there was no
>>apparent difference between a 100 page eBook and one that topped 1000
>>pages. along with the rough visual indicators.
>
>In the examples you cite, I get the impression that the values were hard
>coded. It seems to me that this feature would be more likely to be
>useful if the values were dynamic, based on a simple statistical
>analysis of the document sizes, for example if the medium icon was
>used for all documents in the 25-75 percentile range, etc., and the
>small and large icons were only used for the outliers.

Yes, I believe that they were hardcoded. That was certainly part of
the problem. (Oh, and I don't recall if it was "page count" or file
size which determined the icon, and thus whether a single page item
with a big graphic could cause a misleading icon. I think it could.)

But if they are not hardcoded and are relative instead, you then run
into problems of scope and focus changes. Taking your example -- use
a small icon for items under 25% of average size, big icon for about
75%, and medium for the others, you are fine until the average
changes. Worst case: all your documents are in the range of 1-20
pages, giving a range of icons used; then you add in a 1000 page item
(this combo may not be uncommon in some scenarios); suddenly, one
item uses the big item and everything else uses the small one. And
you thus have two problems at once: first, the value of the icon
sizes has been lost because the extreme one imbalanced the stats, and
second, relative sizing gained value by accumulated user knowledge,
knowledge which didn't go away with the imbalancing but which now
must be slowly discarded and replaced, and which may have to be
repeatedly reacquired as the stats shift over time.

One answer might have been user customization: let the user determine
what icon to use with what size (and give them stats to help on
that), so that they could shift their knowledge as things changed and
kept things current and valuable. Another might have been metadata
such that all items didn't get identified with highly similar "book"
icons; rather, have book, magazine, newspaper, photo album, and so on
icons, maybe with size variations or text attached to the icon to
help parse it even better.

The point remains the same, though: too many variants, especially at
larger/higher values and complexity, all blurs together when
presented solely visually.
--

Jim Drew
Seattle, WA

9 Feb 2004 - 10:13pm
Dan Zlotnikov
2004

I think you pointed that out in your later post, Jim, but there are
very serious problems with relative vs. absolute size. First off, what
is the icon "size" meant to indicate? The absolute file size or the
number of pages in a text document? If the former, a high-res image
would swell the thumbnail to "thick," even if it's only one page in
length.

Then, we run into the whole problem of physical drive space not being a
constant. In a relative representation system, a file that's "average" on
my 20GB drive might be "ohmygodthat'stoobig!" on the 6GB drive. (As a
side note, I'm curious what the latter thumbnail would end up looking
like.)

I'm all for using varying images for different document types, but that
runs into the already existing problem of confusing and frequently
misleading proliferation of obscure icons. Take the *.sys and *.ini file
icons on an XP system. The only way a regular user can divine their
meaning is by knowing up front what these arbitrary symbols represent.

A final question concerns directory/folder thumbnails: Would the
thumbnail "size" indicate the total size of the contents, their total
amount of text, or the number of items inside the directory? This
example is important, in my opinion, because it suggests that there
will be other situations where more than two things can be indicated by
thumbnail "size."

Dan Zlotnikov
WatCHI
www.acm.org/chapters/watchi

On Mon, 2 Feb 2004, Jim Drew wrote:

> I worked on the RCA eBook (and the SoftBook Reader it grew out of).
> We had two sets of "size" icons on the device. Across the top was a
> "bookshelf" which filled with books to represent how much space was
> used on the device. (Different memory cards could be inserted,
> giving different amounts of virtual space.) This representation
> worked adequately, giving a good sense of "lots of room", "half
> full", "some room", and "just about full" without being specific (you
> could get actual numbers elsewhere in the UI). I'm not sure what the
> granularity was on this; probably 10% or so.

Syndicate content Get the feed