Inspiration
Some time before the hackathon, we stumbled upon the idea of readability. One of our teammates was reading a book about user experience design and came across the Flesch-Kincaid formula, a heuristic for determining the readability of a passage. They were intrigued by the possibility of utilizing the formula to build a tool for copywriters and content strategists. We’ve also found that it’s generally interesting to see how difficult it is to read a passage.
What it does
It evaluates the readability of English text as calculated by the Flesch–Kincaid Readability Test, and identifies words and sentences that are the most difficult to read by this scale.
How we built it
We started by bootstrapping our project with npx create-react-app. We then divided the app up into 3 components with the intention of splitting up the work. However, we struggled with coordinating our work and realized that pair programming and working on the same tasks together would work better for us. Building the part of the project that read in user input was a long and arduous process that involved the declaration of many object state variables. We chose to use React.js because we wanted to take advantage of its reactive state features so that whenever the input changed, the analysis would change accordingly. One interesting aspect of the project was figuring out how to programmatically count syllables. At a basic level, such a task merely involves counting vowels and vowel clusters. However, due to the complexity of the English language, there are countless edge cases. We started trying to write a function ourselves to do this task, but realized it would be much faster if we built off of a function we found on stackoverflow that used regular expressions. We also want to acknowledge that it is nearly impossible to correctly count syllables 100% of the time so we refer to that metric as a “syllable count estimate” in our UI.
Challenges we ran into
Some challenges we ran into were many edge cases that threw a wrench into our procedures for tokenizing sentences and words of the input. For example, we had to add additional regular expressions to also split word tokenization on hyphens and slashes in addition to white space to account for compound words. It also became a challenge to manage the code in the Calc.js file as the file grew to a large size of 133 lines long with five state variables. If we could have done something differently, we would have modularized the code in that file and broken it up into more components and used props to pass state between components.
Accomplishments that we're proud of
We are proud of how the color of the UI changes based on the context (difficulty of the passage). It was challenging, but fun to implement as we figured out how to individually manipulate the red, green, and blue values of a color by accessing css custom properties using the JavaScript DOM api. We are also glad that we were able to produce a minimum viable product in time for a hackathon submission.
What we learned
We learned that collaborating on a programming project can be more difficult than initially expected and that sometimes pair programming is the best option. We ended up using a lot of regular expressions so we picked up some knowledge in that domain. We also solidified our knowledge of the useEffect react hook and how it can be triggered by changes in specific state variables.
What's next for Readability Tool
A possibility is to incorporate a word commonality scale and factor that in each of the words found in the sentences. This will likely require some form of NLP methods, as we expect this to require several intermediate steps, e.g., stripping stop words, converting words to their lemma forms, training commonality evaluation models, etc.
Log in or sign up for Devpost to join the conversation.