From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:42
Luben Tuikov [off-list ref] writes:
quoted
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.
Very well put. I think this and removal of redundant "tree"
would be worthy changes -- it unclutters things.
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.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:42
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
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,
Your opinion here is highly subjective.
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.
Luben
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:42
Luben Tuikov wrote:
quoted hunk
--- Jakub Narebski <jnareb@gmail.com> wrote:
quoted
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'd like to mention that there are if I remember correctly
some other places, like "commit" view which have this hated by
you redundancy.
--
Jakub Narebski
Poland
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:42
Jakub Narebski [off-list ref] writes:
Luben Tuikov wrote:
quoted
--- Jakub Narebski <jnareb@gmail.com> wrote:
quoted
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.
quoted
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).
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.
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.
By the way, you are right in saying if we were to do icons they
should be out-of-line img with help for text browsers. That
patch was done as illustration not as a serious patch (I am not
a serious gitweb hacker, so anything I do with gitweb, unless it
is an obvious and trivial bugfix, is not meant for direct
inclusion).
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:42
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... ;-)
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.
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).
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
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:42
BTW,
- why do we have shortlog and log twice in the top navigation
bar in commit view (a=commit)?
- 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()?
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:42
Junio C Hamano wrote:
BTW,
- why do we have shortlog and log twice in the top navigation
bar in commit view (a=commit)?
Huh? I don't have shortlog and log twice in top navigation bar
in commit view
a=commit;h=e70866f53a8d31cde6cfff6396ba0d1f64029afb
in gitweb/v1.4.2.3-gd98896b
- 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()?
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.
Quite often, that's _exactly_ the one thing a maintainer should do. Most
"non-bikeshed-painting" issues don't need maintainers. They are obvious to
everybody, and/or there's only one person who actually did the work, and
nobody else ends up beign competent enough, and people know it.
The real glory of maintainership isn't making the big and important
decisions. The real glory lies in all the _small_ stuff that doesn't
really matter, and that people will just argue forever.
The ability to just cut off the stupid debate early about something that
otherwise never gets resolved (or that causes bad feelings just because
people get worked up over some perceived issue), _that_ is what the
maintainer is all about.
Linus
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... ;-)
Junio is doing an excellent job at maintaining GIT! He's
tried to accomodate everyone, since this kind of flexibility
decides how many entities and companies adopt GIT and in return
this makes GIT better, by having those entities and companies
send back patches. It is a well understood loop.
You should take a look at Linux and some subsystem's maintainers
"maintainership". The worst thing by far that can happen to
a project being maintained is when "maintainership" becomes
the maintainer's _job_, as opposed to a professional (specializing
in a contingent field) who is doing maintainership in his spare
time. (i.e. the way it was in the 70s-80s with UNIX.)
Anyway, I digress, sorry.
quoted
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 strongly agree with Junio. Intuition of gitweb spills in all
of its interfaces. The nature of gitweb dictates that certain
things are clickable, simply because it is, after all, a web
interface to none other but GIT.
We don't need an overly explicit interface in gitweb, since gitweb
is not supposed to _teach_ git, but present it.
Take a look at other SCMs interfaces: perforce, cvs, clearcase, etc.
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.
What "beginners" are you refering to? GIT beginners or gitweb beginners?
gitweb is not supposed to be a teaching tool to GIT.
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.
An absolutely excellent argument for the confines of a college course
paper or assignment on GUI. Not very convicing to people with years
and years of experience in SCMs and what-not.
What we want is not some zelous argument about what is the "right"
way or the "proper" way (all very subjective) of doing the interface
of gitweb. What we want is an intuitive and workable interface,
minimizing the number of eye movements, mouse movement, mouse clicks
to get to the information being sought.
Luben