Polishing the Get API

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.

screenshot_20161118_172719

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s