Slowly and steadily, the UI is coming together. I moved the queries my team mate developed into the app, so we have about 20 queries developed as per Engineering.com's wishlist.

search_fixed_queries_implemented_graphs_next_1

With my team mate's help, we improved my searching mechanism to use RegEx and it helped with accuracy issues. Turns out I did indeed just choose the wrong CSS to implement my hiding as part of the searching.

When a query is deemed "not a match" it gets a "hidden" React property set to "true" (if it is a match that property is set to "false". That got interpreted deep down in the React code as "make this element have the CSS property 'visibility' set to 'hidden'" if that property were true. Otherwise, the CSS visibility property would be set to "visible". However, this had the effect of leaving the physical space on the DOM for that element reserved. What I actually wanted was to be changing the "display" CSS property - "none" if hidden were true, else "block".

Once I made that change, combined with the switch to RegEx, the searching works perfectly. It will let the Engineering.com staff search for queries by their title and description. It would be trivial to add more parts of the query that the searching mechanism is able to look at, or to make the searching mechanism use checkboxes or radio buttons for more types of searches (AND vs OR) or to specify what parts of the queries to search. The screenshot below shows the results of performing the default AND type search with the term "hit rate". The graph displayed has nothing to do with the data from that query, and is just there to illustrate what might be displayed after the "Run Query" button is invoked.

search_fixed_queries_implemented_graphs_next_2

I began looking into integrating Dygraphs into the React app, to allow the query results to be shown graphically. Most humans don't speak JSON. This will be something usable by anybody, including those who aren't particularly technical.

search_fixed_queries_implemented_graphs_next_3

As usual, when considering what libraries to use in the project, we opt to use stable libraries with lots of community support. Dygraphs definitely qualifies. I can't wait to see how this will display the production data we'll soon begin gathering.

Note: This was originally posted on the blog I used for my co-op term while at Seneca College (mswelke.wordpress.com) before being imported here.