A fortunate chain of events – a dry read

At Askia we love to talk about Askia things… and about a year ago, the technical team got together in a room and agreed on what was our biggest need: the ability to elegantly call a web service from a survey and decipher the result and store it appropriately.

Web-service not included

I have mentioned in previous articles how an API allows you extend your para-data. With the IP-address that you collect (and that we encrypt – GDPR is watching you), you can obtain the general location of the person. With the location, you can get the weather at the time of the interview and the likelihood they voted to a given party in the last elections.

You could always call a web service by adding some JavaScript in your page but that was not very elegant… and also made it hard to hide any authentication method.

So we decided to create a new routing where the Web Service was called from the server and not from the browser – effectively hiding the call from the interviewee. We got inspiration from the Postman interface and quickly put together a new routing.

The interface allows you to run different scripts depending on the success of the call and to manipulate and store the different parts of the response… and we introduced a new keyword CurrentHttpResponse.

QueryWebService

At that point, we thought that this had been relatively easy and we contemplated a well deserved visit to the local pub for refreshments.

XML and the Argonauts

As we were putting together an example – calling openweathermap.org to get the weather anywhere in the world – we hit our first problem.

The response looked like like this:

<?xml version="1.0" encoding="utf-8"?>
<current>
   <city id="6690581" name="Belsize Park">
      <coord lon="-0.18" lat="51.55"></coord>
      <country>GB</country>
      <sun rise="2018-03-06T06:33:58" set="2018-03-06T17:50:36"></sun>
   </city>
   <temperature value="282.33" min="281.15" max="283.15" unit="kelvin"></temperature>
   <humidity value="66" unit="%"></humidity>
   <pressure value="988" unit="hPa"></pressure>
   <wind>
      <speed value="2.1" name="Light breeze"></speed>
      <gusts></gusts>
      <direction value="200" code="SSW" name="South-southwest"></direction>
   </wind>
   <clouds value="40" name="scattered clouds"></clouds>
   <visibility value="10000"></visibility>
   <precipitation mode="no"></precipitation>
   <weather number="521" value="shower rain" icon="09d"></weather>
   <lastupdate value="2018-03-06T13:50:00"></lastupdate>
 </current>

To get the temperature, we would have had to look for the string “temperature value=” and extract the following digits… it was possible but a bit of a dirty hack, we felt. As stated before, at Askia we love to talk but we hate dirty hacks.

So we started talking about having a XML parser. The cool kids in the dev team took a clear stand: we do not need a XML parser and we would be a laughing stock if we implemented one. What we needed was a JSON parser. Even better we thought: what if AskiaScript could natively support JSON? Note: I can confirm it, we did a XML parser anyway – I hope you are not laughing.

JSON native and the dictionary

So we came up with the following syntax:

Dim myAuthorVar = @{
 “name”:”Jerome”,
 “age“:21,
 “occupation”:”laughing stock”,
 “busy”: true,
 “children”: [“Mackenzie”, “Austin”],
 “address” : {
    “postcode”:”SW12”
    “city”:”london”
    }
 }
Return myAuthorVar [“occupation”]

We were very excited but that meant we need a new variable type – it’s sometimes called an object or a map but also a Dictionary – the failed librarians and encyclopaedists that we are loved that… so there it was: the Dictionary. It allows to store a series of named values in one object. You can set its properties with a method Set like this myAuthorVar. Set (”Busy”, False ). And access them like you would with an array but by specifying a string instead of a number like this: myAuthorVar [“name”].

Variant and Arrays of Variant

I mentioned that it would be a good time to go to the pub when somebody asked what was the type returned by a dictionary accessor. In other words what was the type of myAuthorVar [“age”] ? The response to this is “it depends”… and there was no way of knowing before. Right now, it was a number, but if a web service had indicated “age” as “fifty-ish”, the result would be a string.

So we had to introduce a new type: the Variant

If you called myAuthorVar.TypeOf(), it would return “variant”… but inside the variant is a dictionary. So we created a method for Variant to know what was inside and we called it InnerTypeOf. myAuthorVar.InnerTypeOf() does return “dictionary”.

It was also nice to write @[1 ,2 ,3] or even @[3.14159,”pear”, “apple”]  – both are arrays of variants that we decided to call “arrays” for simplicity.

A variant could hold any of what we decided to call the base basic types: number, string, date, dictionary and any array of the types above. OK – let’s go to the pub! But then we remembered that JSON supported Null and Booleans… and because we wanted full compatibility, we had to create two new AskiaScript types: Null (which does not do much) and Boolean having the possibility of only taking two values: true or false.

Booleans and back compatibility

This was a can of worms – because we used to consider True and False to be numbers. Let’s imagine some script like this:

 Dim myVariable = (Q1_Name = 7)
 ' … some clever coding…
 myVariable = 42
 ' … more clever coding…
 If myVariable = 42 Then
    ' Save the world ...
 Endif

In classic AskiaScript, this would create a variable called myVariable as a number with a value of 1 or 0 and later taking the value 42 allowing the world to be saved.

We did not want to break back compatibility. I am going to summarize what was hours of discussions. We decided that comparators (like equal or Has) had to return numbers. If they returned booleans, the setting to 42 would now trigger an error because 42 is not a Boolean. And if we permitted an automatic conversion of numbers into Booleans, my Variable would take the value True (and not 42) which would change the way the scripts ran… and the world as we know would perish.

Wordy woes

Having spoken for so long, we were quite thirsty as you might guess. But we realised that our language would become very verbose and somehow inelegant if we had to convert Variants into the type we wanted whenever we wanted to use them.

In the example above, if we wanted to find out the length of our author’s post-code, we would have had to write:

 Dim hisAddress = myAuthorVar["address"]
 Dim hisAddressAsDic = hisAddress.ToDictionary()
 Dim hisPostcode = hisAddressAsDic ["postcode"]
 Dim hisPostcodeStr = hisPostcode.ToString()
 return hisPostcodeStr.Length

This was ridiculous… it would take ages to write any serious code… and we had better things to do than write verbose code (at that stage I was thinking of all the beers I would not be able to drink if I had to type that much to get my own postcode). So we went back to the drawing table and agreed that

myAuthorVar [“address”] [“postcode”]. Length was all we needed.

This elegant code was only possible if Variants supported ALL the properties and methods of ALL the basic types. That was a lot of unit tests that we had to do. So we focused (no blurred vision) and we wrote them.

This meant a serious rewrite and a careful management of conflicts: Format is a method for numbers and dates and they act very differently. So we put together a set of rules.

I’ll give you a reference

At that point, we had spent a lot of time on this, we were (very) thirsty but we wanted it to be perfect. And we realised we had a problem – what if we wanted to change the Postcode of our author (by code).

myAuthorVar [“address”] returned a Variant holding a dictionary with the address – a copy of the address. So to change the postcode we would have needed to write:


 Dim hisAddress = myAuthorVar["address"]
 hisAddress.Set ( "postcode" , "EC2A" )
 myAuthorVar.Set ("address", hisAddress)

This was again way too verbose. So we decided that accessors ( the closed brackets [ ] used by dictionary and arrays) would not return a copy of the address but a reference to the address of the author. This meant that we could write

 myAuthorVar["address"].Set ( "postcode" , "EC2A" )

This added very serious complication the the code  it’s called pointers as in dangling pointers in C++)… and that’s very difficult to make work. In the above example (as in life), the variable hisAddress can outlive myAuthorVar. We had to write a lot of unit tests to ensure that everything worked and we did not have memory leaks. This is discussed here.

For short, a variable stops being a reference as soon as you assign it something else.

AskiaScript Anonymous

We had an ongoing problem with the Value property of question – and we thought it’d be a good idea to address it now before we went to the pub.

Q1.Value returns a string if Q1 is an open-ended question. And it returns an array of numbers if Q1 is closed with multiple response. It can also be a number or a date…

Now let’s imagine we have a script like this

 Dim myVariable = Q1
 ‘ On Mondays at precisely 12 o’clock
 If Now. Day()= 1 and Now.Hour() = 12 Then
    myVariable = Q2
 Endif
 ‘ What is myVariable.Value here?

AskiaScript is a compiler – it wants to know the type of things before it’s run… but in that example, myVariable. Value could be of a different type depending on the day and time it was run.

And what if we had something like Q1.NextVisibleQuestion.Value?

So we decided that as soon as you put a question into a variable then the variable becomes an “anonymous question”. All methods of an anonymous question would work but the Value property would be a variant…. And we also decided to make sure that CurrentQuestion was an anonymous question. Problem solved! Drinks anyone?

But then we had another huge back-compatibility problem. Let’s look at the following code:

 
 Dim myVariable = QNumeric
 Return myVariable + 1

In classic AskiaScript, the system would add an invisible “.Value” after QNumeric (we call that an implicit property). myVariable would be a number and we would return that number incremented by 1.

But with the introduction of anonymous questions, myVariable was now a question. Facing an operator (the +) we would add again the implicit property .Value. But now value would be a variant and we had no rule to add a variant to something else… up to now.

So we made sure that we had rules to add any variant to another Variant – or any basic type or array of basic types. Not just add but also subtract, multiply, divide, compare – including all the keywords like  Has, HasNone etc. In total, combining 4 operators, a dozen of comparators, with 6 basic types and 3 types of arrays (number, string and variants) that made a lot of decisions to take (and a lot of discussions) and many many unit tests.

Before we started this development, we had 1667 unit tests ensuring that all functions of the AskiaScript behave the same from one version to another.

For this, we had to add 2231 (!) more unit tests. Once they all passed successfully, we added the whole thing to Suite 5.4.8 and we hope you’ll like it.

Enough Quant Tricks, we’ll be in the pub for a swift one – we deserved it.

MaxDiff grows!

This article provides an in-depth explanation of AskiaDesign‘s built-in capacity to manage MaxDiff data collection & analysis methodologies. For those of you who, like me, need a short reminder of what MaxDiff is; this is the definition provided by Wikipedia:

The MaxDiff is a long-established academic mathematical theory with very specific assumptions about how people make choices: it assumes that respondents evaluate all possible pairs of items within the displayed set and choose the pair that reflects the maximum difference in preference or importance. It may be thought of as a variation of the method of Paired Comparisons. Consider a set in which a respondent evaluates four items: A, B, C and D. If the respondent says that A is best and D is worst, these two responses inform us on five of six possible implied paired comparisons:

A > B,  A > C,  A > D, B > D, C > D

The only paired comparison that cannot be inferred is B vs. C. In a choice among five items, MaxDiff questioning informs on seven of ten implied paired comparisons.

MaxDiff table

We have recently added a new ADC to our offering that allows you to easily create MaxDiff tables in AskiaDesign. This article covers the setup process and usage for such comparison tables:

MaxDiff table ADC

 

This Askia Design Control allows you to easily create the required screen format for MaxDiff surveys. Add the ADC to your resources, drag it on to your Most response block, set any captions you want to appear in the headers of your grid and select the Least question it should be connected to. As with most ADCs, this survey control allows you to customise many parameters, such as:

  • Least Question: when you drag the ADC on to the response block for your ‘Most’ question, this is where you define which ‘Least’ question it relates to.
  • Most Caption: the caption you want to appear in the ‘Most’ column header.
  • Least Caption: the caption you want to appear in the ‘Least’ column header.
  • Centre Caption: the caption you want to appear in the centre column header e.g. this can be information about the loop iteration or screen number.

You can play around with this survey control in the following demos:

Alternatively, you can download (or even contribute) the MaxDiff ADC from Github!

MaxDiff interactive library

When conducting MaxDiff methodology you have a number of different parameters to consider and produce programming instructions for. At Askia, we have used the R software environment to do this for the different parameters and a large range of the options for each. We have created an interactive library in Design which asks you what option you want for each parameter. The result is a greatly simplified process for producing any MaxDiff design with Askia.

The available parameters are:

  • Number of questions: also known as the number of arrangements or number of screens. This is the number of screens the respondent will see during the course of the MaxDiff section.
  • Number of selectable items: this is the number of options to choose between per screen.
  • Number of items: this is the number of attributes or statements you want to include overall in the MaxDiff design.

As from version 5.4.6 of AskiaDesign, you can now use our Interactive Library feature to easily create and setup your MaxDiff design with the help of the above parameters:

MaxDiff interactive library

 

Check out the full article for more in-depth information & resources.

Adaptive MaxDiff

As we have seen in the above, the key point with standard MaxDiff is that the arrangements on screen are pre-set and do not adapt to the responses given in interview. In addition, the number of selectable options on screen is a constant.

However, in adaptive MaxDiff, the number of selectable options will change. Each round of screens, the items selected as Least are removed from the next round of screens. The number of items on screens therefore diminishes until you get to the start of the last round where you are asked to pick between all those you chose as Most.

The advantages of adaptive MaxDiff are that greater discrimination between items of importance is achieved. The disadvantages? Well, it could be argued that, since your initial answers create the upcoming arrangements, you do not have as much opportunity to change your mind about items you have rated least important in previous rounds.

This article details these differences, provides an example questionnaire to showcase the setup of this methodology with Askia as well as instructions on using and updating the example file for your own list of items.

Of Askia Scripts and Functions

Introduction: What are Askia Scripts for? Or should I say what are their function?

AskiaScripts were designed to evaluate conditions within a survey – at first to branch the survey and then to set values to (often dummy) questions. They needed to be easy to write (and re-read!) and the user should know at creation time if the script was going to succeed or not.

The needs to improve AskiaScripts came as our clients’ surveys became incredibly complex – and that we used our language to produce our ADC.

Lately, AskiaScripts have been used to run very complex routings – like the post-codification of open-ended responses. We had a request to optimise a routing which had hundreds of lines…

AskiaScripts are also used in Tools to verify the quality of data at the end of collection. It’s here that the demand of functions came loudest where there is a need to norm the way straight-lining is evaluated for grid questions for instance. Here again we have seen scripts which have thousands of lines.

Finally, AskiaScripts are also used in Analyse to achieve increasingly complex calculations on the fly – and aggregating data while being at interview level.

From the feedback we received, we believe 2.0 is a success although the in-take has been slow (even internally).

I believe AskiaScripts will be used for weird custom adaptive conjoint, very complex calculations at run-time (segmentation) – I think it will also be used in defining and running super portfolios at a later stage.

Let’s summarise what the core values of AskiaScripts are – knowing they could be antonymic:

  • Simplicity
  • Adapted to survey research
  • Reliable: minimise the likelihood of runtime errors
  • Powerful: the competition often uses JavaScript (which does not have the 3 previous points)
  • And finally extensible – by Askia and by users

Functions: extending Askia Scripts

Rather than us adding functions whenever they are needed (which will still happen), we have decided to let users create their own functions. Teach a man to fish and you have saved yourself a fish.

A function is a piece of code that you can call with different parameters.

By default, the parameters of a function will be passed by value for our basic atomic types: numbers, strings, and dates. The arrays (and all complex objects) will be passed by reference.

Script Value Reference screenshot

If we want to change the way the parameters work, we can use the keyword ByVal or ByRef to force passing the parameter by value or by reference respectively.

Script By Val By Ref screenshot

Let’s talk about scope, baby

Scopes of variables screenshot

A scope defines where a variable is available.

Variable1 is available throughout your script. Referring to Variable2 will generate an error if it’s after the Else statement.

AskiaScript hit the same problem that most scripting languages have had (JavaScript, old VBA, … ). Every variable created is global – unless it’s within a For or an If – or a function.

This might not be a problem when you write a routing condition. It will be if you write an Adaptive Conjoint or a full-on survey analyser. You will need to remember which variables you have already used and name them differently and it will make it very hard to re-use code (the holy grail of any programmer). It also makes IntelliSense (automatic code completion) absolutely unusable.

Every language came up with a different solution to that problem. The original 1960 languages had global variables. Then functions were invented (with parameters passed by value or by address). Then classes and name spaces were invented. JavaScript went another way – it used nested functions to make sure that variables (and sub-functions) were not visible everywhere.

To be or not to be typed, that is the question…

Any variable or method in Askia is strongly typed – this means that at compilation time, we already know the type of the variable. This allows us to know if you can use a method or not for every object.

For questions, this means that we we know that Gender.Value is a number (1, 2 or DK) and that FavouriteNewspapers.Value is an array of numbers.

But if we have a function that takes a question as a parameter, we do not know the type of its value: it could be a number, an array of numbers, a string or a date…

Script Typed Question screenshot

Within the function, we say that the question is anonymous. And we have defined its Value to be a Variant. A variant is an object whose type we only know at run-time. For this, you have a few properties that you can use to convert a Variant into something more useful.

A variant has the property InnerType which indicates what it holds. You can convert any Variant into something else with the following methods: ToNumber(), ToString(), ToDate(), ToNumberArray().

Script Variant To String screenshot

Mods rule!

After a lot of internal discussion, we have decided to define Modules – or name spaces. You will be able to put together a set of variables and functions together. By default – and unless you specify it – these variables and functions will not be accessible from outside of the modules – in Object-Oriented Programming, this is called encapsulation.

You will be able to make some of the variables and functions available from outside the module – they will need to be prefixed by the keyword Export.

To clarify everything, let’s have some sample code:

Script Module screenshot

Inside the module, you can refer to the variables MaxAnswers and Pi from every-where. And you can call any function defined in there.

Outside the module, you will have to write SampleModule1::DoTheCalculation or SampleModule1::MaxAnswers to access the public members.

The default way to create a module is with Module XX / EndModule. You can either include the definition of your module in your condition script OR write it in a file that you add as a resource. These files must have a .asx extension (Askia Script eXtension). To use a module in a routing, you need to call Import + name of the module.

Script Import Module screenshot

Note that a call to SampleModule::PI or SampleModule::DoTheCalculation would return an error.

When Import SampleModule1 is called, all the code which is outside of the function will be run – that is everything in Initialisation a) and Initialisation b) in the example above.

AskiaScripts evolve all the time… and we might create a function which conflicts with a user defined one. The user defined one should still work (and be called) once the new version is released – back compatibility is important.

One side effect of what we have decided to do with modules is that variable declared in the main scope will be global in a whole script if modules are not used. We are hoping we won’t regret this in the future but the aim of AskiaScripts is not to build full on applications… yet!

Conclusion

Functions and modules will be available in 5.4.5 – released in askiafield in February 2017. We will – at a later stage – introduce newer concepts – true OOP, lambda functions. Imagine two instantiated similar modules, it’s pretty much like two objects! We might have something like Dim myObject As Module1 somewhere down the line.

I also believe that we will like to add methods to Askia objects: example Array.RemoveDuplicates().

Script Remove Duplicates screenshot

Note the possible keywords Extends and This (should we call it This or Self?)

But in the meantime, what we have added should make most advanced users happier. We’d love to hear what you think and you suggest what we do next.

Our latest survey controls

In order to allow our users to further engage with their respondents, we have been relentlessly adding new survey controls to our software offering. These controls, also known as ADCs (Askia Design Controls) are freely accessible to all Askia users and allow extended customisation so they fit your needs.

Below, a selection of our latest survey controls:

Responsive Table

The Responsive Table ADC allows you to embed grid (matrix) questions in your survey without having to worry about mobile and tablet respondents. The table will expand / collapse depending on your respondent’s available screen real estate.

Responsive Table Askia Design Control demo

Check out the demo survey and resize your browser to see it in action. You can also check out the dedicated knowledge base article for the full-blown details and example questionnaire.

Video

The Video ADC allows you to easily embed an .MP4 video file in your survey with all the necessary options:

  • Auto-play video
  • Show media controls (play, pause, volume & full-screen)
  • Auto-submit question after video

Video Askia Design Control screenshot

Take a look at our demo survey for this control or go through the KB article for more information.

Audio

Much like the above ADC, the Audio survey control allows you to embed an .MP3 audio file in your survey with the following settings:

  • Auto-play audio file
  • Show media controls (play, pause & volume control)
  • Auto-submit question after audio

You can play around with our demo survey or check out the dedicated article to get started.

Open

We have always provided default text inputs for our open-ended questions but this survey control will supercharge such questions with nifty options:

  • Character count / max character count
  • Email input validation
  • Password input

Open Askia Design Control demo

Access the demo survey to see it in action and check out the knowledge base article for more in-depth information.

Image Lightbox

Displaying images in your survey is straightforward but sometimes you need your respondents to actually be able to view image details and benefit from a larger version of the image in order to answer a question. This is where this ADC will help as it will allow you to provide a larger render of your image without the hassle of laying out your survey page for a wider / higher image (especially when your respondents are accessing your survey from a mobile device).

Image Lightbox Askia Design Control demo

As usual, take our demo survey for a spin or head directly to the dedicated KB article for all the details.

Presenting ADXStudio

ADXStudio is here!!

What is it?

ADXStudio is an IDE for people who want to create Askia Design Control (and later Askia Design Page) easier and faster. This application can support AskiaScript, JavaScript, HTML, CSS, … and more.

ADXStudio was built with Electron, this application is based on NodeJS. Furthermore, we have included CodeMirror (already used in Design and Vista) to get a complete text editor with syntax highlighting and autocompletion.

Installation

To install ADXStudio, follow the procedure available here.

ADXStudio is available on Github and everyone who wants to contribute can download the source code and send us a pull request.

A little bit of ADXStudio:

Check the documentation to learn how to create ADCs:

The TreeView :

It’s the left part of the app in which you can see your project.

ADXStudio-Treeview

New Project:

In the Menu bar (at the top of the application window): go to “File” and click on “New Project” to generate and open a new ADC Structure !

ADXStudio-NewProject

Workspace :

The Workspace part of the application, is the panel located on the right of the window. You can edit your text inside with syntax colouring and autocompletion for AskiaScript, JavaScript, HTML, CSS and Markdown.

ADXStudio-Workspace

Project Settings :

The project Settings view allows you to see and define the settings of your current project (author, project name, …) and is accessible through File menu -> Projects settings.

ADXStudio-ProjectsSettings

Preview + Property Grid :

The preview can be accessed from the “Tools” menu item. Click Preview when your ADC project is open to trigger a preview of your currently opened ADC. The property Grid, visible at the bottom of the preview, let’s you change the properties of your control and preview the result.

ADXStudio-Preview

Build your Askia Design Control :

Finally, to build your .adc control -> select “Build” from the Tools menu. ADXStudio will create the .adc file in the bin folder of your project.

Is Askia compatible with Windows 10 ?

AskiaSuite

Starting from version 5.3.5 of AskiaSuite (askiadesign & askiaanalyse), our beloved swiss-army knife software suite is compatible with Windows 10.
AskiaSuite 5.3.3 is NOT yet compatible (as of November 2015) with Windows 10.
Please check the comments below to see the latest update.

Supervisor & CATI

While askiafield 5.3.3 appears to be compatible, we recommend using the latest 5.3.5 versions, for the sake of matching your AskiaSuite version.

Web-based applications

Our browser-based applications, such as askiavista or askiaweb are not affected by client OS changes and thus remain compatible.

Happy upgrade!

 

New version 5.3.5.0 of askiadesign

We’re excited to announce that a new version (5.3.5.0) of askiadesign is available; as usual, this update contains some nice new features as well as some dead bugs!

Update question properties globally or for a set of questions

We have added a new “Set questions” menu when right-clicking a question in the treeview. You can choose to activate/deactivate four options:

  • Allow Don’t Know
  • Visible
  • Ordered responses
  • Visible in Analyse

PrintScreen1

New “Change the response order” routing

In the same way we use the “Change order” routing to randomize questions, we can now manually specify the order of the responses shown using the new “Change the response order” routing.

PrintScreen4

New shortcuts for routings

You can now use Ctrl + C / Ctrl + V to copy and paste routings and also Alt + Up / Alt + Down to move routings up and down.

Filter view improvement in the routing mode

There are now 4 options available to filter the routings summary view:

  • All routings (view all routings of the questionnaire)
  • After selected question (view the routings where the start question is the one selected in the question tree)
  • Targeting selected question (view the routings where the target question is the one selected in the question tree)
  • Involving selected question (view the routings where the start or target question or any script referring to the selected one in the treeview)

PrintScreen2

Script window improvement

We have improved the dialog to create askia scripts and integrated into the HTML code an interactive help about the current question
allowing you to search responses and insert a range of responses.
We have also removed the obsolete win32 controls to allow more real estate to the script itself.

PrintScreen3

More keywords for the askia scripts

We have added the new Interview object to the askia scripts and implemented the following properties:

  • Interview.Broker
  • Interview.BrokerPanelID
  • Interview.GUID
  • Interview.IPAddress
  • Interview.Latitude
  • Interview.Longitude
  • Interview.PanelID
  • Interview.Progress
  • Interview.Seed
  • Interview.ToString
  • Interview.TypeOf

We have also added the StdDevEst which works on numerical array. The StdDev is equivalent to STDEV.P and StdDevEst to STDEV.S in Microsoft Excel.

Property view allowing HTML preview in realtime

We have added a property view which allows users to change settings in any of the controls (including ADC) without having to right-click “Properties”, change the settings, click apply, view in HTML mode.

PrintScreen5

The complete list of new features and bug fixes can be found here.

Askia Design Controls now available on Github

We’re thrilled to announce that all our Askia Design Controls 2.0 (ADC) have been made available on Github for all developer users who wish to take part creating these survey controls.

ADCs are web-based (HTML, JavaScript & CSS) rich survey controls that enhance the experience of your respondents. Available for web, tablet and mobile surveys, ADCs replace the default radio buttons, checkboxes, text inputs, … by more interactive, playful and animated survey controls.

Below, some examples of Askia Design Controls:

Drag and drop

Drag and drop ADC

(click the above image to check out the live demo)

Smiley rating

Star rating ADC

(click the above image to check out the live demo)

Granite controls (in-progress):

Granite ADC

More than 20 of these survey controls are now accessible to all and many more are on their way!

We have extended the way we have been working with these controls internally at Askia; instead of keeping design, development and maintenance of ADCs within the realm of our development team, we have trained a large part of our support team who are now able to contribute! So, instead of two developers working on ADCs, we now have a team of 7 collaborators and many more clients of our working on their own ADCs (big shout-out to them!)!

You can now easily download and collaborate with our team to improve these survey controls, add new controls, fix any issues you spotted or just make these controls your own!

You can either just download any ADC you want by using the ‘Download ZIP’ button if you do not wish to contribute but just use of one of the available ADCs on Github:

Download ZIP archive of an ADC

Or, if you want to fork our repos to further contribute and collaborate with us on these projects, just sign up for a free Github account and you’ll be in within minutes! This will allow you to create your own branches, create issues, add new repositories, …

Of course, all of our ADCs remain available for non-developer users in our Help Centre for use in askiadesign; they can all be downloaded, previewed in demo surveys and are all fully documented.

Version 5.3.4.0: askiadesign

This post is the first in a series of two that detail the key features of version 5.3.4.0 of askiadesign & askiaanalyse.

In askiadesign 5.2.2, we introduced new controls into our library, the ADC (Askia Design Controls).

It gives you the possibility to select which controls you would like to use on your web screen and simply drag and drop the selected control onto the screen. 

Each one of these ADCs is shipped with many settings that will allow you to fine-tune and customise the rendering of the controls

Version 1 of the Askia Design Controls (ADC 1.0) was based on Adobe Flash.

In askiadesign 5.3.3, we created the first set of new ADC 2.0 controls which are JavaScript-based.

These controls are therefore compatible with all devices and the controls includes intelligent fallbacks so if JavaScript is not enabled the controls generate classical HTML controls. 

As with ADC 1.0 (Flash), ADC 2.0 allows you to customise the appearance as well as the interaction of your survey controls by giving you access to their design parameters.

Askia Design Controls in askiadesign

When generating the screens in HTML, we can also automatically associate an ADC to a given type of questions.

We can assign different controls to single, multiple or grid questions and predefine their properties.

Screen generation options for ADCs in askiadesign

In askiadesign 5.3.4.0, we have improved the management of question compatibility when you drag and drop an ADC to a response block.

AskiaDesign checks if a control requires a loop or not.

It also indicates the list of questions types it was designed for when it indicates the control is not compatible.

ADC compatibility in askiadesign

Askiadesign  automatically creates a response block when dragging an ADC on to incompatible screens.

Below the list of gender are as classical responses but the ADC should be applied to a response block.

Automatically generate response blocks for ADCs in askiadesign

After the drag and drop of the ADC, the list of classical responses is automatically transformed into a response block and the selected ADC was applied as well.

Askia Design Control generated in askiadesign

Have a look at the list of ADC 1.0  and ADC 2.0 controls.

The Electric Kool-Aid Askia Test

Abstract: Survey scripting and coding have lots in common and we should bring testing techniques into Survey Design. For this we have improved Random Data Generation and created a new Tools module called “Script Verification”.

SurveyMonkey, Google consumer surveys and other disruptive DIY technologies have changed the Market Research industry. Any marketing director can put together an online survey, get sample from a number of panel providers and have results to their strategic questions in hours.

But Askia software is not designed for marketing directors. It has been conceived for survey specialists, scripters, data processors who design and analyse complex surveys – sometimes long, sometimes algorithmically challenging, over long periods of time and eventually collecting millions of records. And with our target audience in mind we are continually improving our range of software. We want any design to be achievable, any layout, any number of records. It would be an exaggeration to call it Big Data but let’s say we specialise in “Medium Data”.

On the subject of interview data, I will only mention that in the last 2 years we have completely overhauled our way of storing data in SQL Server (5.3.3) and a new compressed inverted data format (5.3.4). But I am digressing, the subject of this article is about methodologically managing complexity.

Managing complexity with Askia's survey software

The challenge with complexity is that it invariably leads to human errors, their number exponentially growing with size, harder to spot and often too late. The thing is we, as programmers, know about complexity. Askia software is made up of millions of lines of code and, as some of you may have fleetingly experienced, it sometimes breaks. And, believe it or not, we coders have an aspiration to perfection: we constantly try new methodological or technical ways of testing our software so it works smoothly the second we release it. But any program that does anything more than sorting three numbers is bound to break and we have to live with the fact that we will always deliver short of what we wished for – but hopefully learn from past mistakes.

Survey scripting is programming – unfortunately Market Research tools are a little bit behind (yes we are aware of our responsibility there). Our first version of Design in 1994 was attempting to mimic the revolution Visual Basic brought to the programming world in 1991. All basic functionalities were available in a Graphical User Interface. We made the layout WYSIWYG but we still allowed programming in event driven scripts but hidden from the interface. Our AskiaScript still has the traces of its ancestry with variables defined with Dim, For Next loops – I’ll admit that not everybody at Askia thinks it’s a good thing but that’s the price to pay for backwards compatibility.

Reusability & object-oriented programming by Askia

Reusability is the key to decrease development time and increase reliability. For programmers reusability is generally known as Object-Oriented Programming. In all of our software, we have tried to include reusable objects: Generations Settings and Internet options in askiadesign, Tab-templates and clones in Askiaanalyse, survey inheritance in askiasurf, libraries everywhere. Last but certainly not least we have created Askia Design Controls: we have enabled (advanced) users to generate the perfect HTML / JavaScript for each PC / tablet / mobile target whatever the browser, its version or its Operating System. ADCs encapsulate data, they are polymorphic (you can use them on different types of questions and browsers) and because they are open source, it’s up to you to give them inheritance.

There is another part of programming that we would like to bring to the Market Research industry: it’s testing – unit testing, integration testing, system testing. For the development of AskiaScript 2.0 we designed the tests before we wrote one line of code – this is called test-driven development (TDD). The number of bugs was minimal for a development of that size. Each time we found a fault, we added it to the list of tests to make sure it would never surface again in subsequent versions.

Test-driven development in survey design by Askia

Along with the spec of a survey, there should be a list of tests. These tests should be run by someone other than the survey scripter – and the tester should not peek into the routing coding. Different people will think differently ensuring your tests cover more defects.  We have put together a non-exhaustive list of tests:

  • Interview level: data presence for mandatory questions, skip routing testing, coherence between questions, testing links and response visibility.
  • Usability testing: testing each screen on every platform.
  • Aggregated testing: making sure quotas are respected, rotations are balanced, multiple questions have multiple responses.
  • System testing: ensuring the survey runs well on the server and that the data you produce is usable.

Long before considering a soft launch the simplest way to see if your survey runs correctly is to generate random data. You have two ways of doing so: either by using AskiaTools’ random data generator or using a JavaScript simulator (see here). The JS simulator is a great way to achieve systems testing.

System testing can also be achieved by exporting test interview data as .dat files and looking at the size of the individual dat files: you will be able to measure the load that will incur on memory. Multiply this by the number of concurrent interviews you expect and you will have an idea of the specs you need on your server(s). Additionally, looking at the size of a .QES file or preferably of the tables generated in SQL server will indicate how much Hard Drive space you will need.

Random Data Generation in askiatools

We have recently added a lot of features to the Tools random data generator: you can define routings that would only be run during random generation (for validating the screening for instance), you can specify the behaviour when blocking error messages are displayed and more importantly you can import your quota settings and take them into account in your generation (all available in 5.3.3). Quota code is often complex and going over could be an expensive mistake.

We have also created a brand new module in Tools 5.3.5 called “Verification scripts” (see here for more details). This allows a tester – remember not the survey scripter – to create checks in AskiaScripts that will be run on each interview. So you can verify that the question about credit cards has been asked if the interviewee has mentioned banks in another question. You simply write a check like this:

Assert.Check( Banks <> {} and CreditCards.HasNA,” Interviewee should have been asked the question about credit cards” )

The scripts can be as long as you like, we have added If Else conditions and Goto to help you create complex code that you will keep in one single text file. And you can write it within an environment – the askia visual studio – where you get help and documentation on any objects, methods or keywords. You can run this on your randomly generated data, on your soft launch or on your full data set – each time you get a detailed report of how many checks have failed. At the time of writing, this is not released yet but contact us if you want to try a beta.

In these scripts, we also want to have access to aggregated data… this will allow us to have one script that runs interview level testing and aggregated testing. We might want to test if an interview took less than 10% of the average length or if a given response to a question is outside a percentile. In other words, you might want to compare interview responses not with other interview responses but all other interview responses. The script grammar for this will be described in a forthcoming article – we are still passionately discussing it internally.

Usability testing in survey design by Askia

We have not covered usability testing here – not that we do not think it’s important: we are constantly talking about it internally. We are putting together a range of tools for designing ADCs (so far codenamed ADCUtil – yes we need something catchier), we have added ways of visualising your HTML in other browsers in Design. But we need to understand when a display no longer works because of screen size, the bias triggered by no longer using JavaScript, count the number of heads of Internet Explorer 5 users – and there again we need your input and your ideas so we can automate these tasks.

In the meantime, I leave you with these great quotes:

The act of maintaining software necessarily degrades it.” – Alain April

It’s harder to read code than write it.Joel Spolsky

If you can’t measure it, you can’t improve it. Peter Drucker