VisualID SigGraph2004 paper

Holger Waechtler holger at qanu.de
Sat Jul 10 20:30:15 BST 2004


Roger Larsson wrote:
> On Saturday 10 July 2004 11.53, Holger Waechtler wrote:
> 
>>Roger Larsson wrote:
>> > Using "Huge" icon size together with "folder icons reflects content"
>> > gives a nice visual aid for many files.
>>
>>yes, but for backup copies and derived projects with very similiar
>>content the "similiar content versus similiar filename" issue from the
>>paper discussion arises again. Maybe a combined icon made from
>>thumbnail, visualID and the folder logo would be best.
> 
> 
> I think you should select thumbnail or visualID with mime icon blended in.
> (probably minimal)
> 
> Why?
>   Images, video, web pages (html and war), pdf, works well as thumbnail.

only if you don't talk about about different only slightly modified 
versions of a file like it is the case for backup-copies (CAD and EDA 
tools safe up to 10 automatically generated backup copies with almost 
the same name in the directory).

The shape grammars would make all the backup copy IDs looking similiar 
in shape to the original but clearly distinguishable since their file 
names have all the same type of ending like e.g. ".$$1"...".$$9" or 
".b01"...".b09" versus the original file suffix.


>   Documents (.doc) works somewhat (rendering of a full page helps)
>   Source code, text does not work at all, maybe because it is not
>   rendered a full page... (but what is a full page? pipe through a ps
>   formatter?)

For source code it may be important to start preview right after the 
copyright header, then it's probably a little more distinguishable.


>> > > Maybe it's an interesting approach that might get incorporated into
>> > > konqueror/kfm/nautilus/thegnomefilemanager, maybe some of you are
>> > > interested in their research results,
>> > > have a good weekend,
>> >
>> > Generating icons from filename only and not contens is an interesting
>> > approach! (I think I would like it)
>>
>>Given the code snippets in the paper it seems not too hard to implement
>>(maybe to enable it as a user-configurable display option for those of
>>us who don't want to spend all their memory on icon navigantion - ;).
>>
> 
> 
> But all this code might actually be faster than reading content from
> disk - disk is slow compared to CPU...
> 
> But there might be simpler approaches... lets see
> take two and two characters and them with 31 use one as x the other as y
> in a 32 by 32 icon, first pair uses first VGA16 color then the second...
> Scale to icon size...
> Or use two pairs to draw lines in a bigger matrix...

:) well -- I like these organically grown forms generated by their code, 
they look so natural; at least for me this makes them easier to remind 
and lets the user imagine them as landscape or forest of plants or world 
of microbes to navigate in visually...
;)

But in any case the "shape grammar generators" can be made "themeable", 
the authors of the paper outlined this for the branding example of a CAD 
package.


>>Since thumbnail previews are still useful for a wide range of file types
>>the best icon display style might be a combination of the classic
>>mime-type icon (or "brand logo" like they call it in the paper in the
>>example picture on page 6), the content thumbnail and the visualID
>>generated from the file name.
> 
> 
> I can not imagine that all three combined could work...

just blend them together: the big graphical representation of the file 
name that eases your orientation combined with a small "brand logo" or 
mime-type icon on the lower right (to this point the icon looks like the 
picture on page 6 of the VisualID paper), and then the rendered 
thumbnail either as icon background or as downscaled micro-subicon (with 
a size slightly larger than the mime-type micro-subicon) placed e.g. 
slightly left and above or below the brand icon with some overlap.

The preview thumbnail could also simply replace the brand logo or 
mime-type icon if the user wishes so and specifies this in his 
configuration dialog...

Holger



More information about the kfm-devel mailing list