On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp <[email protected]> wrote:
On Wed, Oct 30, 2013 at 5:13 AM, j. van den hoff
<[email protected]>wrote:
recently, I've started to use `ui' more heavily (due to the requirements
of a new collaboration which makes use of the wiki and ticket system).
while the ui sure is usable and provides all important functionality, I
think a few things could be improved, especially when having novice
visitors to a fossil driven site in mind. I list them here in no special
order:
== timeline ==
* it is non-obvious how to get to the display of file content related
to a
specific check-in:
On the "Check-in" page, the first link to the right of "Other Links:" is
"files" which takes you to a display of all files for that one specific
check-in.
yes, I know. but consider the checkin concerns a single file (it
frequently does) and that file
is in dir/sub1/sub2/sub3/file.name
it still'd be a pain to get to it (even if you perfectly remember in what
subdir it is). I feel it
should be essentially a straightforward 'one-click action' to reach the
file content.
currently one has to do [timeline-sha1] --> [changes-to-sha1]. this is
not
what the new user would expect. rather he will look for the filename.
but
the filename link in the "check-in" page jumps to the history of the
file.
proposal:
1. link the filenames shown in the timeline when activating "show
files" to the file content.
There are two files: The "before" and the "after". Which do you want to
link to? Presumably the "after" file. But what then to do about deleted
yes, definitely "after". I would say there is no ambiguity here: if you do
display a file name in the timeline
and link to it's content it should be the content _after_ checkin and that
sure is what the user would expect
to see, when going to that link
files, such as seen at
http://www.fossil-scm.org/fossil/timeline?n=8&c=1f498a6&v - leave them
unlinked or link them to the "before" vesion?
definitely "unlink": I'm concerned with a probably rather common desire:
look at file content _after_
some modification+check-in. so displaying the "before" content for deleted
files would be inconsistent
(and displaying the content of a file _after_ deletion (empty) is not very
illuminating ;-)). luckily,
you already show the status as "(deleted)" in the timeline. so leaving
these "unlinked" would not cause
confusion.
2. "unlink" the file name in the "modified file.name from xxx to yyy"
line of the `check-in' page and add instead a "history" link on the same
page (in the "Timelines:" line, probably)
So, instead of saying:
Modified dir/filename.txt(1) from 0123456789(2) to abcdef0123(3).
(Where hyperlinks are shown with (#)) you think it would be better to
say:
Modified dir/filename from 0123456789(2) to abcdef0123(3).
[history](1)
I'm not so sure that is an improvement. You're going to need to really
sell this one.
I can try.
1.
when I was rather new to `fossil' (and also not using the ui much) I
demonstrated
it to a "svn customer" in my group. first thing he asked: "I want the
logfile of changes for a selected file. how do I get it?"
empirical fact: I hardly didn't find it (that's the "non-obvious
location/name" problem I see here). I bet most other new
user will have the same problem.
2.
"unlinking" the file name in the check-in page was just a proposal.
actually, my problem is, that I find it just strange that _only_ the file
name link here takes the user to the history of that file. having a link
spelling out what's "under" the link is usually better I believe.
so I would think even just changing the respective line to
dir/filename.txt (history(1)): modified from 0123456789(2) to
abcdef0123(3)
or, possibly,
dir/filename.txt(3) (history(1)): modified from 0123456789(2)
or
dir/filename.txt(3): modified from 0123456789(2) (history(1))
would be an improvement compared to the current version in my view.
3.
if the change to the timeline regarding linking file names to file content
after checkin would be realized I also would add a "history" tab to the
'artifact content' page. this would be another rather "obvious" location
where to look for the history in my view.
* the order of entries in the timeline menu is sub-optimal in my view.
currently it is
200 entries | checkins only | events only | show files | older | tags
only | tickets only | wiki only
which mixes "subsetting" actions and "timeline length or appearance"
actions.
I propose to change (and rephrase) this to
show file names | previous (and "next" in the other direction instead
of "older/newer") | more | less | checkins | events | tags | tickets |
wiki
this sorting order seems more natural to me (notably the user will
directly see the file names tab). also, it would be nice to enable the
user
to increase/decrease the length of the time line display beyond choosing
between 20 and 200 (and without knowing that this number can be edited
in
the URL). so I propose to increase/decrease the length of the timeline
by a
certain factor (of 10, e.g.) with each click on more/less (keeping the
minimum length at 20). alternatively, one could keep the current 200/20
switch and add an "all" switch.
== wiki ==
* the list of all wiki pages does not really stand out and is not
reachable by a single click. if the new user starts at the home page and
then goes to the `wiki' tab he sees a least on top of which is the link
to
the home page from where he just came (by default, anyway) and the link
to
the "table of content" (list of all wiki pages) is somewhere at the
bottom.
proposal: I would find it more convenient if the `wiki' tab would take
the
user directly to the table of content (list of all wiki pages) and that
tabs were added beside the current `all' tab on that page for the other
actions (recent changes, new wiki, etc.) or, at least, a single tab
taking
the user to a page listing these (essentially the page currently
reached by
the `wiki' tab).
== files ==
* it would be nice if directories where differentiated from files (e.g.
in
unix `ls -F' fashion) by trailing `/').
IIRC, we used to do it that way. But people complained about it so we
took
it out. :-(
yes, ask 10 people and get 20 opinions, I know. but maybe a new "poll" can
be done (or, if no consensus can be reached, add a further configuration
switch (these switches being a set of cardinality aleph_0 after all ...)).
I believe identification of directories is just necessary (`ls' does it
(if one wants to), all file browser do it). also, as said, a linear list
would be better in my view.
any opinions regarding restructuring/resorting the tabs in the main menu
etc.?
* it would be nice if a one-column display where available (or
configurable via a switch): it is easier to locate a file of a given
name
in a one-dimensional list.
just my 2c, hope this makes sense (and I know that tastes do differ).
but
maybe some of the above proposals are found acceptable.
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
______________________________**_________________
fossil-users mailing list
[email protected].**org <[email protected]>
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
