That is assuming that users would rather read natural language than scan
a page for data. Personally, I think that forming the data into
something that looks like a sentence has real limitations. If we want
our pages to be scannable, I suggest that aligning fielded data and
labels along an axis is good design practice. Additionally, offsetting
the labels in another color is also beneficial. Building a typographical
hierarchy to represent the most important information would also help.
Would we want to turn the data on a page into a single paragraph? Like so:
This item is a book titled "The Society of the Spectacle" (Société du
spectacle) written by Guy Debord and published in 1994 in New York by
Zone Books. It has been translated into English from French, is 154
pages long, and has a Library of Congress call-number of HM291 .D413
1994. The book is identified by two ISBN numbers of 0942299795 and
0942299809 and contains information relevant to the subjects of social
phsychology, proletariat, and social classes.
I think the Open Library's record is much friendlier:
http://openlibrary.org/b/OL2216632M/society-of-the-spectacle
Here there is a well developed typographical hierarchy where the title
is in largest type, followed by smaller text (and a line break) for the
byline, and followed by another line break and lighter text for the
publisher. The rest of the metadata is aligned in a tabular arrangement
with the labels in another color than their values.
I think "language, phrases, sentences" are really useful when they are
used for things like a synopsis, author biography, or reviews of the
work. I don't think that we need to pretend that our data isn't data.
We also shouldn't be afraid of prioritizing data within the user
interface. The way Borders deals with some of the issues mentioned
earlier in this thread could be useful. On this Borders page for Soft
Subversions (ugly URL below), the author is listed at the top with the
title and additional contributors are found near the bottom of the page
from an anchored link that says "see all contributors." Here you find
the editor of the book. Also, Borders has a textual description of the
book before the fold and subjects which are labeled "Browse Related
Categories," letting users know what kind of functionality they will be
getting if they click one of those links.
(http://www.borders.com/online/store/TitleDetail?type=1&catalogId=10001&simple=1&defaultSearchView=List&keyword=soft+subversions&LogData=[search%3A+22%2Cparse%3A+28]&searchData={productId%3Anull%2Csku%3Anull%2Ctype%3A1%2Csort%3Anull%2CcurrPage%3A1%2CresultsPerPage%3A25%2CsimpleSearch%3Atrue%2Cnavigation%3A5185%2CmoreValue%3Anull%2CcoverView%3Afalse%2Curl%3Arpp%3D25%26view%3D2%26type%3D1%26nav%3D5185%26simple%3Dtrue%26book_search%3Dsoft%2Bsubversions%2Cterms%3A{book_search%3Dsoft+subversions}}&storeId=13551&sku=1584350733&ddkey=http:SearchResults)
Best,
Chris
Karen Coyle wrote:
> Deborah Fritz wrote:
>
>> Title: Poems from Cuba
>> Other title information for title: alone against the sea
>> Parallel title: Poesia desde Cuba
>> Other title information for parallel title: solo contra el mar
>> First statement of responsibility: Raul Mesa
>> Subsequent statement of responsibility: edited with a preface by Harley D.
>> Oberhelman
>> Subsequent statement of responsibility: translated from the Spanish by James
>> Hoggard
>>
>>
>>
>
> I REALLY dislike the labeled displays. I think they get in the way of
> the text you want users to focus on, the actual information you are
> wanting to convey. What would be wrong with:
>
> Poems from Cuba, alone against the sea. (Poesia desde Cuba, solo contra
> el mar) by Raul Mesa. Edited with a preface by Harley D. Oberhelman.
> Translated from the Spanish by James Hoggard.
>
> After all, this isn't DATA it's language, phrases, sentences. We don't do:
>
> Paragraph:
> Sentence:
>
> We have simple conventions (indenting, full stops) that people
> understand. Can't we continue to use those? Can't we say: "Published by
> Grove Press in 1967?" It's so ironic that we have both failed to treat
> our data like data, relying much to heavily on text, but then we make it
> look too data-ish when we display it to users.
>
> kc
>
>
>
Received on Mon Mar 16 2009 - 18:05:33 EDT