3 ms·

> https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci ... That is just a mess of unimportant info. That scr

by SQLite 9y ago

> https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci ... That is just a mess of unimportant info. That screen contains all and only the information I want to see. (No surprise, since I wrote that screen.) I would very much like to read more details from Xwattt about what he (or she) finds messy, unimportant, and inadequate about the timeline view of Fossil and to perhaps see examples of better presentations of development history. I wonder if Xwattt has tried clicking on two of the check-in circles in the graph from the link above, in order to get a diff between the two selected check-ins? Is that information not useful? What of the filtering options in the sub-menu? Is clicking on "Files" to see all the individual files changes in each check-in not helpful? Is clicking on a branch-name tag to see a timeline of just that one branch not something that other people ever want to do? Seriously - I'm not trolling here. I honestly what to grok what it is that Xwattt finds inadequate about the Fossil web interface, as understanding this will help to make the interface better.

Frondo 9y ago
Do you use Github or Bitbucket regularly? That would be the best way to understand what people are used to, and consequently what they will expect to see (or not see). If the reply is, "fossil is meant to be different," then of course you have your answer; it shows you what you care about, not what people who are accustomed to other systems care about.
petre 9y ago
I use both fossil and github. I find fossil's history graph more useful than github's commits view which is basically just a git log and only lists one branch at once. In fossil I can see all checkins on all branches simultaneously. If I want to see a signle branch I click on it. If I want to see a diff, I click on the checkin link.
xwattt 9y ago
> contains all and only the information I want to see http://noisydecentgraphics.typepad.com/design/images/2008/03/11/yourproduct.jpg http://noisydecentgraphics.typepad.com/design/images/2008/03... > examples of better presentations Here it is - http://github.com/ http://github.com/ > Is that information not useful? Sure, all information useful, but presentation and usability of fossil ui is near zero. It looks like a programmer without any aesthetic taste just throw all information in random places on screen just to fill it. While UX designers polishes every checkbox, padding and font size. For example - why unreadable commit ids occupy so much space on the screen? When I open timeline - I want to read commit descriptions first, and only after that I may be interested in some commit id. I'm opening github timeline and I'm focused on commit descriptions, but fossil timeline accents me on useless commit ids! > I'm not trolling here Me too. I bet 99% of Github success is a good UX - but it is very difficult for programmer to understand it.
ptrott2017 9y ago
As a long time user of Fossil who periodically tries to persuade others to use it, the challenges I have seen getting others to adopt fossil that echo XWattts comments include: Look and feel. I have tried different UI themes - github and stackoverflowesque (so-skin.txt) are the most successful in getting buys in - but out of the box fossil, tends not to get a great initial response and it is suprising how many people just stop there. Fossil timeline graph is different from Github commit view - which is the main tool many of devs I work have only used. I much much prefer Fossil graph view to Github commits I find it a lot more helpful, but others do not see it this way. This can usually be quickly solves with some on boarding training, but it is a small initial barrier friction point to adoption. Tickets and timeline - Actual user feedback said while trying to get a colleague to use Fossil -" In tickets and timeline - Whats this weird jumble of letters i have to click on - why can I not click on the ticket title?" While obliviously all tickets need a unique identifier - do i need to look at it all the time, or can I reveal it only when i need it? This is comes up frequently. One of the biggest barriers to adoption that has prevented me getting adoption in wider teams is - as silly as this sounds - not directly scm functionally related but user experience on connected items for tickets. I personally love the fact I can have issues and docs in same repo as code - it was one of the first things that attracted me to Fossil and has proven itself on my own projects repeatedly. However I loose people every time I bring up the issues page up because its not how many teams work today - they use tools with a Kanban interface that connects or is associated to their repo. I was very excited to Steve Landers initial work (http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Landers-KanbanTcl.pdf http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG. Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc. I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.

by SQLite 9y ago

Frondo 9y ago

Do you use Github or Bitbucket regularly? That would be the best way to understand what people are used to, and consequently what they will expect to see (or not see). If the reply is, "fossil is meant to be different," then of course you have your answer; it shows you what you care about, not what people who are accustomed to other systems care about.

petre 9y ago

I use both fossil and github. I find fossil's history graph more useful than github's commits view which is basically just a git log and only lists one branch at once. In fossil I can see all checkins on all branches simultaneously. If I want to see a signle branch I click on it. If I want to see a diff, I click on the checkin link.

xwattt 9y ago

> contains all and only the information I want to see http://noisydecentgraphics.typepad.com/design/images/2008/03/11/yourproduct.jpg http://noisydecentgraphics.typepad.com/design/images/2008/03... > examples of better presentations Here it is - http://github.com/ http://github.com/ > Is that information not useful? Sure, all information useful, but presentation and usability of fossil ui is near zero. It looks like a programmer without any aesthetic taste just throw all information in random places on screen just to fill it. While UX designers polishes every checkbox, padding and font size. For example - why unreadable commit ids occupy so much space on the screen? When I open timeline - I want to read commit descriptions first, and only after that I may be interested in some commit id. I'm opening github timeline and I'm focused on commit descriptions, but fossil timeline accents me on useless commit ids! > I'm not trolling here Me too. I bet 99% of Github success is a good UX - but it is very difficult for programmer to understand it.

ptrott2017 9y ago

As a long time user of Fossil who periodically tries to persuade others to use it, the challenges I have seen getting others to adopt fossil that echo XWattts comments include: Look and feel. I have tried different UI themes - github and stackoverflowesque (so-skin.txt) are the most successful in getting buys in - but out of the box fossil, tends not to get a great initial response and it is suprising how many people just stop there. Fossil timeline graph is different from Github commit view - which is the main tool many of devs I work have only used. I much much prefer Fossil graph view to Github commits I find it a lot more helpful, but others do not see it this way. This can usually be quickly solves with some on boarding training, but it is a small initial barrier friction point to adoption. Tickets and timeline - Actual user feedback said while trying to get a colleague to use Fossil -" In tickets and timeline - Whats this weird jumble of letters i have to click on - why can I not click on the ticket title?" While obliviously all tickets need a unique identifier - do i need to look at it all the time, or can I reveal it only when i need it? This is comes up frequently. One of the biggest barriers to adoption that has prevented me getting adoption in wider teams is - as silly as this sounds - not directly scm functionally related but user experience on connected items for tickets. I personally love the fact I can have issues and docs in same repo as code - it was one of the first things that attracted me to Fossil and has proven itself on my own projects repeatedly. However I loose people every time I bring up the issues page up because its not how many teams work today - they use tools with a Kanban interface that connects or is associated to their repo. I was very excited to Steve Landers initial work (http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Landers-KanbanTcl.pdf http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG. Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc. I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.