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. > 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 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? > > 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. > > * 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. :-( > > * 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> > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
