Right, I don’t mean to suggest that it’s more difficult if there is no stone on the location already. My interface already captures the clicks by the point location, and I envision that shift-clicking repeatedly on a location should cycle through all of the moves at that location (in some order).
I’m not asking about the difficulty of implementing this, since it’s all rather straightforward once the exact desired behavior is understood. Instead, I’m asking about what should be the designed behavior of “jump to move” should there happen to be multiple moves in the tree at the selected location. Should there be no moves at the location, then perhaps the jump should just do nothing. If there is only one move at the selected location in the entire tree, then that move should be found and jumped to.
My point in my previous post is that I think that “jump to move” should somehow to search over moves both before, after, and on different variations of the current location in the tree, but determining the priority between multiple moves is an interface design decision.
I think it is also useful to look forward, since some users might want to jump forward to see when a particular point is eventually played.
Imagine that you’re looking at a game record where early on both players have decided to leave a vital point unfilled in order to play elsewhere. Hence a jump forward to the move on that vital point could be useful, if you were curious about seeing when and which player eventually filled that point.
Wow, that looks purdy kewl, @yebellz! Though … something … dunno, something there doesn’t seem right …could it be the drop shadows? Or is it there some difference in sharpness between board and stones? The exact positioning?
Another question, what do you think: how many different shell stone images would be enough to make it look convincing? Ideally, of course, 180 I just purchased a “used” (played once) S&S set <happy> and when I find the time I might go and scan them.
And then again … moving in the diametrically opposite direction: sometimes I think it may all be just too much skeuomorphism … perhaps for digital/visual/pictorial communication of Go diagrams simple graphics are easier for the eye, less distracting … the Eidogo thingie definitely has the best contrast/colour combination, I think … when I look at all three, Eidogo gives me the most relaxed feeling, the least stress.
@trohde,
Thanks for the kind words and thoughts! I agree that several things could probably still be tweaked a bit. I’m still going to keep playing with many of the details. Here’s what it looks like without shadows, which I felt seemed a bit flat, but perhaps I still haven’t gotten the shadows quite right.
Fuzzy positioning, and maybe even making the grid slightly rectangular like real boards (which is readily apparent if viewed from directly above) might improve things. Also, maybe color levels/saturation, sharpness differences, lack of perspective distortion… well, there are a lot of challenges to making a really convincing realistic go board. Maybe things are starting to get into the uncanny valley.
Maybe more stone textures would help too. Currently, there are 4 black stones and 11 white stones, all courtesy of another open (CC-BY-SA) project, go-assets. Also, the board image is from jgoboard (CC-BY-NC). It’s always helpful to have more people making more such images freely available.
Regarding whether it’s too much skeumorphish… yeah, I’m not too sure if I absolutely prefer realistic rendering. I worked on it since I thought it would be kind of a neat feature, but I also really like a simple, abstract depiction of the board, such as with just plain flat colors like this, or alternatively adding just a simple outline like this.
By the way, with BesoGo, the board/stone colors are specified in CSS, making it very easy for the webmaster to customize the theme (a power user could even play with changing the CSS defined colors using the browser console). One could also easily ripoff the EidoGo color scheme and stone graphics, while getting the added benefit of avoiding the limitations, bugs and security vulnerabilities in EidoGo.
The exact board color scheme is directly lifted from EidoGo. I didn’t use their stone graphics, which have a slight gradient, but only low-res images were available. However, the flat color stones that I use have colors based on those images.
If you are curious about some other themes, you can probably guess the names from this:
Added the shift+click to jump to particular move as suggested by @Pempu
Added tools for changing promoting/demoting the order of variations
I have not really worked on this in a long while, but I think I want to get back to it.
Here are some thoughts for my ToDo list:
Update the code to modern javascript practices. Specifically, packing things into a proper module (I need to learn how to do this)
Refactor colors to reside fully in the CSS, which will make full color customization much easier
Add a problem mode widget for presenting go problems
Work on something that could be cleanly integrated into these forums, in order to support embedded SGF files
Regarding the last ToDo item:
We used to have EidoGo as a plugin here (on these forums) for directly embedding diagrams, SGF files, problems, but that no longer works and was disabled. Would there be interest and support to use BesoGo as a replacement?
Obviously nothing lol you can name it how you like… Just to me any change at all from initial document creation would be grounds for a 0.0.1 release lol so in my head 0.0.0 would just be a bunch of empty file stubs and thus couldn’t be released
I just purchased a “used” (played once) S&S set 
