patchgitweb: tree view: eliminate redundant "blob"

> Binary and non-binary blobs:
>
> The "list" table element of tree view is identical
> to the "blob" link part of the link table element.
> I.e. clicking on "blob" is identical to clicking on
> the entry itself.

> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > Binary and non-binary blobs:
> >
> > The "list" table element of tree view is identical
> > to the "blob" link part of the link table element.
> > I.e. clicking on "blob" is identical to clicking on
> > the entry itself.
> 
> Then perhaps we can lose tree link for the same reasoning?

> Binary and non-binary blobs:
> 
> The "list" table element of tree view is identical
> to the "blob" link part of the link table element.
> I.e. clicking on "blob" is identical to clicking on
> the entry itself.
> 
> Thus, eliminate "blob" from being shown -- the user
> can get identical result by simply clicking on the
> entry itself.

> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> I'd rather not. The fact that the file name and tree name is link,
>> and the fact that commit title and tag title is link is a _convenience_.
>> Not always it is visible (without mouseover) that it is link.
>> And it is _not_ visible in the case of files!
> 
> Then that should be fixed.
> 
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.

>> And for example for commits and heads there are two possible
>> views, commit and commitdiff for commit, shortlog and log for head,
>> of which we arbitrary chose one for the subject link. So in that
>> case the additional self link is needed. I'd rather have both.
> 
> For commits and heads, I agree. But that's not what this patch does.

> 
> > And for example for commits and heads there are two possible
> > views, commit and commitdiff for commit, shortlog and log for head,
> > of which we arbitrary chose one for the subject link. So in that
> > case the additional self link is needed. I'd rather have both.
> 
> For commits and heads, I agree. But that's not what this patch does.
> 
> > And for consistency I'd rather always have visible form default
> > self link/
> 
> A parse error kicked me off here, sorry.
> 
> 
> (I'm personally kind of ambivalent to the change.)
> 
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> -
> 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
> 

> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> I'd rather not. The fact that the file name and tree name is link,
>> and the fact that commit title and tag title is link is a _convenience_.
>> Not always it is visible (without mouseover) that it is link.
>> And it is _not_ visible in the case of files!
>
> Then that should be fixed.
>
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.

> Petr Baudis <pasky@suse.cz> writes:
> 
>> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
>> where Jakub Narebski <jnareb@gmail.com> said that...
>>> I'd rather not. The fact that the file name and tree name is link,
>>> and the fact that commit title and tag title is link is a _convenience_.
>>> Not always it is visible (without mouseover) that it is link.
>>> And it is _not_ visible in the case of files!
>>
>> Then that should be fixed.
>>
>> And directories should have trailing slash in their name in the tree
>> listing, for people with non-UNIX background who don't understand the
>> ls -l like output.
> 
> I am with you on both counts.  For the latter, people might
> actually like mode string to be changed to pretty pictures,
> though.

> I'd rather not. The fact that the file name and tree name is link,
> and the fact that commit title and tag title is link is a _convenience_.
> Not always it is visible (without mouseover) that it is link.
> And it is _not_ visible in the case of files!
> 
> And for example for commits and heads there are two possible
> views, commit and commitdiff for commit, shortlog and log for head,
> of which we arbitrary chose one for the subject link. So in that
> case the additional self link is needed. I'd rather have both.
> And for consistency I'd rather always have visible form default
> self link/
> 
> I'd rather have additional link, than cause confusion to the users.
> Perhaps we could separate the self link ("blob" for files, "tree"
> for directories) into separate column?
> 
> Besides, you have to mouse over the name of file, or name of
> directory to see to what view it would lead on.

> 
> Nak.
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> 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
> 

> Jakub,
> 
> I understand your argument completely.  Underlining/coloring/etc
> entities which are "links" themselves was very cool circa 1993 when
> I took an HTML course (NSA Mosaic or rather...), transitioning from
> "gopher" to the WWW.
> 
> Over the years I've seen a transition where web content is more and
> more context sensitive, i.e. everything you can see is in some way
> "clickable".  Be it letters, words, sentences, graphical objects of
> some sort, etc.  If you could imagine: any web content being a "wiki
> on steroids".
>
> Generally, this WEB Development argument goes as follows:
>     "There is no reason for anything to not be clickable."
> 
> Thus, I like the fact that gitweb is on the forefront of WEB development.
> We should keep it like that.

> This is example of where forefront has it wrong. I'm all for "list" entry
> to be link to default view, but I'm all against removing clearly marked
> link to "plain"/"tree" view.
> 
> And "invisible links" _especially_ if the link is not convenience only
> (i.e. it is not provided clearly as link somewhere else) is so called
> "mystery meat navigation" and is one of the most common mistakes in
> web development.
> 
> And is not as if "plain |" takes much space...

> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> This is example of where forefront has it wrong. I'm all for "list" entry
>> to be link to default view, but I'm all against removing clearly marked
>> link to "plain"/"tree" view.
>> 
>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>> 
>> And is not as if "blob |" takes much space...
> 
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".

> Either that or you can think of it as "shortening" the line.
> Wlg, suppose that I have a file called "blobname" and a directory
> called "treename":
>     mode blobname    blob | blame | history | raw
>     mode treename    tree | history
> Is equivalent to
>     mode blobname    blame | history | raw
>     mode treename    history
> For any name "blob" and any name "tree".

>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>> 
>> And is not as if "plain |" takes much space...
>
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".
>
> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.
>
> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will.
>...
> Either that or you can think of it as "shortening" the line.

> 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....
> But underlined text is harder to read, and blue underlined text even 
> more so...

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... That means that we cannot distinguish really well (at 
> > least color) between tree and blob entries.
> 
> Do we even say links are blue and underlined by forcing that in
> our css?

> > 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....
> > But underlined text is harder to read, and blue underlined text even 
> > more so...
> 
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue.  In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.

> Junio C Hamano wrote:
> 
>> Doesn't leading drwxr-xr-x mean anything?
> 
> Neither d in drwxr-xr-x, nor trailing / in the name are significant
> enough indicators of directory vs file (tree vs blob) indicator,
> especially that by default git-ls-tree output mixes trees with blobs.
>  

> Jakub Narebski wrote:
>> Junio C Hamano wrote:
>> 
>>> Doesn't leading drwxr-xr-x mean anything?
>> 
>> Neither d in drwxr-xr-x, nor trailing / in the name are significant
>> enough indicators of directory vs file (tree vs blob) indicator,
>> especially that by default git-ls-tree output mixes trees with blobs.
>>  
> 
> I beg to differ. The trailing slash would indeed help, as peoples eyes 
> are generally focused on the mouse-pointer rather than some 5-10" to the 
> left of it. If we're worrying that windows folks use \ for 
> path-delimiter, I think they'll pick up the difference quick enough.

> Jakub Narebski <jnareb@gmail.com> writes:
>
>> ... That means that we cannot distinguish really well (at 
>> least color) between tree and blob entries.
>
> Do we even say links are blue and underlined by forcing that in
> our css?
>
> Doesn't leading drwxr-xr-x mean anything?
>
> Why is making the distinction important in the first place?

> Junio C Hamano <junkio@cox.net> writes:
> 
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> ... That means that we cannot distinguish really well (at 
>>> least color) between tree and blob entries.
>>
>> Do we even say links are blue and underlined by forcing that in
>> our css?
>>
>> Doesn't leading drwxr-xr-x mean anything?
>>
>> Why is making the distinction important in the first place?
> 
> Anyhow, I was too tired to sleep after an unscheduled day-job on
> Sunday X-<, and whipped this up for fun.
> 
> -- >8 --
> [PATCH] gitweb: remove UNIXy mode bits from tree display
> 
> and replace it with an image icon for cuteness ;-).

> +td.executable {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBgYGdgMEhgUFBgYGJgcBKAIiAbKAIUB8oyMAAANBcCqbivEbgAAAAASUVORK5CYII=);
> +  background-repeat: no-repeat;
> +}
> +
> +td.folder {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAAB1JREFUCNdjYGBgkGFgUGJgcPzA4CCABdV/ACoBAFTTBQ822ZerAAAAAElFTkSuQmCC);
> +  background-repeat: no-repeat;
> +}
> +
> +td.regular {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAABtJREFUCNdjqD/A4JDA4BDA4FDB4MCBHdX/AACO5wbfUNnbqwAAAABJRU5ErkJggg==);
> +  background-repeat: no-repeat;
> +}
> +
> +td.symlink {
> +  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA0AAAANAQMAAABIJXY/AAAABlBMVEX///+UAN7OszyBAAAAAXRSTlMAQObYZgAAACVJREFUCNdjYGBg4G9gMEhgUFBgcBAAIQYYYlFg4ElgkG8AKgEARSsDX750+Y0AAAAASUVORK5CYII=);
> +  background-repeat: no-repeat;
> +}
> +

>  # convert file mode in octal to symbolic file mode string
> +sub kind_class {
> +	my ($type, $mode) = @_;
> +	$mode = oct $mode;
> +	if (S_ISDIR($mode & S_IFMT)) {
> +		return 'folder';
> +	} elsif (S_ISLNK($mode)) {
> +		return 'symlink';
> +	} elsif (S_ISREG($mode)) {
> +		# git cares only about the executable bit
> +		if ($mode & S_IXUSR) {
> +			return 'executable';
> +		} else {
> +			return 'regular';
> +		};
> +	}
> +}
> +

> @@ -1651,7 +1668,9 @@ sub git_print_tree_entry {
>  	# the mode of the entry, list is the name of the entry, an href,
>  	# and link is the action links of the entry.
>  
> -	print "<td class=\"mode\">" . mode_str($t->{'mode'}) . "</td>\n";
> +	my $kind = kind_class($t->{'type'}, $t->{'mode'});
> +	print "<td class=\"$kind\">&nbsp;</td>\n";
> +
>  	if ($t->{'type'} eq "blob") {
>  		print "<td class=\"list\">" .
>  			$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... That means that we cannot distinguish really well (at 
> > least color) between tree and blob entries.
> 
> Do we even say links are blue and underlined by forcing that in
> our css?
> 
> Doesn't leading drwxr-xr-x mean anything?
> 
> Why is making the distinction important in the first place?
> 
> > 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....
> > But underlined text is harder to read, and blue underlined text even 
> > more so...
> 
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue.  In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.

> 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 <jnareb@gmail.com> wrote:
>> 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,
> 
> Your opinion here is highly subjective.

> Luben Tuikov wrote:
>> --- Jakub Narebski <jnareb@gmail.com> wrote:
>>> 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,
>> 
>> Your opinion here is highly subjective.
>
> Yours too.
>  
>> Years of experience make certain things "make sense" and other
>> "make less sense".  Note that that is in itself subjective.
>> 
>> Give it 10 years, your opinion will change.
>
> Perhaps. Perhaps not.
>
> I guess we have to agree to disagree. It's Junio opinion that
> matters (which patches would get accepted).

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

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

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

> 
>  - sometimes I'd like to view my tags sorted by name not by
>    age.  Maybe we could add <sort-by> control on the age and
>    name columns for git_tags_body()?
> 
> 
> 

> On Tue, 3 Oct 2006, Junio C Hamano wrote:
> 
> > 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... ;-)

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