More On GrammerPolice « My Site/Blog
Untitled Document

More On GrammerPolice

I originally started writing this post in November before the CS Fair I was presenting at however, got caught up in school work. The plugin actually ended up winning an award as the best independent project, which caught me completely by surprise (I’ll probably talk about the fair in another post). I just thought I’d go into a little more depth about the problems I faced when designing the plugin and ways in which I tried to overcome them (original post can be found here).

One of the first problems I ran into was where to store all the information generated by the plugin (errors/ corrections). A coworker at the time recommended I check out a service called Firebase, which happened to be a free, easy-to-use, scalable backend. I set up a free account in a few minutes, went through a couple of tutorials, and ended up with a database to test the plugin.

The next issue I had was how to reliably access and store data from static web pages. Say for example you have the following sentence:

The quick brown fox jumped over the lazy dog

For the sake of simplicity let’s just imagine that such a sentence is contained within <p> tags on a webpage. Say the user of the app needs to highlight the word “the”. Right away you can see that you have no idea which “the” I am actually referring to. Solving this problem and more complicated iterations of it (dynamic pages) was probably the biggest challenge I faced in designing the script.

My solution was to include an index to the word from the beginning of the sentence, which I defined either as the first sentence contained within a tag or by the “.” character. Assuming we wanted to choose the second “the”, we would store an index value of six (starting from 0). Thus upon returning to the sentence we could tell our script to highlight the sixth word.

The next, more complicated, example would be if you had two paragraphs with similar content. Worst case scenario would look something like this:

<p>The quick brown fox jumped over the lazy dog</p>

<p>The quick brown fox jumped over the lazy dog</p>

As you can see, another reference is then needed in order to be able to address the correct word. I decided to add an html5 custom data attribute to each <p> tag hashed out from the website URL. This injection was accomplished using jQuery and simple onload function that appended the custom attribute onto specified containers (h1, h2, p, ect.) For the example above that would have looked a little something like this:

<p data-gp=”domain1″>The quick brown fox jumped over the lazy dog</p>

<p data-gp=”domain2″>The quick brown fox jumped over the lazy dog</p>

The domain would be the URL of the webpage while the last number indicates the index of the <p> tag relative to the beginning of the page. Thus making it possible to address and access any word on a given page, while still (hopefully) being able to accommodate small changes in content. I chose to use periods to break up paragraphs as I thought it more likely to have a sentence edited for correctness rather than be outright deleted. That way even if a portion of a sentence was deleted the plugin would still, hopefully, be able to navigate to the correct location. From there, the only difference between accessing data and storing it was the inclusion of one extra method, which would return the ID of the parent element.

The last problem was storing enough information that the plugin would be able to reliably return to a page and locate the correct text. This was accomplished by creating a new data reference every time the user clicked the plugin’s submit button. The reference would include the URL of the current page, an error object (the error, and necessary references), and the user submitted correction. Therefore, when a user visits a webpage the plugin will first check to see if that URL is contained within the database. If it is, the plugin will then inject the html references highlight the errors with the stored information.

Overall, the design of the plugin is much more suited to handling static content, with aspects of the dynamic handling being slightly abstracted. For instance, issues arise if new containers are introduced, or if content is edited to a point that the references can no longer reliably point to the text they should. These are just a few of the bugs I would like to work on in the future.

I really enjoyed working on this project. It happened to be one of my first, involved, experience with JavaScript and any sort of databasing and was a great learning experience. I have far more work planned for the plugin than what I’ve completed as this is definitely one of the projects I’d like to see through to deployment. Please do not hesitate to contact me with any questions or comments you may have.



Mockups of the plugin in action (the floating text parts)

Untitled Document

no comments

leave a response

Untitled Document