After meeting with Engineering.com, we learned that they like what they see so far in terms of our Get API's Visual Analysis Tool, but both they and my team lead agree that it would be better long term if they get a tool that's easily extensible. They should be able to build queries themselves instead of relying on us.

Therefore, we're looking into making the tool more flexible than just displaying queries that are runnable. We're looking into either making the "fields" more flexible (allowing them to add AND/OR boolean logic to the fields) and creating a sort of query builder, which would allow them to assemble Mongo queries using GUI elements which then join the pre-built queries on the screen for everyone accessing the tool to run. My team mate is creating a prototype of this Query Builder.

Meanwhile, I'm extending and polishing the existing prebuilt queries to use multiple display types each. For example, for the "Hit Story", instead of just displaying a time line of the actions performed on that hit (clicking on something, reaching a scroll point, etc), it also now displays information about the hit itself. Our new schema design for our queries allows them to have multiple display components in the GUI. This allows the queries to be more useful.

polishing_the_get_api_1

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.