From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
Date: Wed, 27 Sep 2006 00:24:21 +0200 [thread overview]
Message-ID: <efc9af$7ic$1@sea.gmane.org> (raw)
In-Reply-To: 20060926213236.79160.qmail@web31815.mail.mud.yahoo.com
Luben Tuikov wrote:
> --- 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".
If you need to mouseover to discover that a part of webpage is link, it is
mystery meat navigation. Not in it's worst kind (it is quite obvious on
mouseover that that part is link), but still.
> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.
But some links are hidden. But there is always (or should be always)
visible, i.e. in default link colors (blue for unvisited), and default
decoration (underline not only on mouseover - that's mystery meat
navigation).
> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will. The redundancy is so well defined that
> even applying a simple algorithm to gitweb.perl will discover it.
Redundancy is not always bad. Especially in interface.
> 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".
But then we _must_ (to not have mystery meat navigation) mark "blobname"
and "treename" _clearly_ as links, while using different visual (e.g.
different colors) to clearly distinguish between "blob" entry and "tree"
entry. And no, mode and remaining links (well, "raw") is not enough.
Which is somewhat contradictory. And makes interface somewhat inconsistent
(although removing both "blob" link for blobs and "tree" link for trees is
a step towards consistency).
> Plus the code (gitweb.perl) has less redundancy and overhead.
Redundancy in _interface_ is not always bad. We have a lot of redundancy
(mostly via hidden _convenience_ links) in gitweb interface.
Overhead? What overhead? Creating the page? It's negligible. Size of the
page? It is small enough for current net bandwidths; creation time is
bottleneck (not for "tree" view though), not the bandwidth.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
next prev parent reply other threads:[~2006-09-26 22:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 5:38 [PATCH] gitweb: tree view: eliminate redundant "blob" Luben Tuikov
2006-09-26 6:34 ` Junio C Hamano
2006-09-26 17:04 ` Luben Tuikov
2006-09-26 8:54 ` Jakub Narebski
2006-09-26 9:22 ` Jakub Narebski
2006-09-26 16:07 ` Petr Baudis
2006-09-26 16:24 ` Jakub Narebski
2006-09-26 20:33 ` Luben Tuikov
2006-09-27 2:40 ` Junio C Hamano
2006-10-01 18:49 ` Jakub Narebski
2006-09-26 20:14 ` Luben Tuikov
2006-09-26 20:31 ` Jakub Narebski
2006-09-26 21:32 ` Luben Tuikov
2006-09-26 22:24 ` Jakub Narebski [this message]
2006-09-26 22:30 ` Jakub Narebski
2006-09-27 6:42 ` Junio C Hamano
2006-10-01 18:41 ` Jakub Narebski
2006-10-01 18:56 ` Junio C Hamano
2006-10-01 19:27 ` Jakub Narebski
2006-10-02 7:15 ` Andreas Ericsson
2006-10-02 10:56 ` Jakub Narebski
2006-10-02 7:34 ` Junio C Hamano
2006-10-02 11:06 ` Jakub Narebski
2006-10-02 19:46 ` Luben Tuikov
2006-10-02 19:11 ` Luben Tuikov
2006-10-02 20:03 ` Jakub Narebski
2006-10-03 4:14 ` Junio C Hamano
2006-10-03 8:18 ` Jakub Narebski
2006-10-03 9:34 ` Junio C Hamano
2006-10-03 10:15 ` Jakub Narebski
2006-10-05 0:15 ` Luben Tuikov
2006-10-03 20:20 ` Luben Tuikov
2006-10-03 16:31 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='efc9af$7ic$1@sea.gmane.org' \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).