To All, with apologies to the post author for the hijack.
I hope that everyone is taking FCB as the development of a tool which is 'Work in Progress' as it would potentially deny the future of FCB if we were to think of anything about it as cast in stone.
So far, through use, thought and discussion the utility had gone through a number of significant jumps in functionality but I am certain there is still so much further for it to go. Organic, or evolutionary growth like this is often inefficient and frequently restricted by that which has been laid down before, but most folk need something to work with in order to stimulate their imaginations to better things. And so it has been with FCB.
It started, even before the Windows utility, as a simple pencil and paper system to create a cypher string which could be reliably and easily communicated so that the recipient could faithfully recreate the diagram made by the 'sender'.
The first Windows program attempt was literally a simple 'Paintbox'. It allowed the user to select a small gif tile and then paint it anywhere in a grid of squares. The grid squares were 'lettered' and the gif tiles each had a unique letter, so it was a simple process to build the cypher with each placing of a new gif tile. The utility could also work the other way around, in that if you pasted in a cypher string into the cypher box, the utility could paint the right gif tiles into the right squares to recreate the drawing. It was a cypher creator and decoder first and a drawing utility second.
At that time Frank Brown was using an expensive CAD program to create his knot diagrams. Very powerful, quite a steep learning curve and priced well out of most peoples range. However, a couple of additions, like different coloured cords and the ability to move the diagrams around and Frank found that the little utility was in fact far easier and quicker to use than the professional CAD software. The cypher tool was starting to become a drawing tool and with the addition of Save and Load facilities, the cypher side was almost irrelevant, because it really did not matter how the utility remembered the diagram, all you had to do was 'Load the File'.
The addition of cord colours created a problem with using gif tiles because it meant that for just two colours we would need four gif tiles representing the possible variations of over red, under blue etc and for three cord we were going to have to increase the pallet from just two crossing tiles to eight. That led to the first big change in the utility, instead of painting a gif into a square, the utility actually drew the cord in the square. The tile pallet on the left became just an indicator of what would be drawn in the square.
A number of drawing enhancements followed such as the ability to move the drawing around the grid, flip hand, auto load etc. and the utility was progressing to becoming a more usable drawing tool. It was however, no more than that - it just drew lines and curves in squares. Apart from a little logic to make sure a crossing used the right under cord colour, it was nothing more than a tool for drawing lines in squares - it knew nothing of the meanings of the tiles or of the knot which was diagrammed. The fields to enter the knot name, additional information and the Overs Index, were just text fields and held whatever the user typed in them.
When the Overs Index was first created, the biggest criticism of it was that it was simply too complicated for the 'man in the street' to be able to work it out and sure enough, no one was filling in the OI for knots diagrams they were creating. To give the utility the power to calculate the OI itself, it needed two things - first was a 'map' for every tile which declared which face was connected to which and the second was to know where to 'Start'. This was easy because the WEnd tiles were the only ones to have only one connected face.
So I put together a function which waited until a WEnd tile had been painted, then it started to trace out the cord, moving out the 'out' face into the neighbouring 'in' face, through the neighbour and out its 'out' face using the tile map to guide the progress. The colour of the tile was completely ignored in favour of following legitimate face connections. This continued until the function met a cell with no content when it stopped. I then had the complete path of the cord and could use it to identify all the crossings in sequence (later to be called the Binary Index). I could then apply the rules to count the overs index and post the result automatically into the Overs Index field.
Version 4.2 was a big step forward because it built in the facility to take the Binary Signature and use it to look up that signature in the Knot Library Wiki. However, these tools seem to be a bit ahead of their time, because today all the comments seem to be focused on the utility purely as a drawing tool with requests for drag, drop, copy, paste, undo, zoom, etc. and the shape and use of the various tile images. This is clearly where the next development work should be concentrated.
There is a growing consensus that the WEnd would be more understandably depicted as an end which has only one face connection and should probably be depicted as a stump end inside the cell.
The use of arrows is much less clearly resolved.
It was used in early versions to indicate the rope continuing to the SPart, it might also be taken to indicate the direction of the load. Later, it was also used to indicate the long arms of a large loop ( as distinct from a small bight equivalent to a TIB WEnd). The loop arrows were shown pointing into the knot to distinguish loop ends from the SPart, but perhaps they should be used pointing out of the knot to follow the implication that they indicate the load direction and then close the two lines to show this to be a connected loop rather than two unconnected lines. As far as analysing the knot is concerned, the arrows are no different to simple straight lines, they just connect one face with another and can be used anywhere to indicate flow, force, continuation etc. whatever the user wants.
Apart from indicating loop legs, do we need an arrow at all? The SPart can simply be indicated as a full line and if the knot does not have an SPart, then it can be indicated using a WEnd on both ends?? I feel that we need some symbol to indicate 'and the rest of the rope' be it an arrow, a cut line or a line with ellipsis, but then this could be used anywhere to indicate that this section is extended.
Working on the premise that we should concentrate on making the utility a more competent drawing tool first and an analysis tool second, then perhaps it is time to consider a rethink to the way the cord line is drawn and to consider the idea of dropping the 'tile painting' approach in favour of simply 'connecting the dots'. For example, it is possible to consider a method where the user picks a colour then simply clicks on the wall faces that the line is required to pass through, then the utility draws the line shape necessary to connect the two clicked points (in the same cell). This then immediately begs the question of why restrict drawing to just the four square faces, why not allow the corners to be clicked as well, giving us access to diagonal lines and wall to corner bends as well as corner to corner curves?
This would take us from the possible six connection options we have with face to face connection right up to 20 possible connections.
The FCB42 connections are in red and the FCB5 additional connections are in black.
We would have to develop a totally new way of showing a crossing and would probably have to have the facility of moving the cord up and down in layers in order to facilitate the crossing function - a lot of work - is it worth while?
Derek
