Last night I had a thought about user interfaces that may be worth
passing on. It regards the issue of how to present a list of documents
in a way that is intuitive for the user, yet still provides some degree
of resistance to attacks like "typo-spamming". There are several
variations of this problem, but for the purpose of this post lets assume
that all I want to do is present a simple list of some recent documents
of interest, sorted by author name and title.
Author Document Title
------------ ------------------
Oscar the Grouch Collecting Garbage <-- on Sesame Street
Oskar the Grouch Collecting Garbage <-- in Java
Part of the problem is balancing brevity of presentation to the user,
with the need for authentication. If you simply allow authors to pick
their own name and title, several authors might pick names and titles
that are very similar, or even identical. This problem becomes much
more severe when you consider "hostile" authors that are deliberately
trying to forge another author's work.
To help address this problem, Freenet uses some well-known cryptographic
authentication techniques. From a pure client GUI point of view, I'm
pretty sure we can ignore the details of this procedure in most cases,
and just think of it as assigning a long digital number to each document.
Behind the scenes, some work happens which makes it very difficult for
two or more authors to claim the same document number.
This goes a long way towards preventing fraudulent documents and such.
Unfortunately, such long numbers are not easy for the user to recognize
and/or compare. We can ask each author to pick a "human-readable" name
for themselves or the document, but that doesn't prevent multiple
authors from claiming a similar human-readable name or title. Here's a
highly-shortened example, with apologies to those who don't have
monospaced fonts.
Author Document Title Version Signature
---------------- ------------------ ----- -------------
Oscar the Grouch Collecting Garbage n/a 0030230404203
Oscar the Grouch Collecting Garbage n/a 5034234404203
Oskar the Grouch Collecting Garbage 0.3 9977282820222
Oskar the Grouch Collecting Garbage 0.3 9977293930222
Oskar the Grouch Collecting Garbage 0.4 9977293930222
Oskar the Grouch Correcting Garbage 0.0 9977293930222
So, to help address this problem, we could visually group together
identical table entries that are in adjacent rows of the same column.
In a client, we can do the grouping with little boxes or background
colors, and I'd put an extra emphasis on entries that were identical
in every way except the signature. Even in ASCII, though, you can
still get the general idea:
Author Document Title Version Signature
---------------- ------------------ ----- ---------------
| Oscar the Grouch | Collecting Garbage | n/a | 0030230404203
| Oscar the Grouch | Collecting Garbage | n/a = 5034234404203
= Oskar the Grouch | Collecting Garbage = 0.3 | 9977282820222
= Oskar the Grouch | Collecting Garbage = 0.3 = 9977293930222
= Oskar the Grouch | Collecting Garbage | 0.4 = 9977293930222
= Oskar the Grouch = Correcting Garbage = 0.0 = 9977293930222
OK, that's the simple idea about GUI that I wanted to share. "Visually
associate elements that are identical, and disassociate elements that
are nearly-identical." That's pretty much a client GUI thing, but it
does bring up the following issue, which may be of interest to a larger
audience.
In the above table, I added two columns (text author name, and version)
that AFAIK are not recognized by the server. The client would just
stick them into the document somewhere with a tag of some kind that
lets an identical client find and extract the data.
So what I'm wondering is: 1) should client authors try to standardize
somewhat on fields like these, and 2) would such fields ever be of
interest to the server? Regarding clients, if a client introduces an
optional tag that proves to be useful, like "preferred author name", it
would be nice if other clients could read and write the same tag.
Regarding servers, tags such as "date/version" may eventually migrate
to the server side of things, so we want to make sure that our client
shenanigans coordinate well with future directions of the server stuff.
To help illustrate just how many client-side information tags I've been
kicking around lately, here's a draft of a client for I was thinking
about recently. The form would be presented to the user when they were
inserting a new document.
-----------------------------------------------------------------
- Your digital signature (required): [select from list]
- Your preferred text name for that digital signature (optional):
Note: this text name will be displayed, unencrypted, to others.
Do not use your real name if you wish to be anonymous.
- Document title (required):
- Document date/version (optional):
The following fields are strictly optional, and are not even
applicable in many cases. Note these fields will be displayed,
unencrypted, to all Freenet users who decode the document.
- Standardized category/categories into which you think this
document fits: [select from several lists]
- URL for more information about this document:
- URL for more information about the author:
- E-mail address of the author:
- Author's preferred authentication system:
- Author's alternate authentication system:
-----------------------------------------------------------------
These fields would be put into the document somewhere, with the
expectation that the receiver's client might see the fields and extract
them from the document automatically. The fields could then be used to
create tables showing author name & document name, or buttons that fire
up a browser or authentication service, or whatever.
For clients, I'm wondering if we should make some effort early on to
separate out a part of a document that is designed for things that are
specifically for the use of clients which choose to recognize them.
If so, then it may be a good idea to have some kind of registry (in
sourceforge, perhaps?). Friendly client authors can agree on tag
formats and names, so that popular tags can be interpreted by multiple
clients (or at least ignored reliably).
As far as servers go, it seems pretty safe to bet that such things
should be left out of the server code as much as possible. Even so,
the functionality of certain tags may overlap with planned features
of future server releases, so the server folk may want to monitor
what tags the client authors are using & how well they work. For
example, the tags "version" and "frequency of periodical
publication" may eventually be of concern to clients.
Opinions?
--Will
(not speaking for his employers)
willdye at willdye.com
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
