BesoGo is a new web-based SGF editor that has just been released (v0.0.0-alpha preview).
Play with the editor here
http://yewang.github.io/besogo/
GitHub Project Page
Comments, suggestions, feature requests, and bug reports are welcome. Please contact me first if you are interested in contributing via pull requests.
Shift clicking on a move does not do what other editors are using (jump to that move)
Also the move tree does not remember where the focus came from when moving from a branch to the father branch and then trying to go forward with keyboard. It follows the father branch. This is actually also a problem in OGS 
Edit:
Also adding stones to a single node/leaf (whatever) does not work. Adding stones will make a new node even if I am just trying to put many black/white stones on the board. Again same problem in OGS…
Edit:2
I think the cross indicating last move is too pronounced. Makes it annoying to look at a situation when one stone is “jumping out” of the whole thing.
Thanks for the feedback, Pempu. I really appreciate these design suggestions. Everything is still a work in progress, as I’m still looking too improve the interface design and add features.
Jump to move and remembering navigation history are on the to-do list.
There are buttons for adding stones, indicated by the circles with red pluses on them. The white and black circles are for forcing the play of a particular color, even if illegal.
I think I might add an option to remove or change the last move marker. Do you have any suggestions for an alternative design?
I like a shaded circle marked for last move like OGS and KGS uses.
I can’t come up with an scenario where one would want to add one colour stones and not want them to be on the same node/leaf. Ok maybe when recording a one colour go game one would want that. It’s such a niche that I don’t think it’s beneficial to have 4 icons in the interface for that. I’d prefer just 2 icons. So that adding black or white stones would not make new node but add the stones to the same node ala KGS.
When toggling between coordinate modes (lovely btw) the last mode seems weird to me. Half japanese half numeric.
Edit: The Cut is named weird since it will delete /remove instead of cut (as in cut/paste)
I think I’ll change the last move marker to something like a grey circle to be more subtle in the next release, but eventually, I’ll make this an option that can be toggled by either the end user or webmaster (the editor is actually an embeddable widget, like eidogo).
I agree with you that it may be a bit wasteful in the interface to provide 4 buttons, when the play black and play white should be rarely used. However, there is a distinction between the play black/white tools vs the set black/white/empty tools, coming from the SGF standard. The play stone tools will register captures, while the set stone tools do not. Of course, the set stone tools are more useful for many practical situations (setting up an initial position for a problem, placing handicap stones, etc.). Normally, it’s illegal for a player to play several times in a row (without intervening passes from the other), but this recording functionality is supported by the SGF standard, and might be useful in some rare cases (maybe when an SGF composer just wants to create a sequence of diagrams and play with arbitrary control).
For properly recording one color go in an SGF file, I think just recording the game normally would be the only viable approach (in order to make sure captures are properly registered), while relying on the SGF program to toggle just the display between normal and one color mode.
The last two coordinate systems are actually based on a proposal that I had for a corner-relative system, where the coordinates reflect the distance from the nearest corner, while also unambiguously distinguishing which corner.
http://lifein19x19.com/forum/viewtopic.php?f=10&t=11586
For now, it just removes, but I was planning to also add the functionality to “paste” in order to transplant branches (which could be useful for fixing a transcription error that is only realized much later, without having to throw away and redo all of the subsequent moves entered).
Just a note re one-color Go:
This is a very special case, but you would still want to store the underlying “real” color. It is only the presentation that changes.
I’m not sure how I would note this a file except as a Game Comment. Handling will be entirely how the tool wants to handle it.
The “Comment” button could be removed by always showing the comment box with some text inside it “comments here” that would disappear as soon as keyboard focus is on the box. Similar to how it works in OGS.
@Pempu, I’ve been thinking about this feature and what the specific behavior of “jump to move” should be. Could you offer your thoughts on this topic?
When it comes to jumping to a move that is present in multiple variations within the tree, what is the appropriate rule to determine which move to jump to? Basically, should the tree search be done depth first, breadth first, or something else? Depth first would prioritize the “main line”, but maybe a hybrid scheme could make sense as well. Also, what about the distinction between moves before vs after the current position? Should, one be prioritized over the other?
How about only looking back in the tree, toward the beginning of the game?
From a UI view, this would require clicking on a stone. Then there is no question which node caused that stone to appear.
That’s an interesting argument in support of prioritizing backward search first. However, I think it still would be nice to have the ability to jump forward and into variations as well.
Note that even with searching backward, you can have moves that are no longer on the board due to capture.
True, but if we can look back based on location. Maybe even go to the previous play at that location by clicking there again. This would allow looking back through a ko or fill.
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.
I’ve been experimenting with some CSS-based themes:
http://yewang.github.io/besogo/testing.html?theme=dark
http://yewang.github.io/besogo/testing.html?theme=alt
http://yewang.github.io/besogo/testing.html?theme=book
Just some basic flat-color themes for now, but textured and “realistic” graphics are in the plan for further work.
Experimental photo-realistic board rendering:
http://yewang.github.io/besogo/testing.html?theme=wood&realstones=on
Niiiiiice!
W: rsun (4d), B: integer (2d)
(I moved the following part of the discussion from Smallest Groups With Two Eyes to this thread, seems better)
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.
@trohde, just for fun, I created an alternate theme that you might find “relaxing”
http://yewang.github.io/besogo/testing.html?theme=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: