Subject: Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

From: Jakub Narebski <[email-masked]>
Date: Sun, 1 Oct 2006 20:41:14 +0200

On Wed, 27 Sep 2006, Junio C Hamano wrote:
> If the only objection is that it is harder to realize that the
> remaining one (the other one that did not get removed by this
> redundancy elimination) is clickable, maybe that is what needs
> to be fixed.

But that is plain impossible without compromising interface usability.
Let me explain. 

In the case of tree view (directory listing) we have blobs (files and 
symlinks) and trees (directories). To mark item unequivocably as link 
it has to have default link color (blue) and default link decoration 
(underline). That means that we cannot distinguish really well (at 
least color) between tree and blob entries. I'd rather have redundant 
"blob"/"tree" (self)links, clearly marked as links, and tree entries 
using link decoration (blue, underlined) while blob entries have 
default text decoration (black, no underline).

In the case of shortlog/log/history/heads/tags view, to clearly mark 
subject/title of a commit or tag as link, we would have to use default 
link decoration. Let's for a while abandon link-within-link, i.e. using 
some of committags also in commit title (in shortlog/history view)...
But underlined text is harder to read, and blue underlined text even 
more so (as for example it is hard to read italics, commonly used for 
emphasis). I'd rather have additional "commit" link, clearly marked as 
link, and leave subject as is, as hidden link, as a shortcut.

I think that redundancy in a visual interface (and not only visual, as 
seen in the example of Perl programming language) is a good idea, 
contrary to the redundancy in code or data (database).
-- 
Jakub Narebski
Poland