On Tue, 3 Oct 2006, Junio C Hamano wrote:

quoted text
> Honestly, I _hate_ to be in the position to decide in which
> color the bikeshed should be, but sometimes that is what a
> maintainer has to do.

Joys and tribulations of being maintainer... ;-)
 
quoted text
> I personally feel that in a list that is one line per item, like
> the shortlog, we do not necessarily have to underline the log
> message even though they are clickable.  The purpose of the list
> is to show things so people can read them.  Readability matters.
> At the same time we would want to give access to object details;
> I think it is Ok not to give underline to them, as long as
> people can easily pick up the convention that each of these
> listed items is clickable to obtain details about it.

And the current convention of underlining "hidden links", like
the subject line in shortlog/log/heads/history view, is a good
hint of the convention.

quoted text
> We should 
> probably make other clickable links at the right, such as "tree"
> and "snapshot", visually stand out, by giving underline as we
> already do.  They are not really "text", but clickable icons
> that happen to be done with text (as opposed to being done with
> img).

Additionally we use slightly smaller font for those links
(in addition to using default style for links).

quoted text
> By the same logic, the purpose of the tree view is to show
> contents of a tree object.  If the user picks up the convention
> for the short log that each listed commit can be clicked to
> obtain details about it, it probably is natural for the user to
> expect that each listed entry in the tree view can be clicked to
> obtain details about it, so not showing the redundant tree/blob
> link is in line with that.  And it would be consistent not to
> give underline to the file or directory names.

I'd rather have underline for directory names to distinguish
it even more from files (blob entries), even for monochromatic
text display.


I am of two mind about removing "redundant" links movement.

First, I don't thing that avoiding redundancy in _user interface_
is a good argument. We sometimes add redundancy, for example in
commitdiff view for each patch we have sha1 of blob in the gitweb
header clickable, and obvously link, and we have the names of from
and to files in diff header "hidden links" and clickable. I could
agree with the argument about removing redundancy from the _code_,
and/or with the argument about _uncluttering_ interface.

Second, removing "redundant" links coupled with the fact that
the links the removed links duplicated cannot for mentioned resons
have default links style, so it is harder to guess that they are
links ("mystery meat navigation", although not in it's worst edition).
So there is tradeoff. Uncluttering the interface and simplifying
the code, but at the cost of gitweb interface being harder to beginners.
It is a question of policy then, do we cater to beginner users, or to
advanced users (which know/discovered that file name in tree view
and commit subject/title line in shortlog are links to respectively
blob view of a file and commit view of a commit).

Third, we should be consistent: either leave redundant links, perhaps
separating it by putting it into separate "selflink" column (see for 
example tags view), or remove redundat links where possible in all 
views.

-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html