--- Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> 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... ;-)
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.
> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html