My first group coding-project : creating interactive CLI menu and input options without TTY-Prompt
When making interactive CLI application, TTY prompt is always the first choice for developers. TTY indeed makes adding different menu and input options much easier. But as a newbie in coding world, I decided to use the “old-fashioned” index-numbered-menu to challenge myself.
It all begun with my first group project DM Log 1.01.00 in Flatiron school. Our app is a short DM guideline, which focuses on beginner experience. As it’s known for D&D fans, Dungeons Master makes a story, in which there are worlds, locations and monsters. To make the process clear and simple for a beginner like me, we made relationships chart as followed.
I was responsible for the transition between story and monsters. After DM chooses a story, DM is also able to see, add and delete worlds and locations of this story. Here is the brief demonstration of my story menu.
As shown in the demonstration, I made two menus, one for worlds and one for locations. The following, I’ll explain the logic and code behind locations menu.
The looping is the basis of this type of menu making. I chose while loop. In while loop, the condition which is to be tested, given at the beginning of the loop and all statements are executed until the given boolean condition satisfies. So the statements in our location menu will be executed till the condition is satisfied. The world instance is assigned by the user in world menu, the “name” and “locations” method from ActiveRecord shows the name and locations of the chosen world, and since there are many “locations” in the world, according to our classes’ relationships, we need to iterate through all locations and shows only names of locations. For better user experience I put HEREDOC instead of “ puts ‘ ’ ”. A HEREDOC is a way to define a multiline string, while maintaining the original indentation and formatting. This is all because of the DRY (aka Don’t repeat yourself) principle of software development, to reduce repetition of software patterns. Heredoc is good for multiline, so I still use “ puts ‘ ’ ” for one line string.
After getting input, I considered using “ if/eslif ” statement at first, but case statement is more flexible and better fit for complex multi-options. Whenever you need to use some “ if/elsif ”statements you could consider using a Ruby case statement instead.
Also for the consideration of better user experience, we also need to prepare for the typo situation by prompting a “invalid input”, which I put in the ‘else’ section.
The ‘1’ is for accessing locations in the assigned world, and for further input to get into the location-monsters menu. To show the list of locations in the chosen world, I used the “map” iteration as mentioned above again. Why ‘if/elsif’ here instead of ‘case’? When there are fewer input option and there is another ‘case’ statement around it, I prefer to use ‘if/elsif’ to avoid confusion and repetition.
The ‘2’ is for adding random location into the assigned world. After getting input, I used ActiveRecord “find_or_create_by” method to avoid creating duplicate instance. The reassigning of world instance at the end is necessary. It would save the update immediately, and show it in the locations list.
The ‘3’ is for deleting a location. Before the delete-input, I list the locations for user’s conveniences. When the input is not included in the list, “invalid entry’ will be prompted, otherwise it will be deleted from the list. The reassigning of the world instance at last is important as mentioned above.
Because of the limited timing, I was not able to prompt a reconfirmation and return option for this section. For my fellow developers, I recommend adding and refactoring of this part, which would make the interaction of this app more complete.
The ‘4’ is returning to previous page. You may wonder why I assigned world instance “nil” again. Because in former page, the user needs to choose a world, which means the world instance is needed to be assigned again. If we don’t “nil” the value, the user would not be able to proceed as we intended to.
Alright, now the last part of the code, prompting the invalid entry to remind the user to enter the right data. There is nothing much to clarify. It’s shown as it is.
The improvement of user experience played a significant role while I wrote my code. Like using sleep method and “colorize” gem did the “magic”. Sleep (*args) suspends the current thread for duration seconds (which may be any number, including a Float with fractional seconds). Called without an argument, sleep() will sleep forever. “Colorize” gem extends String class or add a ColorizedString with methods to set text color, background color and text effects. Command line applications have no graphics or visual interface beyond what you see in your terminal after you run the program, which makes it sometimes dull to look at. Wouldn’t it be more interesting to give it colors?
Making an interactive CLI app right after three weeks of bootcamp was like pie in the sky before I started Flatiron school. Thanks to the excellent curriculum, informative teaching staff and my partners in crime(actually in project) Imade Jeremiah Osifo and Griffin Poole, I was able to accomplish it. It may seem not as professional and DRY enough according to “developer’s standard”, but I’m proud and glad that I now have this skillset to make a CLI app. This is just a beginning, I believe that after finishing this bootcamp I would be capable to make more.
Sources:
