(This is a repost from the main QVSource blog here.)
We achieved a major milestone this month which marked the end of our first year of providing QVSource commercially.
We are considering the first year a great success and are delighted that already all of our earliest customers (excluding one desktop only user) have renewed for the second year - thank you!
We have also maintained the highest rated position on QlikMarket and currently have 18 5-star reviews - if you are a user and like the product please take a minute to rate us.
But it's no time to get complacent - we have been connecting QlikView to APIs since the end of 2010 when QVSource development began, and with all the experience we have gained and lessons we have learned we know we can still do many things better. Year one was about getting the basics right, next we will be focusing on usability and performance.
So this is half of a two part post on some of the improvements we are working on. In this post I'll look at our front end (user interface) and how it's changing and in the next post I'll look at our 'back end' QlikView scripting and how we are planning to simultaneously reduce complexity and improve performance.
Our current connector config UI is perfectly functional and gets the job done but there are a few challenges it still presents:
- It shows all the input fields all at once, even though some may not be relevant to all the tables you are interested in.
- It lacks supportive information about the fields and tables.
- Each connector's UI is manually built which leads to some inconsistencies between connectors.
- It presents all the tables all of the time, even though 80% of users will typically only use a common subset of tables.
A case in point is the Twitter Connector - here's a screen shot of the current version:
Current users will no doubt recognise this and some of the issues outlined above which it presents. I am not picking on this connector, I think all but the simplest of connectors have a similar issue.
So we are now re-developing the connector config user interfaces to have a layout which looks more like this (note this is still in development so the soon to be released version might differ slightly):
A few things to point out.
At the top left a new drop down now allows the user to see different groups of tables. This is because for many connectors, 80% of users will typically only use a common subset of tables so now the first time they use the connector they are presented only the most common or popular ones to avoid information overload. The drop down allows you to select different grouping and of course 'All Tables' will be an option for power users:
Below the table list we now have a new area where additional information about the selected table which could be relevant to the user is shown - here we see an example for the Twitter search table:
This will often essentially be us mapping relevant documentation from the underlying API to the QVSource user. Hyperlinks can also be included here to link to our docs or other relevant web pages.
The final big change is the input parameter section - this should now only show input parameters for the currently selected table:
Which should make the connector far more intuitive to use. This interface is also now 'auto generated' which means that there will be a much greater level of visual consistency between the connectors and also makes our SDK easier to use as you simply need to define which parameters each table needs and let the framework take care of the rest.
You should also notice that we now have tool tips on some of the fields - where necessary this allows additional helpful information about the fields to be show.
Finally, when the table's data is requested we now have much improved parameter validation before the request even gets to the connector. Here we see what happens when the Search table is requested without entering a query.
We hope you like the new changes, as they are still being worked on please let us know any further suggestions or concerns you might have and we will try to address them in the coming weeks.
In the next blog post I'll be discussing some of the changes we are making to simplify and improve the performance of the QlikView scripting for QVSource.
