I think a good place to start is my design decision to store information about the Q Sort - both the Q Sort board and the Q Sort statements - in a text file stored on the Internet. The purpose of this decision was two-fold. First, I wanted to come up a simple file structure for dynamically defining and constructing the Q Sort activity. That is, when I started this project I knew I needed to design the app in such a way so as to allow for any text-based Q Sort to be constructed. (Quick aside: there is no inherent reason why Q Sort statements need to be textual. They could easily be pictures, sounds, or videos. But, I decided that I would focus my attention initially on text-based statements given that this is the dominant mode for the kinds of research and teaching needs I do.) I've used the approach of storing data that dynamically controls content of an app in a simple text file in other projects, most notably the project where I built a multiple-choice question app. It's a very useful and flexible approach, plus has the added charm of being very simple to do.
Here's a flowchart of the data download process that is used in this approach:
I used a background color of orange for the "pizza.txt" step and blue for the other steps to highlight the fact that the data is stored on the Internet (orange), then downloaded into the app (blue). In this post, we'll look at each of the first three steps of this process in more detail.
Data Stored in a Text File on the Internet
I am a big fan of eating pizza.
Most important,Least important
The toppings are vegetarian.
The pizza is inexpensive.
The pizza has lots of cheese.
The crust is thick and chewy.
The pizza has lots of toppings.
The ingredients are grown locally.
The toppings include meat.
The crust is thin and crispy.
The pizza can be delivered to my home.
I realize your eyes are probably beginning to glaze over, but trust me, it's not nearly as complicated as it looks.
Line 1 is the title of the Q Sort activity.
Line 2 is a summary statement about the entire Q Sort activity. I don't use this statement yet in my prototype, so we can safely ignore it for now. But, as a very short explanation, just know that I'm thinking of ways to use a Q Sort activity as a teaching tool, not just a research tool. As a teaching tool, I think it would be a good idea to ask participants AFTER the Q Sort activity concludes to rate their opinion of this statement. I'll talk more about this later.
Line 3 includes the labels of the two poles of the rating scale, each separated by a comma. It was important to include this because the rating scale can vary tremendously. Typical examples would be "Most Agree-Least Agree" and "Most Important-Least Important," but the range of possibilities is endless. The point here is that this is an important dynamic element of a Q Sort.
The next group of lines define the elements of the Q Sort board, so let's consider them in some detail.
Defining the Elements of the Q Sort Board
Defining the elements of the Q Sort board is not complicated, but I admit that this the most obtuse part of the text file. There are four elements or items in each line, each separated by a comma. How one constructs it depends on the shape of the Q Sort Board. It's much easier to understand these lines if you visualize the board itself. So, here is a visual representation of the "Pizza Board" that was also included in my previous post:
Notice first that the scale ranges from -2 to +2 with 0 as the neutral spot. So, there are a total of five columns in the board. My design uses a linear representation of the board, with the rating progressively moving from right to left with an indentation to denote each rating notch. (Aside: we are accustomed to a Cartesian coordinate system where positive numbers are on the right and negative numbers are on the left.)
With that in mind, the first item in each line dictates the "indentation" of that rating element. A reminder that indentation goes from right to left, so 0 indicates no indentation, so this is reserved for the most "positive" rating element, or +2 in this case. Now, take a moment and work out in your mind how many "steps" are needed to move from +2 to -2. The answer is 4. Notice that there are two lines with a step of 1, then three lines with a step of 2, then two lines with a step of 3, and finally one line with a step of 4. Take a moment a see how this relates directly to the image of the Q Sort board above.
The Second Element of the Q Sort Board
The second element in each line (again delimited by the comma) is the rating scale itself which ranges from +2 to -2. This element is shown on each slot, preceded by the text "Rating: ".
The Third Element of the Q Sort Board
The third element in each line is the color of the slot. This is denoted using the common hexadecimal notation. I realize that this is not a very friendly way to represent color, but believe me, it really is a typical way to do it. Now, in fairness to LiveCode, you can also represent color using more descriptive terms, such as "yellow," or "red," or "green." But these denote a very small range of the color spectrum, so I thought it best to give the designer as many options as possible to define the color of a rating slot. Given that LiveCode allows for this approach, I thought it best to use it.
The Fourth Element of the Q Sort Board
The fourth element is completely optional - it's merely a description of the color. If you leave it off, nothing of consequence will result. Think of it as a "comment element." For me, I don't commit hexadecimal notation to memory, so I wanted to quickly be reminded of the colors I've chosen. You could comment on this or anything else you want.
Defining the Q Sort Statements
Notice that the next line begins with a hash tag, otherwise known as a pound sign - #. I decided to use this symbol as my "signal" that we are now going to define the information for the Q Sort statements. The LiveCode script looks for this symbol and when found, begins to interpret the lines that follow as those that define the Q Sort statements themselves.
There are no other elements that follow these Q Sort statements, so when the text file ends, this will trigger the end of the statements for the LiveCode script. The important thing to note here is that there is one line per statement.
Creating a Utility to Help People Construct the Q Sort Information
Transferring the Data Stored in a Text File on the Internet to the LiveCode App
Now that we have a better understanding of how the text file is constructed, let's take a look at the LiveCode script that also "interprets" the text file. All of the code is contained within the big yellow "Begin" button on the title card:
Unfortunately, blogger doesn't allow for an easy way to reference lines in code, so I'll use a color-coding scheme where I'll toggle between red, blue, and orange. And, I won't even try to explain every single line of code. My goal is to give you the gist of what's going on here.
The first line in red goes and looks for the URL entered into the field "qsortURLdownload" on card "administration" into the global variable "varDownloadSite." Recall in the video that the card "administration" has two fields that contain the URLs for both the download of the Q Sort information detailed above and the URL to which the Q Sort data resulting from the participant's work is sent:
The next line shown in blue basically does a "copy and paste," taking the information found in the text file stored on the Internet (the URL of which is now stored in the variable "varDownloadSite") and puts it into the field "download" on the card "resources," a card hidden from view from the participant.
However, it's easy to anticipate that there might be a problem accessing this file, such as when there is not an Internet connection at the time the participants runs the file. So, the rest of these blue lines list code that will alert the participant to this problem. If this code is triggered, the line "exit mouseUp" is executed, which does just that - the button basically "quits" and no more of the script is executed.
The next lines shown in orange simply store lines 1-3 in three global variables that are used in various places in the app:
- Line 1 is put into the variable "varQTitle"
- Line 2 is put into the variable "varSummaryStatement" (though remember that the app doesn't yet use this)
- Line 3 is put into the variable "varRatingLabels"
Data Separated for Q Sort Board and Statements
Defining the Q Sort Statements
So, What Do We End Up With?
This is a good place to stop. I hope you get the general idea of the approach I'm using here. This approach is good for any software application with dynamic elements, assuming the data structure is not too complicated. If it is, then using a bonafide database like mySQL would be the way to go. Next time we'll consider the scripts need to construct and present the Q Sort to the participant.