Luben Tuikov wrote:
quoted text
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Luben Tuikov wrote:
>> 
>>>> It probably is wise to resurrect those "redundant" links.
>>> 
>>> If someone does this, can they also remove the now "other"
>>> redundant link? (the link at the pathname itself) A simple
>>> code analyzer would show the duplicate code in gitweb.
>>
>> I'd rather add some more "hidden" links, but for each hidden
>> link (which are convenience only, to have larger are to click,
>> or to have closer area to click) I'd like to have clearly marked
>> link (marked as a link, i.e. using default link style; and with
>> link text denoting _kind_ of link) which leads to the same contents. 
> 
> Why would you like all this?  If users start using those other links
> all the time, what is the purpose of the "hidden" links as you call
> them? 

It was answered in the part you haven't quoted. Sometimes "hidden link" 
purpose it is to have larger area where we can click, for example in 
"tree" view the name of file (the name of directory is not hidden, as
it uses default link style), in "shortlog"/"heads"/"tags" view the title
(subject) of a commit/ref. Sometimes it is to have link closer, for
example name of files in diff header being "hidden link" to file 
contents before and after the change.

"Hidden links" are in fact half hidden, as I think all of them are 
underlined on mouseover. 

But, as I have said, we cannot use default link style for those "hidden 
links", either because as in "shortlog" view this would negatively 
affect readibility, or it would clash with syntax highlighting as in 
the case of "commitdiff" and "blobdiff" views, or because we have two 
types of object we want to be visually distinct, but there is only one 
default style of links like in the case of directory (tree) and file 
(blob) entries in the "tree" view.
 
quoted text
> Consider the "tree" link between "commitdiff" and "snapshot" 
> (if enabled) in shortlog view.
> 
> Consider the "hidden" link of each entry (file/directory).
> 
> Can you see how they are different?

Yes, "tree" link is small, blue (if not visited), and underlined.
But I guess that wasn't what you had in mind.

IMPORTANT: By the way, by removing 'redundant' "blob"/"tree" link we 
remove the possibility of denoting which links (which directories and 
files) we have visited (sic!).

quoted text
> Introducing this to an engineer who has little knowlege about git:
>    "Click on the file or directory name, to get the file or go into
>     the directory"
> Simple and intuitive, no need to mention "blob" or "tree" or "object".
> Or,
>    "Click on the 'blob' link to get the ... Click on the 'tree' link
>    to get the ... Oh you didn't know what a 'tree' or 'blob' object
>    is? A 'blob' is ... A 'tree' is ..."
>
> At which point the engineer has lost 90% of his interest.

The links are for git and gitweb users. They tell (we assume that git 
user knows what blob, tree, etc. means; we assume that gitweb user 
knows what blob views or tree view means)
    "Click on the 'blob' link to get 'blob' view for current line file"
like the "history" link tells
    "Click on the 'history' link to get history of a current line file"

For example "hidden link" of title/subject of a commit in "shortlog" or 
"history" view doesn't tell us what kind of view it leads too: commit, 
commitdiff? Well, it doesn't tell us that it is link, either... ;-)

quoted text
> It even gets even worse for the obnoxious "tree" link next to each
> commit in shortlog view:
>    "The tree link is the the tree object which is part of a commit
>     object. Oh you don't know the internals of a commit object?
>     A commit object binds a tree object and a (parent) commit object,
>     but blah, blah, blah..." 
> 
> Can you see how all this apparent "simplicity" you're trying to
> introduce contradics the mere links you're introducing it with?

I don't understand you. The "tree" link in shortlog is a _shortcut_ to 
the "tree" view (and I think that one can guess that tree view means 
directory listing in the state as saved by given commit), without it 
you would have to do it in two steps, first going to commit view, then 
clicking on tree in the main navbar. So it is IMHO usefull.

Perhaps you meant "tree" header in "commit" view? There surely we could 
use ordinary link style for sha1 which is tree identifier. Cause surely 
we don't need for the sha1 to be readable, as in the case of commit 
title in the shortlog view. Additionally it would serve as a way to 
distinguish on first glance which headers are clickable, and which are 
not. And there we could I guess loose redundant headers.

[...]

quoted text
> The question is: Given the average engineer, what is the gitweb
> interface such that they can start using it fastest with the minimum
> amount of  questions?

Given average user/programmer... 

quoted text
>> But we agreed (I guess) to disagree on the whole redundancy in user
>> interface issue (although I agree on the issue of reducing clutter).
>> BTW. we can reduce redundancy in the code without need for removing
>> "alternate entry points" in interface, I think.
> 
> Clutter and redundancy is just a part of it.  A larger part is
> how much git or non-git oriented we want to make the interface, which
> seems related to the overall simplicity and intuitiveness.

One must pay atention to not to make interface _too simple_, and less 
usable because of it. And definition of intuitiveness depends on the 
person...

-- 
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