This is the first of several posts explaining how the first prototype of my Q Sort app works.
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.
Let's begin by understanding the structure of the text file stored on the Internet. Here's the pizza example I used in my previous post:
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 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 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 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 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.
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.
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:
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.
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
Pizza
I am a big fan of eating pizza.
Most important,Least important
0,+2,#ccffcc,light green
1,+1,#ccffff,light blue
1,+1,#ccffff,light blue
2,0,#ffffcc,light yellow
2,0,#ffffcc,light yellow
2,0,#ffffcc,light yellow
3,-1,#ffcc66,light orange
3,-1,#ffcc66,light orange
4,-2,#ff9999,light red
#statements
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
It has crossed my mind that it would be helpful if I take some time in the near future to build a little utility that helps would-be researchers or teachers using this Q Sort app - should it prove to be valuable - correctly build the text file.
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:
global varDownloadSite
on mouseUp
//get URL for download site
put field "qsortURLdownload" on card "administration" into varDownloadSite
put empty into field "download" on card "resources"
put URL varDownloadSite into field "download" on card "resources"
if field "download" on card "resources" is empty then
answer "There was an error downloading information. Please check your Internet connection." with "OK"
exit mouseUp
end if
//Extract the data
global varQTitle, varSummaryStatement, varRatingLabels
put empty into field "board structure" on card "resources"
put empty into field "statements" on card "resources"
//field "download" on card "resources"
//field "board structure" on card "resources"
//field "statements" on card "resources"
put line 1 of field "download" on card "resources" into varQTitle
put line 2 of field "download" on card "resources" into varSummaryStatement
put line 3 of field "download" on card "resources" into varRatingLabels
put the number of lines in field "download" on card "resources" into L
//look for # and put lines above into board structure field
repeat with i = 4 to L
if char 1 of line i of field "download" on card "resources" = "#" then
put line 4 to (i-1) of field "download" on card "resources" into field "board structure" on card "resources"
exit repeat
end if
end repeat
//look for # again and put lines after into statements field
repeat with i=4 to L
if char 1 of line i of field "download" on card "resources" = "#" then
put line i+1 to L of field "download" on card "resources" into field "statements" on card "resources"
end if
end repeat
//Done go to the sorting activity
go to card "sort"
end mouseUp
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
The next group of lines in red defines the structure and visual representation of the Q Sort board. I think the key thing here is that there is a repeat loop that continues until it finds that all-important hash tag "#". This sends the message "Whoa! Don't go any further" to the repeat loop. All of the lines the repeat loop finds is then put into the field "board structure" on the card "resources."
Defining the Q Sort Statements
The next set of blue lines denote the script that look for the Q Sort statements. Once again, the key here is hash tag "#" - the script starts at the top and works its way down until it finds the hash tag. Then, it takes all lines afterwards as the list of statements, with one line per statement. This information is put into the field "statements" on the card "resources."
So, What Do We End Up With?
Obviously, the card "resources" is rather important here, and I'm guilty of not telling you much about that card yet. This card is just that, an important resource for the app - it is used to store the information just teased out of the pizza.txt and sorted into the various Q sort components. So, let's take a look at that card:
There are three fields on this card. Going from left to right, they are "download," "board structure," and "statements," just as described above. Basically, this card just disentangles the information from the text file.
It's important to point out that I didn't have to store this information in fields on this card. Instead, I could have stored this information in global variables. But hey, I'm a very concrete kind of guy and I like being to actually "see" stuff like this. And, it obviously helps when I'm trying to explain this to others because I can actually show the card with the fields, which is much more tangible than variables.
Closing
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.
