I have made so many revisions and updates to my Q Sort tool that I hardly know where to begin. The most important point to be made, though, is that all of these changes have been made based on using the app in authentic ways with people. That is, I haven't made changes based simply on my own insights or whims, but on what people have reported to me they find annoying, bothersome, or problematic along with also knowing something about they like about the tool. Both are important because improving the tool is a combination of addressing weaknesses but not ruining the good stuff. (This is my third blog posting about this tool, here are links to the first and the second.)
Many challenges remain, so I'm hardly feeling even close to being done. The biggest weakness remains the total number of statements that I can comfortably put on the screen at any one time. Right now the app can comfortably handle 20 statements, with about 25 being the absolute upper limit. For Q research this is a serious limitation. However, for instructional applications of the Q sort - which is currently my main focus - this is fine. Indeed, for a class activity I think any more than about 20 statements would likely cause some frustration.
A Look at the Current Version
Here's a video demonstrating the version I'm currently using in my teaching - I made this video as an introduction for my students:
The first update is obviously my new, improved, and awesome screen design for my title card. OK, well, maybe it's not so awesome, but hey, check out that big red Q! (Strange how one can be proud of the stupidest things.)
On a more serious note, here are probably the two most important design features that are part of the current prototype.
The issue of text size is a problem not easily solved given the limited screen space of most computer monitors. I've added two options in response to requests from users with moderate visual impairments (and frankly, I easily fall into this category). The first is the option to turn on and off a magnification window showing in large text the statement most recently clicked or moved. And, although I don't highlight this fact in the video, the user can drag this magnification window anywhere on the screen.
Now, I thought I had "nailed it" with this modification, but one person in my summer class who was the first to call for some adjustment to the statements' text size wasn't satisfied, and I'm very glad she was forthcoming enough to tell me so. What she really wanted from the beginning was a way to increase the text size of the statements directly. I had dismissed attacking the problem head on in this way because I just felt there wasn't room, but I went ahead and explored it. In the end, I was able to give users the ability to increase the text size of all of the statements, though to a limited degree. Most important, this seemed to meet the needs of the people who gave me this feedback.
Another related change was the option to quickly shift all of the unsorted statements either left or right on the screen. This option was the idea of another person in my class and I found it very easy to implement. Even with these changes, the limitations on screen size still makes the sorting activity feel cramped, but they seem to have surmounted the big, early objections of users.
As mentioned in one of my previous blog postings, other computer-based Q sort tools overcome this problem by having the user do multiple sorts beginning with a general sort (e.g. into high, low, and middle groups), then having the user do secondary sorts with the smaller sorting groups. Although this seems adequate, the Q sort literature makes it clear it is preferred for users to have access to all the statements throughout the sorting activity. So, at least for now, I'm trying to stick to this "pure" form of the Q sort activity.
One of the most exciting developments over the past few months has been the emergence of an instructional strategy to use the Q sort activity within my teaching. This strategy took shape throughout the entire summer and I am again trying it out with my fall design course. The strategy can be briefly summarized as follows:
This feature is critical for step 4 of the instructional strategy, though it wasn't available until recently. Instead, I had asked people to write down their top-most and bottom-most statements, but this turned out to be a bad approach. I now have the app save each Q sort the person completes to a text file on their computer. (Actually, I had been saving this information all along as a redundant "safety net" for research purposes. So, it was a pretty easy to option to create.)
On a more serious note, here are probably the two most important design features that are part of the current prototype.
User Control Over the Text Size of the Statements
The issue of text size is a problem not easily solved given the limited screen space of most computer monitors. I've added two options in response to requests from users with moderate visual impairments (and frankly, I easily fall into this category). The first is the option to turn on and off a magnification window showing in large text the statement most recently clicked or moved. And, although I don't highlight this fact in the video, the user can drag this magnification window anywhere on the screen.
Now, I thought I had "nailed it" with this modification, but one person in my summer class who was the first to call for some adjustment to the statements' text size wasn't satisfied, and I'm very glad she was forthcoming enough to tell me so. What she really wanted from the beginning was a way to increase the text size of the statements directly. I had dismissed attacking the problem head on in this way because I just felt there wasn't room, but I went ahead and explored it. In the end, I was able to give users the ability to increase the text size of all of the statements, though to a limited degree. Most important, this seemed to meet the needs of the people who gave me this feedback.
Another related change was the option to quickly shift all of the unsorted statements either left or right on the screen. This option was the idea of another person in my class and I found it very easy to implement. Even with these changes, the limitations on screen size still makes the sorting activity feel cramped, but they seem to have surmounted the big, early objections of users.
As mentioned in one of my previous blog postings, other computer-based Q sort tools overcome this problem by having the user do multiple sorts beginning with a general sort (e.g. into high, low, and middle groups), then having the user do secondary sorts with the smaller sorting groups. Although this seems adequate, the Q sort literature makes it clear it is preferred for users to have access to all the statements throughout the sorting activity. So, at least for now, I'm trying to stick to this "pure" form of the Q sort activity.
Developing an Instructional Strategy for the Sorting Activity
One of the most exciting developments over the past few months has been the emergence of an instructional strategy to use the Q sort activity within my teaching. This strategy took shape throughout the entire summer and I am again trying it out with my fall design course. The strategy can be briefly summarized as follows:
- Collaborate with the students to identify a topic for a Q sort activity.
- Ask each student to complete a short online survey about the topic resulting in a short statement of no more than about 15 words. (I use a simple Google form for this.) I then compile the statements and edit them for redundancy, resulting in a total list of 15-25 total statements to be used in the Q sort activity.
- The students complete the Q sort activity on the assigned topic either shortly before the start of an online virtual class session, or at the start of it. (I've had mixed success and problems with each.)
- The students then participate in a small group discussion during class using their Q sort answers as a guide for the discussion.
- During the small group discussion, I create a summary report of the Q sort data, which is then shared with the class when they return from the small group discussion.
- Using the summary report, a whole class discussion is held. Individuals or groups are given the opportunity to make comments as they wish.
Step 5 is a weak link at present in that it is not easy to do quickly with accuracy. I'm using Excel as the analysis tool and I find it takes me at least 20 minutes of focused effort to get a minimal report ready. This is very difficult to do during class, even though I'm not needed during the small group discussions. It's not a problem if I hold the Q sort activity asynchronously prior to class. Ideally, I would program another LiveCode app to do the analysis for me, which I may wind up doing. For now, I'm going to try to build an Excel template that allows me to quickly drop in the data.
The Option for a User to Review Their Choices to Any Previously Completed Q Sort
This feature is critical for step 4 of the instructional strategy, though it wasn't available until recently. Instead, I had asked people to write down their top-most and bottom-most statements, but this turned out to be a bad approach. I now have the app save each Q sort the person completes to a text file on their computer. (Actually, I had been saving this information all along as a redundant "safety net" for research purposes. So, it was a pretty easy to option to create.)
A Preview of the Revisions I'm Currently Working On
I've had some uncertainty with the FTP upload of the data to my web site. My web hosting company had some issues recently which I believe interfered greatly with the last Q sort activity I conducted. Basically, I think my web site was down when several people tried to upload their data. The bottom-line for me is the need to improve the reliability of the app's uploading of the data and alternatively notifying the user of any problems with the upload. I'm currently working on version 2.5 and two key changes are planned.
First, I am instituting a confirmation feature into the app that will actually check to see if the user's data has been uploaded. If it has not, it will automatically try a second time to upload it. If that fails, it will notify the user that there is some sort of Internet connectivity problem and to please try again later. I've finished the programming of this and it seems to be working.
The "please try again later" message relates to the second feature. I will give the user the option to re-upload the data to any past Q sort. I've also finished the programming of this feature, but I'm now thinking that I need to make this feature a bit more nuanced. That is, I don't think I really want the user to be able to casually upload the data manually. For some reason, I envision users doing so repeatedly "just to make sure." That could really make a mess of my source data file on the web. My thinking right now is simply to have the app first check to see if the person's data is "up there," and if it is just to let them know all is well, thus preventing them from uploading a duplicate copy.
What's In Store for Version 3.0
I now have several month's worth of field trials under my belt with three different groups of people (in three different courses). I'm very happy with the progress I'm making, both with the app itself and with the pedagogy I'm inventing to go along with it. But, I see a big problem as I start to scale up implementation. Without going into detail, my current approach requires me to program a "new edition" for each new group that uses the tool, which obviously will become unwieldy as I scale up. I could solve this problem by creating a web-based database of user accounts, but I really want to avoid that. Why? Ultimately, I want to give this Q sort tool away to other instructors and I don't want them to have to be skilled at database management. I like the simple text file approach with FTP.
My thinking is to use the "Edmodo approach" where each new Q sort is defined and activated for the user with a special code that they have to input into the app. (Edmodo is a cool and free - my favorite combination - online learning management system that is quite popular with K12 educators.) I'll explain the strategy in more detail later if I decide to go this route, but suffice it to say that I could design a single app that would get all its data for a specific Q sort for a special group, thus allowing for unlimited sorts for an unlimited number of groups. The only consequence would be that the user would have to be given a random code to input to access each and every new Q sort. This approach seems to work OK for Edmodo and other apps, so it should work as well for me.
No comments:
Post a Comment