In which I redesign a text-based command line tool in order to represent it graphically.
In response to a brief for a Computer Science class on filtering algorithms, I built an algorithm capable of accurately solving a certain highly popular (and trademarked - though not entirely original) word game. The algorithm was implemented in Python3 over a few days, and works almost flawlessly. The answers it produces almost always complete the puzzle within the requisite 6 tries; the one time this failed to be the case was down to human error.
And indeed it is that human error issue which led to the selection of this project for re-design. Whilst the algorithm performed perfectly, the user needed to enter commands in an essoteric text-based format in order to actually access the algorithm.
The text-based system caused two chief problems: the user had to learn and remember all of the operators and syntax required to add a rule into the list; and the inconsistent syntax of the system made it unclear what parameters a particular operator could take (ie. some operators could take both a position argument and a value argument).
The algorithm, whilst efficient, was also built a few years ago and was not reflective of my ability to write high-quality code. A complete refactoring would be required in order to try and separate the core algorithm from the shibboleths of operating-system specific knotting and bodges.
This, though, would provide the perfect opportunity to translate the algorithm into JavaScript for re-implementation. I planned to use core web technologies in order to implement the algorithm online such that it might make it more accessible, especially in a cross-platform context.
The process of re-implementation started by looking at the original high-level abstracted algorithm design, marginally edited here to remove aforementioned anachronisms:
Import word list from file
Objectify word list; make it indexable
Import rules; objectify and make them indexable
For each rule:
Check rule type
For each word in the list:
If the word DOES NOT match the rule, delete it from the list
Output the word listThis is the basic structure for the main loop of the programme, not including the filtering systems. In order to translate this into JavaScript, I chose to use JavaScript-specific object formats in order to store data. This would eliminate the non-exact representation system for rules which had been used in the original Python algorithm, and allow the algorithm to hold an internal representation of the data which could be set via an API.
This is a significantly better system than the python implementation, which required the users to attempt to understand the internal organisation of the algorithm in order to use it. This semantically separates the data from the way in which it is processed, which is significantly better programming practice.
When defining the object structure itself, an array containing many sub-objects made the most sense, as throughout the process, rule creation is dynamic, with limits defined purely by the machine’s memory capacity. Each sub-object could be given a heritable structure from a template super-object, meaning the API could insert a new object by simply cloning the super-object into a free memory slot, then populating it with the arguements passed to the command.
The super-object holds three parameters, some of which are not needed
for certain rules, but which could in these cases default to holding a
null value. These paramerters are: Type (string) - the type
of rule being held in this slot and determining which type of filtering
should be used, value (character) - generally defining the
particular letter to filter for, and finally,
position [optional](integer) - defining where in the word a
particular value occured. These three parameters, when used together can
adaquately describe any concievable Word Game™ play state.
Once these elements were assembled, the algorithm could accurately represent the current state of play, as well as process using the filters, initial tests in the JavaScript showed the output to be identical to the Python implementation on a given ruleset, meaning the code translation had likely been successful pending further examination. In order to make testing easier, I put together a small user interface which, though far from final, could allow a user to input rules graphically:
The interface provoked some thoughts about general structure and navigation which went on to shape the next iteration:
The second UI iteration was designed initially on paper:
The idea was to use a split-screen system, with the left panel displaying a list of the rule set, and the right panel displaying the potential words which could be used to solve the game. Instead of using algorithm-specific terminology to describe the rule name, more user-freindly options are now used, describing what each option means:
This version now has a particular flow to it. The user adds a rule by starting at the top, the rule then moves over to the left panel, and updates the right panel with the final output. It follows the input-process-output mantra from computing.
After an analysis of this design, I came away with a few extra pointers:
Improving upon the aforementioned points, and increasing the overall usability of the system, this prototype came to be the final design:
The design is now significantly more focused. Analysis of the first version found that showing the internal working of the rules and the algorithms was unnecessary, and priority should be given to what it is that users want: an answer. To this end, only a single word is displayed.
In terms of functionality selection, the togglebox system exposes the functionality previously hidden behind a drop-down menu. This also allows all instructions to be on screen at all times, meaning that it is clear both what the programme is doing and is not doing.
Parameter entry is now significantly simplified too: the “letters” box automatically focuses as soon as a rule has been selected, allowing easy keyboard navigation. For entering the position of a letter, a checkbox system graphically represents the letter position as it would be represented in Word Game™. This makes entry significantly less confusing.
The addition of a certainty bar is not something which the algorithm currently accomodates, but which could help users get an idea of how close they are to an answer, perhaps more crucial in latter game stages than earlier, but still likely of use. The percentage is calculated using a bit of mathematical trickery to scale percentages at different non-linear gradients, relative to the degree of certainty. For instance, if out of the 70,000 words the programme knows about, it has eliminated all but 30, the mathematical certainty would display 99.9%. However, 30 words when only 6 may be played in total is still a long was off in real terms, so the scaling adapts that to closer to 90% certainty. That is to say, the displayed percentage is not mathematically accurate at all, but the incrementation feels significantly more accurate perceptively when using the system.
You can try the final version at this link
I am pleased with the outcome of the final version of this project, and I feel that it has demonstrated my improved programming and interface design skills since the algorithm’s inception. There are some functions which I feel are still missing, such as the ability to edit the rules which the algorithm is using to filter words, or the number of letters in the word, but these would be outside of the scope of this project which set out to improve the usability of the filtering algorithm.