Hard Coding with an Eight Foot Piece of Pine Lumber

Well, the semester ended and the holiday season suddenly emerged around me. Handmade gifts are always the ones I enjoy receiving the most. It doesn't matter the quality of the item, only that the person has invested their time and focus on the receiver's behalf. My daughter, Rebecca, is the one who has given me the most beautiful and precious handmade gifts over the years. She is an accomplished professional artist, but she enjoys dabbling in most every craft. One Christmas she gave me a wonderful set of crocheted Angry Birds, which I proudly display in my UGA office. I still cannot bear to discard even a picture she drew for me when she was in third or fourth grade. I have tried to give some handmade gifts myself over the years, to varying degrees of success. But again, I think the people who receive them appreciate the time and attention they represent and - even if the quality is lacking - my intent.

Okay, you are probably asking yourself what all this has to do with learning LiveCode. Well, I have long felt the same sensation in building something with wood as I do when programming. And the key word here is "build." The part of my brain and psyche that is fulfilled by the act of building something is equally satisfied with wood or software as the finished product. I feel the same sense of euphoria and accomplishment as I build something in either medium. My skill in each medium is quite lacking, but that hasn't deterred me. I've given so much focus on building software over the past few years that it occurred to me that I needed to spend some significant time on a woodworking project. The brief holiday break leading up to Christmas provided a good opportunity.

Build: A Special Word

A little more about the word "build." Many other words are used for the act of actually giving a tangible form to a design. In my field of instructional technology, a favorite is the word "develop." I've never been too fond of this word for some reason. The current interest in MakerSpaces puts the word "make" at the center. I like the word "make." It conjures up the world of crafts and I've come to really appreciate and admire people who are serious in making crafts. For example, I've finally come to see the importance and value of making personal scrapbooks using paper, glue, and scissors. I find it both funny and sad that we all loved working with these materials as children, but somewhere along the way, most of us stopped because we thought them as too childish for adult pursuits. ("Put down" is an apt phrase here for both its meanings.) "Construction" is a word I've favored for almost 30 years. Indeed, I think Seymour Papert was wise to use it to describe his theory and practice of constructionism, which is simply learning by constructing, or - as I liked to describe it - learning by building. The word also conjured up its more serious philosophical cousin - constructivism. Discussing the "N" version vs. the "V" version of the word has filled many hours of my teaching. One thing I like about the word construct is that it is easy to imagine the person using a variety of tools, those both simple and sophisticated, while probably wearing a hard hat.

But, the word build is my favorite because I think of its relationship to working with wood to create projects used in our day-to-day lives. It's easy to imagine a carpenter or cabinet maker building something on a very personal scale. Our kitchens, living rooms, and bedrooms are full of things built with wood by skilled people. And, I've long used carpentry as a favorite analogy to building software projects. Many years ago, I wrote a book titled Getting Interactive with Authorware: Building Simulations and Games.

In the preface, I featured one of my woodworking heroes - Norm Abrams - to explain what a "project approach" was all about using the metaphor of woodworking:

The project approach simply means that one learns through building complete, stand-alone projects that are interesting and have clear goals and expectations. Good projects also have an easy-to-understand structure that makes sense at the start. Games and simulations make for good projects. One might say that this book was written much in the spirit of Norm Abrams on the American public television show “The New Yankee Workshop.” Norm is a master carpenter who shows his TV audience how to build from scratch a piece of furniture or other woodworking project. Norm always starts by carefully choosing a project worthy of the effort, often visiting American colonial sites for inspiration. Once he finds a suitable subject, he then builds the piece twice — once for himself (plus to show the audience at the start what the finished product will look like) and again in front of the camera. The design that Norm follows usually includes many changes from the original, mostly to keep the construction within the reach of the amateur carpenter at home.

Although TNYW is no longer in production, you can find all of the episodes on YouTube - here's a good one:

A Christmas Present for My Wife

My woodworking project was a special Christmas gift for my wife this year. I really wanted to push my current skills and develop some new skills. Most of my efforts over the years have been creating outdoor projects featuring mostly 2X4s. My projects have included a storage shed, a deck, a few picnic tables, several benches, two chicken houses, simple fencing, and some wooden gates thrown in along the way. If the project involved 2X4s with a fairly wide margin of error, I was your man. The challenge I gave myself this time was a piece of indoor furniture that my wife would find useful and beautiful. The margin of error now was very small. Finding the right piece of furniture was key. I checked out a bunch of woodworking books from the library - all included at least one of the words "simple," "easy," or "children." One book I really enjoyed reading was Build It Together: 27 Easy-to-Make Woodworking Projects for Adults and Children by Katie and Gene Hamilton. I loved the concept and especially the simplicity of the projects. (The photos were fun to look at as each featured a child building one of the projects with a parent.) Each of these books - even the simplest - contained knowledge and skills I did not have. So, similar to my learning LiveCode, each helped me to extend my own skills and knowledge just a tiny bit. And over time, it adds up.

Just as time was running out to build something in time for Christmas, I found the perfect project - a hallway bookcase that I found in the book The Complete Guide to Easy Woodworking Projects: 50 Projects You Can Build with Hand Power Tools, published by Black & Decker.

The design has those three essential elements proposed by the architect Vitruvius several thousand years ago - firmness, commodity, and delight. This bookcase is meant for the underutilized space of a hallway with a small footprint that tapers off toward the top, making it less likely to bump an elbow into it. I think the delight comes from the simplicity of the design and its well-balanced, visual form. Here's a photo of the finished piece:

I won't bore you with any more details, other than repeating that I experienced that same wonderful, satisfying feeling of building something special. And yes, it did involve several pieces of eight foot pine lumber - but not one 2X4.

I wish everyone a wonderful, healthy - and peaceful - 2017.

Lloyd Taking Inventory: What Have I Actually Designed in the Past 34 Years?

The fall semester at the University of Georgia is coming to a close. I taught two design courses this semester and am hunkered down reviewing student projects. As usual, I'm very impressed by the creative work of our students.  I've encouraged my students to try to think of themselves as designers, so I always try to model being a designer as part of my teaching approach. The great thing about taking on identities such as designer, writer, or even researcher is that you don't have to be great or even good at it. You just have to do it with passion and confidence. Indeed, the current writing on design thinking makes it clear that good or great designs usually only come once in awhile and only in the midst of a slew of other designs that never see the light of day.

With that as the context of this post, I've been trying to remember all of the major design projects I've been involved in during my career as a professional educator. These are the ones that rose to the level of good or useful and took significant time and effort to produce. Put another way, these are the ones that saw the light of day. Also, the only examples I include here are software design projects. So, I don't include the design of any of my classroom instruction or any initiatives in which I've been involved. For example, none of the +-10,000 or so PowerPoint presentations I've created qualifies for this list. As another example, about six years ago I was asked to build an initiative by a former dean of our college of education to try to engage faculty in innovative forms of instruction supported by technology. This was a major design effort on my part, but it is not included here because it was not software design.

Each of the software described below deserves a full and long explanation, but I'll obviously not do that here. My goal is simply to "take inventory" and provide a short description of each.

Serendipity (1982)

This was my first published software. Serendipity consisted of nine games and activities for elementary school children, most targeted at fifth graders, the grade I taught. The story of its creation is far too long to tell here. The short version is simply that I decided to learn Applesoft BASIC programming on my own on the Apple II family of computers. At the same time I was a brand new elementary school teacher. Fortunate for me, right after graduation from the University of Pittsburgh I landed in an elementary school in rural New Mexico who had a progressive principal who saw technology as the future of education. He found in me a willing participant in his vision of technology supporting teaching and learning. It was a wonderful time to be a teacher interested in technology, which I now refer to the romantic period of educational computing. That is, there were no rules, directives, mandates, or restrictions. I was free to experiment.

Of Serendipity's nine activities, here were the ones I was most proud of:

Mineshaft: This remains as probably my most successful game design, as judged by students' level of engagement and learning. It is an educational game for learning fractions through estimation. A miner left his miner's pick down in the mine and it was your job to go and fetch it. You competed against another player. The mine was actually a number line shown in a vertical direction. Each player entered a fraction, then their respective mineshaft elevator would be lowered to that level. The player who came closest to the miner's pick would see the pick get loaded into their elevator, taken back up to the surface and deposited on their side of the screen. The first player to win a certain number of rounds was the winner. The cool thing about this game was that you really didn't need know anything about fractions to enjoy the game. You could learn about fractions through discovery learning. Another cool thing is that you never worried about getting exactly the right answer. In fact, this was almost impossible to do. Instead, the game promoted the important skill of estimation.

Pinpoint: This was another game where the player learned about estimating mathematics. The game was really just a form of the classic guessing game where one person thinks of a number between, say 0 and 100, and the other person has to try to guess what it is. In this game, a picture of a radar screen appeared on screen. The idea was that the mystery number was located at the center of the cross hairs. As you took guesses, your "shot" was shown on the radar screen a certain distance away from the center. The closer to the center, the better your guess. This was another game that my fifth graders really enjoyed.

Waffle: This was a math game for two players that borrowed from the games of bingo and connect four. A 4X4 grid appeared on the screen. At the start of each round, each player would choose a "target number," such as 20. The goal was to take turns choosing to place an integer from 1-9 in one of the squares. If a row or column eventually added up to your target number, you won a bunch of points.

Estimation Baseball: This was another math estimation game for two players. The idea was very simple. Give the player a seemingly tough math problem, such as 439 X 675, with very little time to solve it. Let's imagine giving the student only 15 seconds with a beep every five seconds. Each beep signals a "strike." If you don't enter some answer (i.e. swinging the bat), you strike out. If you enter a number, it all depends on how close you estimate the correct answer of 296,325. Learning to quickly round each number to the nearest hundred would give you a much simpler problem of 400 X 700, which is 28 plus four zeros, or 280,000. This might result in a double or a triple. Get even closer and you hit a home run. But, estimates that are far off the mark result in an out. Shortening or lengthening the time between strikes is an easy to increase or decrease the challenge.

Professional Class Golf (1984)

This golf game remains my magnus opus. It was also designed for the Apple IIe and was programmed using BASIC. It was my second software package published. Interestingly, the publication of this game coincided with my transition from classroom teacher in New Mexico to doctoral student at Penn State. I have vivid memories of working on it in both places. (Note: I know there are DOS 3.3 emulators out there that will take old software programmed in Applesoft BASIC and allow the software to be played on modern Apple computers. Unfortunately, getting the code from the 5.25" disks to the Internet is a "bridge too far.")

Fig Newton (1985)

This was the software I designed for my dissertation research at Penn State. It involved a fundamental tutorial about Newton's Laws of Motion lasting about 45 minutes. My research topic was learning through visualization, specifically animation. I built a bunch of simple physics animations to accompany my physics narrative. I studied the difference between animated and static images. Fig Newton was designed using SuperPilot for the Apple II family of computers. Few people know about SuperPilot, but it was the preferred authoring choice at Penn State at the time. Despite knowing and greatly preferring Applesoft BASIC, I went with the flow and learned SuperPilot.

Fig Newton Redux 1 (1988)

After I graduated and became an Assistant Professor of Educational Technology at Texas A&M University, I decided to go back to programming with Applesoft BASIC. I reprogrammed my Laws of Motion tutorial in BASIC. I recall one motivation to do so was so that I could begin to include gaming and simulations within the tutorial. Although one could actually program the needed algorithms in SuperPilot, the execution was very, very slow to the point that it was unusable. And, it felt good going back to BASIC. I used variants of this software for my many research projects in the schools for many years.

Space Shuttle Commander (1990)

This was my attempt at putting into practice everything I had learned with my research. Space Shuttle Commander (SSC) included a series of games and simulations in the context of the player commanding the space shuttle. All of the tutorials I had created became available as student resources, creatively rebranded as "flight school." I was very proud of SSC, particularly because NASA agreed to publish it within their Educational Technology division. The software was given away for free to all interested teachers.

Fig Newton Redux 2 (1992)

I'm actually amazed how long the Apple II family of computers remained viable in the schools. But, eventually, the inevitable happened and the Apple II family was replaced with Macintosh or Windows computers. I think it started to happen in earnest around 1991. I had begun learning a new authoring tool called Authorware a few years earlier. Gaming and simulation software created with Authorware in the early years ran very slowly, similar to SuperPilot, but due to advances in the Mac platform eventually the speed became satisfactory and I made the jump from BASIC to Authorware. This happened about the time I moved from Texas A&M University to the University of Georgia in 1993. I again programmed many different variants of my laws of motion tutorial, games, and simulations for use in my research agenda at that time.

The Rogue Refrigerator (1995)

For awhile I focused attention on the relationship between distance, velocity, and acceleration as the learning topic within my research agenda. If you know anything about physics, you know this is among the most fundamental set of principles in physics. Indeed, the history of physics more or less began with these ideas. Some historians point to these principles as the first serious examples that gave rise to the invention of calculus. One example of a game and simulation combination involved an activity in which just the graphics - and hence the context - of the simulation changed. For example, we had the ever-popular spaceship example with an engine accelerating it faster and faster. But, another example used a graphic of a refrigerator being pushed by one or two people (they resembled twins). The idea of a fridge on the loose really struck the fancy of the research participants, though in the end this example produced the least effective learning. But, it was fun to play.

Nowhere Road - The Game (1999)

Our program at the University of Georgia changed the design of our masters curriculum to focus on a studio approach to learning. This included sharing one's design prototypes as they were developed with one's design community for critique, while also journaling about the design. Again, in the spirit of modeling all this I designed Nowhere Road - The Game, which involved the adventures of a mild-mannered professor who bicycled to work most days. Along the way, he had to deal with mean dogs and impatient drivers. The game also tried to teach the benefits of safe cycling. I again used Authorware to design this. Fortunately, the journal I kept is still available.

Project Shop (2000)

Project Shop was a federally funded to help people with mild to moderate intellectual disabilities. Video and interactive software was developed in the context of grocery shopping. The grocery store is an interesting place, both cognitively and socially. There are so many opportunities to build many forms of literacy and to learn socially accepted behaviors. Having a dually-diagnosed son with autism, I learned early how difficult the grocery store was for him to figure out. The grant allowed us to produce some very fun, motivating videos that became "anchors" for a variety of activities found on an accompanying CD. I can claim only a portion of the design effort that went into Project Shop. The credit goes to the entire team, which included Dr. John Langone and Dr. Thomas Clees, special education faculty and colleagues of mine at UGA. We also had some outstanding graduate assistants, included Michael Matzko. Mike was one of the most talented software designers I've ever had the pleasure to work with. The topic of Mike's doctoral dissertation was the design of the Project Shop software. We used Authorware to build the software which, unfortunately, makes all our excellent work inaccessible. Very sad irony.

WWILD Team (2000)

Around 2000 I became very interested in designing online learning environments. I began to learn about how to build databases for use in dynamic web sites. I learned how to program Active Server Pages (ASP) using a simple Microsoft Access backend database. The WWILD team was my first large project. WWILD stands for "World Wide Interactive Learning Design" team. I envisioned the entire world acting together as type of organized design effort. Interestingly, the WWILD team anticipated the rise of learning objects because the site promoted the compilation, curation, and review of interactive learning "modules." Yes, I had high hopes for this site. The site remains active and functional.

Lloyd's Personal Learning Management System (2002)

The early examples of learning management systems (LMSs) were very crude and I was very disappointed in them. So, I decided to make my own custom LMS for various courses I was teaching to use an alternative. I built a rather clever design using ASP and Microsoft Access which allowed me to early create new sections of the course for use with new students in subsequent semesters. It proved popular enough that many of my colleagues at UGA asked to use my system when they were tapped to teach these courses. This online system still works, but I stopped using it about five years ago when UGA finally adopted a more robust LMS.

Graduate Degree Portfolio Management Site (2005)

For many years I was graduate coordinator or department head or program coordinator, or a combination thereof. One of the most confusing tasks was managing graduate student portfolio meetings. Many people have to be consulted just to schedule one. Then, it becomes a game of reminders to make sure everyone shows up at the right time and the right place. So, I solved this problem by building a management site for all of the graduate student portfolios. The site doesn't contain the portfolios themselves, just links to them, along with committee members and room numbers. The web site also manages the approval and completion process as each portfolio undergoes several reviews. This has been one of my most successful projects and in the end saved a lot of people a lot of time, especially me.

In Search of Lost Wisdom (2006)

This was special activity I designed for my online teaching of instructional design to help me teach task analysis. I built this activity because, frankly, I was dissatisfied with my teaching of the task analysis unit. I didn't like teaching it and, not surprisingly, my students didn't like learning it. I had been touting the advantages of game-based learning, so I decided to practice what I had been preaching by designing a game to do the teaching for me. This is now one of my and my students' favorite parts of the course. This was also designed with ASP and was added to my custom-built LMS for the instructional design course. (Note: I also built a public portal for my LMS, which required quite a bit of effort. It's been used by about a dozen or so instructors in the USA. It still works. In fact, I used this portal myself this semester to run the game during one of my courses. It worked great and students seemed to really like it.)

Project Promote (2006)

One of the cool tools I built for my custom LMS was a question & answer (Q&A) tool to allow all questions asked by students to be archived and then searched later by them or future students. It worked pretty well. I presented this tool to a group of faculty and administrators in the Office of the Vice President for Instruction at UGA and it generated some interest. An interesting design emerged from these conversations to build a Q&A-type tool where assistant professors could ask sensitive questions posed to a group of senior faculty. The VP gave me a little bit of money to hire a graduate student to build this online tool. I thought it was a great idea, however, the tool just never took off. It was that case of "we built it, but they did not come." Too bad.

Catch Sunny (2011)

This was my first serious LiveCode project. I was working on a large grant meant to support people with disabilities transition from school and home into independent living in the community. This app was meant to help the team understand the ability of people in the target audience to use and interact with the small iPhone interface. Sunny is one of my pet dogs. I randomly put a picture of Sunny on the screen and the task was to click on Sunny (i.e. catch him) as quick as you can. If successful, the size of the icon of Sunny was reduced a little bit. If errors began to occur, then the icon's size was enlarged. The app tracked the user's success and error rate. It also tracked where errors were occurring. I also used this project to learn how to build a native iOS app for the iPhone. This was my first app that appeared in the iPhone App Store.

Lunar Hotel Shuttle (2012)

This physics simulation game was the original inspiration to start this blog, so click here to read more about it.

Statistics in Education for Mere Mortals (2013)

I entered the MOOC world in 2013 by proposing, then building a MOOC to help instructional design professional in particular, but really anyone, learn and use fundamental statistics in their work. I've taught this MOOC eight times, with a regular schedule for future offerings (a new section begins every February and July). The fundamental software design for this MOOC is a series of videos that revolve around each participant building their own Excel spreadsheets from scratch. We start with computing the mean and standard deviation, and end by computing an Analysis of Variance (ANOVA). All of the videos used in the MOOC are available on YouTube.

PersuadeMe (2013)

PersuadeMe is an interactive web site that promotes learning how to write evidence-based argumentation. The design of PersuadeMe was a group effort, but I led the design effort and also was the programmer for the team, building the site using HTML, PHP, and MySQL. We received a very small grant of $25,000 to build the prototype, but this funded only a small portion of the time needed to build the site.

Lloyd's Video Analysis Tool (2016)

I've blogged extensively here about the design of this app. Here is a last blog post I published about this app.

Lloyd's Q Sort Tool (2016)

I've also blogged extensively here about the design of this app. Here is a link to my first blog posting about it.

Closing Thoughts

As I wrote in the opening section, most designs never see the light of day. A good example of this is the fact that I have designed and written about 31 unique projects in this blog since I began it in January 2013, almost four years ago. However, of these I include only three in the list above - Lunar Hotel Shuttle, Lloyd's Video Analysis Tool, and Lloyd's Q Sort Tool. But, that's OK because each of the projects contributed in some small way to my overall understanding of LiveCode and consequently to the design of these three projects.

As I reflect on the list above, I wonder about many things. What exactly does this list represent? Although this blog post seems long, one must remember it represents 34 years of my professional life. That fact makes the list seem very, very short to me.

Finally, I keep an old Apple IIe in my office and every now and then I power it up to play some of my older software. Of all the software I programmed for the Apple IIe, the one I play first - and usually the only one play - is Professional Class Golf II Pebble Beach. Even with the old graphics, simple sound effects and keyboard only input, I still think this is a fun game. Good design, like good music, stands the test of time.

Giving Thanks to the LiveCode Community For Their Help in Solving a Pending Messages Problem

We Americans are about to enter into the long Thanksgiving holiday weekend, so it is time for me to pause and reflect on all of the reasons I have to be thankful. There is much on a personal level I could mention, but given that this blog centers on my professional life, I wish to give thanks to the wonderful LiveCode community. And, the topic of this post is definitely in the spirit of my blog's title - learning LiveCode.

Recall I had been experiencing a strange speeding up within a little physics simulation/game I had created back in July. This problem baffled me, so I decided to post a note about the problem within the HTML5 LiveCode Forum. Two longtime LiveCode users, Hermann and Bernd, quickly responded. Each immediately zeroed in on the cause of the problem. My looping strategy has a major flaw in it. It creates a build up of pending messages. Each one restarts the loop, resulting in a sort of amplification effect. Instead of only one loop being in control at all times, multiple loops are created with each having an effect on the speed of the simulation. Through their kind assistance, Hermann and Bernd helped me to understand a little better the nuances of the pending messages feature in LiveCode. For more details, I've included below a copy of my post to the LiveCode HTML5 Forum along with the replies from Hermann and Bernd.

My physics simulation now runs great on all platforms, including HTML5. Click here to check it out for yourself. (The download takes awhile, so be patient.)

Knowledge Transfer: Solving a Similar Problem in My Q Sort App

Most of my time over these past two months have been devoted to work on my Q sort app. I will post an update on that project soon, but I believe a problem that only Windows users had been experiencing is also related to this pending messages problem caused by my looping strategy. I haven't been able to test the new version of the Q Sort app thoroughly yet, so I'll withhold judgment until later if this is, in fact, the cause of the problem. But, I definitely was executing the looping strategy incorrectly in the Q sort app, so fixing it can only be a good thing.

This is just a nice example of how increased understanding of a problem in one LiveCode project - even a toy project - can be used to solve a problem in another, more serious, project.

A quick side note: Last week I gave a presentation at the E-Learn 2016 Conference in Alexandria, Virginia, about my Q sort research project. I think it went well. Most satisfying was the fact that no one in the audience had ever heard of the Q methodology. I like being the one to first alert people to this very interesting way to study subjectivity.

Final Thoughts

I like to tell people that Thanksgiving is my most favorite holiday of the year, with July 4th coming in a close second. Thanksgiving is all about family and July 4th is all about community. Also, we have yet to figure out a way to commercialize these two holidays. (Yes, the encroachment of the Christmas buying season on Thanksgiving has been a problem, but even that is finally beginning to be rolled back.) But for academics - faculty and students alike - Thanksgiving also provides a well-timed moment to both catch our breath and catch up. This post is a good case in point. I actually began writing it in mid-September. The past two months have been very busy and hectic. So, it is nice to finally give thanks publicly to Hermann and Bernd.

Finally, take note of the last paragraph by Bernd. He cleverly found a way to "hack" my little game, something I'll be sure to patch up if I continue working on it.

Postscript

I'm mindful of the fact that the Macy's Thanksgiving Day Parade may be the greatest example of commercialism. But hey, it's an American tradition!

---

My LiveCode Forum Post

Strange Speeding Up in the Execution of a LiveCode Project

I wasn't sure the best forum to submit this to, but given that the problem I describe below occurs when I export to HTML5, I thought I would start here.

I've created a little physics simulation/game I call "Thread the Needle" to show the relationship between distance, velocity, and acceleration. I'm used LiveCode 8.1 on a Macintosh. It works great when I run it as a standalone for the Mac, but when I export it as a standalone for Windows or HTML5, something odd happens.

Everything starts off fine. The simulation and game work just as expected. But, the program starts to speed up inexplicably with each new game or simulation try. It is important to point out that each new try begins with an "opencard" command. The program only consists of a single card. I put all of the opening scripts on the card script including a bunch of custom functions I created. This includes the main "loop" function that controls the simulation/game:

 on mainEventLoop  
   if varRun is true then  
    checkGame  
    physicsEngine  
   end if  
   send mainEventLoop to me in 50 milliseconds  
 end mainEventLoop  

The procedure "mainEventLoop" is originally called in the opencard script.

For the HTML5 version, if I choose to reload the page the program again works fine for the first try, but then it predictably speeds up in each successive try.

The same phenomenon occurs when I run the Windows standalone version. If I quit and relaunch the Windows standalone, it works just fine for the first try, but then the simulation/game gains speed with each successive try. It's as if the computer's processing power magically increases each time. (Given that mainEventLoop calls itself every 50 milliseconds, I would think this would create it's own speed limit.)

But again, all works fine if I stick to the Macintosh. So, this leads me to think the code is working properly, but that there is something uniquely odd with the Windows or HTML5 execution (at least when the program is built on a Macintosh).

If you want to run the program for yourself to see what I mean, here is the link to the HTML5 version of the project:

http://lrieber.coe.uga.edu/livecode/html5/lloyd_physics_game/index.html

I also made a video demonstration of the simulation/game for use in my teaching at the University of Georgia, in case you just want to get a sense of how the program works. (This video was made using only a Macintosh, so the problem described above doesn't occur.)

https://www.youtube.com/watch?v=oJeXRvmT5QI

I'm guessing (hoping) that others have experienced this phenomenon also and might be able to share some insights as to what is happening and, more importantly, how to make the problem and to have the simulation/game run smoothly.

Thanks.

Lloyd Rieber

---

Re: Strange Speeding Up in the Execution of a LiveCode Project

Postby [-hh] » Sat Sep 17, 2016 8:55 pm

Hi Lloyd,

you could try to cancel the current loop before starting a new one.

This should work on each platform and especially in the HTML5 standalone.

   on opencard  
     ...  
     repeat 2 -- cancel current mainEventLoop  
       repeat for each line L in the pendingMessages  
         if L contains "mainEventLoop" then cancel item 1 of L  
       end repeat  
     end repeat  
    //Begin  
    mainEventLoop  
   end opencard  

[Probably the Mac IDE holds, without the above cancelling, the additional mainEventLoops in a long row and absorbs them later on because the simulation needs more than the 50 millisecs of the loop's refresh.]

Hermann

p.s. Great stack!

---

Re: Strange Speeding Up in the Execution of a LiveCode Project

Postby bn » Sun Sep 18, 2016 4:44 am
Hi Lloyd,

I agree with Hermann that the messaging seems to be the problem.

   on mainEventLoop  
     if varRun is true then  
      checkGame  
      physicsEngine  
     end if  
     send mainEventLoop to me in 50 milliseconds  
   end mainEventLoop  

here you send "mainEventLoop" regardless of what happens, whether you show a dialog and so on. That is not necessary and piles up messages.
I tried to fix this by

   on mainEventLoop  
     if varRun is true then  
      lock screen  
      checkGame  
      physicsEngine  
      unlock screen  
     end if  
     put the pendingMessages into tMessages  
     repeat for each line aLine in tMessages  
      if item 3 of aLine is "mainEventLoop" then cancel item 1 of aLine  
     end repeat  
     send "mainEventLoop" to me in 50 milliseconds  
   end mainEventLoop  

It effectively keeps the "mainEventloop" messages from piling up and it runs nicer in HTML5.

Note that I put a lock screen/unlock screen pair around checkGame and physicsEngine. You do a lot of screen updates in your handlers like graphics and fields. That is costly and can be avoided by locking the screen.

Furthermore your mainEventLoop does not have to run when the game is not actually running e.g. showing dialogs. I would move " send "mainEventLoop" to me in 50 milliseconds" inside the "if varRun is true" condition.
That needs a little more coding regarding varRun setting to true and false and when setting it to true to start the "mainEventLoop" again but saves a lot of processing cycles and then it does not interfere with the rest of the application.

My strategy to get some points was not to touch the arrowkeys at all. Then at least I did not have a negative score and at times I even hit a marble when it happened to be close enough to the middle line. :)

Kind regards
Bernd

Lloyd's Physics Simulation, Prototype 2: Thread the Needle Game

Zipped Standalone Download: Macintosh | Windows
Download files updated September 13, 2016
HTML5 Version

Over the past week or so, I returned to work on my little physics simulation that I built and wrote about a couple of months ago. This little prototype has constantly been on my mind and I've been playing it rather frequently since I wrote my original post about the prototype on July 4, 2016.

Recall in that post I wondered about a game element that could be added to it: "...I can imagine having targets placed within the area of the line graphs that you have to try to hit with one of the graph lines." Yes, the more I played the simulation, the more I liked this idea. So, I've spent about 6 hours working on the next prototype that includes this gaming feature. I call the game "thread the needle" because that is exactly what it reminds me of - the blue distance graph seems like a piece of thread that I'm trying to maneuver to pierce (thread) the target (eye of the needle). Here's a screen shot of the game:

A Quick Demonstration

Probably the best way to understand how the game works is with a short video demonstration:

Ok, let's explore the game a little further.

Goal and Rules of the Game

The goal of the game is, of course, to learn about the relationship between distance, velocity, and acceleration. But, we should probably keep that a secret because this fact might ruin the game for any elementary, middle, or high school student who plays it. But, as one adds game elements to a simulation that already appropriately models the physics, you have to be careful that the attractiveness of the game doesn't inadvertently detract from the learning of the physics. The physics can be considered the underlying model of the simulation. In a discovery-oriented learning environment, the goal is for the student to "discover" for themselves the rules of this model. If the simulation was sufficiently motivating to explore, no game would be necessary. But, alas, the simulation itself is rather boring for most people who are not already physics geeks. My ambition is to invent a game that turns people who play it into physics geeks. Yes, I dream big. So, let's keep this ambition in mind as I explain how the game works.

I really like how my simulation graphs the quantities of distance (traveled by the marble), the velocity (speed - aka the change in distance - and in what direction) of the marble, and the acceleration (change in velocity and in what direction) of the marble. As I played the simulation, I found myself mostly focusing on the distance graph, while also keeping an eye on the acceleration graph. Interestingly, I pretty much ignored the velocity graph. Not sure why, but that's what I found myself doing. Perhaps your play experience will be different.

Interestingly, I also ignored the numeric readouts just above the graphs. If the graphs are hidden, one could use the numeric readouts to also figure out the location and motion of the marble. But, I must admit I completely ignored this information as well. I find this particularly interesting because I have done research in the past where I compared the use of numeric data, such as these, to visual data in similar physics activities. But, let's not go there right now.

So, I thought my original idea of putting various targets in the graph area to "shoot" with the distance graph would make a rather interesting game. I try to avoid war or violent metaphors if possible, so I'm much happier with the "thread the needle" metaphor, and I think it works quite well. I think the threading metaphor actually describes the experience much better than the concept of shooting.

The Target: The Eye of the Needle

I kept the design of the target simple - a blue circle. I thought it made the most sense to color code the target to match that of the distance graph. Obviously, the larger the target, the easier the task. So, I wrote a script that assigned points to the target that match the size of the target. The size and vertical location of the target are chosen at random. I keep moving the target to the right on the graph area as the graph grows. So, the goal of the game is just to "pierce" the target - thread the needle - with the distance graph. Doing so earns the player the number of points associated with the given target.

Game Elements that Promote Learning

I think the game is pretty good, but I noticed a problem. It becomes pretty easy to hit the target if you press the acceleration buttons with reckless abandon. I think doing so also detracts from the learning of the relationship between distance, velocity, and acceleration. So, I wanted to temper this tendency to just go click happy. Consequently, I added a small penalty each time one of the acceleration buttons is clicked, which I (tentatively) called "maneuvers." The penalty is only 5 points, but this can up quickly if you go click happy. I also reward the player for finishing the graph by awarding some bonus points. This makes one more mindful of the rate of change of the distance graph, which of course is related to the change of velocity, which is what the acceleration buttons control. There is an interesting tension in the game now. One's tendency is to click wildly when you get close to one of the edges, but of course this comes with a penalty. Yet, the bonus points helps to offset that. So, I found myself wanting to absolutely finish a graph, while being careful to use all of my clicks wisely. For now, I don't penalize the player for missing a given target, but that has crossed my mind as another game element to add. I think the loss of points for missing a target is in itself a penalty.

An interesting question when it come to assigning or deducting game points is just how many points to use where and when. This is always a difficult thing to gauge. The goal, of course, is to enhance the game play. The only good way of deciding this is to play the game and to observe other people playing the game. Interestingly, once you find the sweet spot for the first level or round of the game, you can use all these parameters for increasing or decreasing the challenge of the game for subsequent rounds.

Other New Design Elements

As I worked on this second prototype, there were a bunch of other small design features that I included. Here are the most notable:

• I included a way to speed up the game play by allowing the user to change the horizontal step size of the graph. This complements the existing option of changing the default increment of the force of acceleration that I designed in the first prototype. Changing the horizontal step size is a very cool option because it changes the game play quite a bit. There is a faster pace to the game when the step size is increased, which adds to the excitement of the game, but it makes the game more difficult.
• I added simple sound effects at various critical moments: when a target is threaded or missed; when the player completes the graph; or when the marble rolls off the edge before completing the graph.
• When the game begins, I added some scripts to make sure the target was not overlapping the x axis. I wanted to be sure the player had to make some maneuver to begin to earn points. Similarly, I made sure that the target is not initially placed either too high or too low at the start of the round as I thought that would be a cause of frustration.

Next Steps, Though Not Likely

The game only consists of one round. If I continue to work on this simulation/game, an obvious thing to do next would be to add additional rounds with increasing challenges. Another idea is to leave a "ghost" image of all targets on the graph. I think this would be very useful in coming back and debriefing the player's game performance for that round, particularly in a conversation with a "more knowledgeable other" or MKO - to use a famous term by Vygotsky in his social constructionism theory. The teacher is an obvious MKO, but probably a more significant MKO to a player would be a peer who has achieved higher scores (but not too much higher).

But, to be honest, I don't think I'll be working much more on this game as I have achieved my original design goal of creating a simulation/game for use as an example in my teaching of design at the University of Georgia. But, if I can coax some physics teachers in some nearby high schools to use the game in their classrooms, and it proves to be somewhat successful as a learning tool and a fun game, then I might be motivated to continue working on it. I'll bet the students will have all kinds of ideas and recommendations for revising and improving the game. That would definitely "accelerate" my motivation to keep working on the game.

PostScript

I had the students in my doctoral design course download and try out the app. On some of the computers - all Windows I think - the simulation ran incredibly fast, much too fast to play. So, I have modified the option to calibrate the horizontal step size in one tenth increments between .1 and 1. Above 1, I kept the increment in whole numbers. I hope this helps. I've updated the download files accordingly (links are at the very top of this post).

This is an interesting design problem given that the simulation speed is ultimately tied to the processing capabilities of the computer on which it is run.

Update on the PostScript (September 18, 2016)

I submitted this problem to one of the LiveCode forums. With help from more experienced LiveCode programmers, I think I now understand the problem and it is not due to a Mac vs. Windows issue. Instead, it appears the problem is rooted in one of my simulation's scripts. I will post a separate blog post about this after I explore the problem more thoroughly based the advice.

Getting the Word Out: Building an Email Checker App with LiveCode to Remove Multiple or Bad Addresses from a Long List of Emails

For the past three years I've been teaching a MOOC about introductory statistics. In total, about 5800 people have enrolled. I've also been doing some research on MOOCs with this course as well. I'm happy to report that an "early view" of a research article I wrote is now available online through the British Journal of Educational Technology. Here's the link and citation:

http://onlinelibrary.wiley.com/doi/10.1111/bjet.12504/full

Rieber, L. P. (2016). Participation patterns in a massive open online course (MOOC) about statistics. British Journal of Educational Technology. doi:10.1111/bjet.12504

(After the print version article is published, the citation will change to include the volume/issue and page numbers.)

Yes, this is great news, and my family - usually my only readers - are very proud. (Some people have spread a rumor that I hold nightly, mandatory readings of my research articles in my house. That's simply ridiculous - I stopped doing that years ago.) However, I do want to alert the people who enrolled in my MOOC over these past three about this article because it's really because of their help and support that I was able to do this research. Fortunately, I have all of the emails of every person who ever enrolled in the MOOC. So, I could just put all of these emails into a gigantic list and "bcc" them in an email with the information about the paper. And that is exactly what I will do.

But, although it is true that over 5800 people enrolled at one point or another, a good number of these enrollments were the same people. Some started the MOOC and didn't finish, but came back the next time it was offered to work on it some more. Some did this several times. So, I don't want to send two, three, or more copies of the same email to a person. That's a good way to really get someone angry, and I've spent a lifetime trying to avoid angry people (with only mixed success). Ok, simple enough - just check the list and remove any multiple entries. But, good golly, doing so manually with a list of 5800 would be a tough task and I would likely make many mistakes even if I tried. So, once again it's LiveCode to the rescue. I quickly built a simple app that scans a given list of emails and removes all of the duplicates. I also added the feature to subsequently have it scan a list of "bad email addresses" - those that bounce back for whatever reason. That way, I can refine the list to only those emails that actually work. The result is an edited list of email addresses that I can use - judiciously - to send other announcements to these people that I think are useful and would be warmly received.

The Email Checker App

Here's a snapshot of the ugly, but functional main card:

Yes, pretty ugly. But hey, I built this app quickly - an hour or two at most - for me to do an important job. No need to make it pretty. But, there is usability in the design. The red text are the directions I wrote to remind myself about how the darn thing works. I actually built this app about a year ago and knew at the time I wouldn't need to use it very frequently. Knowing how short my memory is, I was careful to write in the instructions so that any idiot - well, a specific idiot - could know what to do after opening the app. As anticipated, it is only now that I have another email that I think is worth sending to this group. I'm now very grateful to myself that I wrote those "notes to self" - hmm, am I being "self"-ish?  

How the App Works

After pasting in the list of emails into the far left field, there are three simple steps to cleaning the list of duplicates and non-email addresses:

1. Sort the list. This puts exact copies of multiple emails sequentially in the list.
2. Check for duplicates. This simply compares each line in the field with the one after it. If the two are a match, a bell rings and the email is deleted from the field on the left and placed in the field on the far right. I realized that if there are more than two duplicates in the list, then this step would need to repeated until all duplicates were found. I was rather lazy here because yes, I could have programmed the matching algorithm to just keep going if it found a duplicate. That is, if it finds one duplicate on the next line, then it should continue the comparing the next line with the same email. At some point, I may make this modification, but for my purposes, it's easy enough just to run step 2 as often as I need to catch all the duplicates.
3. Check for the @ symbol. Finally, I found the occasional email entry that wasn't actually an email address. So, I added a step that checks each email for the @ symbol. Obviously, without this symbol, the email would not work.

Purging Bad Emails from the List 

After I send the email out, it is inevitable that some addresses won't work. Perhaps the person entered the email address incorrectly when they created their MOOC accounts, or they deleted the email account after the MOOC was over. Either way, I manually keep track of all emails that bounce back to me, then paste that list into the middle field on this card:

The end result is a nice, clean list of working emails.

Final Comments

I take very seriously the responsibility of having such a list of email addresses. I would never, ever consider giving or sharing this list with anyone. I don't know about you, but I am very hesitant of giving out one of my "good emails" to any group or organization because I'm always suspicious that my email will be sold or used for marketing purposes. (And yes, I do have some "throw-away" emails that work, technically, but I never check them. God only knows how much spam they have accumulated over the years.)

So, if you ever join a future section of my MOOC, please know that your email is safe with me. But, I hope you won't mind getting an email two or three times a year from me with information I think you really might want to have.

I Aspire to Be a Second Rate Designer

My goal in this essay is to confront the unfortunate rhetoric that pervades most professional careers, namely that our goal should be to be the very best. Of course, taking any alternative position is a precarious place to occupy, because one would be subject to the criticism of being a slacker, or someone who is satisfied with mediocre work. I stand in neither of those places, but I am very pragmatic and realistic about my abilities and aspirations. As I have worked with both faculty and students at the University of Georgia about designing learning experiences and environments, I've seen too often the paralysis that can occur with just the thought that one's work is no good. I especially want my students to take on the identity of "designer," but this is something many resist. They feel they don't yet quality for such a title. My position is simply you are a designer or you can be a designer by choosing to do so.

The inspiration for the title of this essay comes from a comment I remember Steve Jobs making about Microsoft products. My memory was that he called them, as a whole, second-rate. As it turns out, my memory was kind to Microsoft because Jobs actually called them third-rate:

I guess I am saddened, not by Microsoft's success – I have no problem with their success, they've earned their success for the most part. I have a problem with the fact that they just make really third rate products. (1996) [citation]

I remember thinking at the time how I wish I could design software as good as that sold by Microsoft. Second-rate in this context seemed like an excellent aspiration. Yes, I long admired Steve Jobs' pursuit of perfection and remain very inspired by the excellent products and software produced by Apple. But, his vision within an environment of very talented (and well compensated) people is not one that I can put into practice myself.

Consider the following saying, attributed to Voltaire: "Perfect is the enemy of the good." I first heard this a long time ago in the context was that we should never be satisfied with something just being "good enough." Instead, we should strive for perfection. (An essay by Charles Osgood on being "pretty good" makes the same point.)

In contrast, I interpret this quote in exactly the opposite way. I view the strive for "perfection" as a debilitative or paralyzing state that usually results in a person either not trying at all or just giving up. And, apparently, Voltaire agrees with me, if you can believe the Wikipedia entry.

A more modern version comes from Sir Robert Alexander Watson-Watt, a pioneer in the development of radar during World War II: "Give them the third best to go on with; the second best comes too late, the best never comes." Given the war context of this quote, I can easily imagine the sense of urgency to just get on with it and stop all sniffling about it not yet being good enough.

Design Thinking

I've read a lot of the "design thinking" literature over the past couple of years. A really good book that I use in one of my doctoral design courses is Creative Confidence by Tom Kelly and David Kelly. Here is a link to a great TED talk by David Kelly about this. Here a few good quotes from the book about the potential for everyone to be a creative designer:

"One prerequisite for achieving creative confidence is the belief that your innovation skills and capabilities are not set in stone. If you currently feel that you are not a creative person – if you think, “I’m not good at that kind of thing” – you have to let go of that belief before you can move on." p.30

 On Bandura's concept of self-efficacy:

“Doubts in one’s creative ability can be cured by guiding people through a series of small successes. And the experience can have a powerful effect on the rest of their lives.” p. 40

 On the failure paradox:

“A widely held myth suggests that creative geniuses rarely fail. Yet … the opposite is actually true: creative geniuses, from artists like Mozart to scientists like Darwin, are quite prolific when it comes to failure – they just don’t let that stop them.” p. 40

 On permission to fail:

“…you can get better faster at coming up with new ideas if you give yourself and those around you the leeway to make mistakes from time to time.” p. 49

And finally a good reminder that creativity is an innate human characteristic:

"We forget that back in kindergarten, we were all creative. We all played and experimented and tried out weird things without fear or shame. We didn’t know enough not to. The fear of social rejection is something we learned as we got older. And that’s why it’s possible to regain our creative abilities so swiftly and powerfully, even decades later." p. 6

Me and My Accordion: Love Unrequited

And yes, this is an actual photograph of my accordion!

I think a good way of thinking about this issue is by analogy to writing or music. Just as many resist taking on the identity of designer, people are likewise hesitant to assume the mantle of writer or musician, even if they have been keeping a diary or journal for years, or have long enjoyed playing a guitar or other instrument as a hobby. Many feel the identity of writer or musician is reserved for those special few who have achieved success or acclaim.

Allow me to tell you a little story about me and my accordion. My story mirrors the classic Greek theater experience in that it contains both comedy and tragedy. In the last 30 years or so, I've focused solely on the comedy. I'm the guy at the meeting who says, "I'm not sure that's a good idea, but hey, I play an accordion, so what do I know." But, there was a time when I thought I could be a good, even great, musician if I just practiced hard enough.

I took accordion lessons for four years from the age of about 8-12 from the truly great accordionist Steve Seventy - a legend on the Southside of Pittsburgh who unfortunately died in 1988 at the young age of 61. (His name is not pronounced "70" by the way, it is pronounced "se-VEN-tee".) I paid for these lessons myself with my paper route earnings. I stopped taking lessons at about the time I started high school because practicing had long become a chore, not a passion. But, around my junior year of high school, I regained an interest in music and thought to myself that if I practiced long and hard, I could be good. After all, that was the rhetoric I had heard - you can do anything you want if you just try hard enough. I also tried to conquer my fear of performing in public by actively looking for opportunities to play at my high school and church for various occasions. I really tried to be good. The problem, however, is that I was and am a terrible accordion player. I'm missing whatever gene is needed to be musically skilled. My greatest triumph in playing the accordion was when I was a public school teacher and played for my elementary school students. They didn't care if I good or bad, they just loved the fact that they had a teacher who owned this amazing contraption and something resembling music came out of it when he strapped it on.  I take great satisfaction in thinking that these kids - now in their mid-40s - likely think back fondly to that one teacher who played an accordion. I bet that's one of a handful of things they do remember with a smile from those years.

So, yes, I am a musician, though a poor one. But, I am a better person by having made the attempt. And, making a joyful noise is a noble and honorable endeavor.

Me and LiveCode: 35 Projects in about 40 Months

In my own design work, I know I'll never attain the status of a great designer. But, I love to design and don't want anything to interfere with that passion. I still see the status of a second-rate or even third-rate designer as an aspiration and high achievement. I would only be a step or two away from being a first-rate designer, which would be a tremendous accomplishment.

I actually date my first experiences as a "real" designer to those same years as a public school teacher when I learned how to program in BASIC on the Apple II computer. I actually published two software titles back then. One was a compilation of educational games titled Serendipity, with the most successful being a game to teach fractions titled Mineshaft. The second was a golf game titled rather pretentiously Professional Class Golf. This golf game remains my magnus opus and I keep an old Apple IIe in my office so I can play it occasionally.

Writing this essay gave me some reason to pause and reflect on my experience these past few years learning LiveCode. Using January 1, 2013 - the launch date of this blog - as the starting point, I've designed about 35 LiveCode projects in about 40 months, just about all of which I've written about in this blog. The projects have been big and small, though mostly small. Very few are worth more than the virtual ink I've used to write about them, but that is beside the point. I'm a designer because I design and build.

A collage of "first rate" designers resulting from a Google search of "great designers." (Genius, I know.) A special tribute to Steve Wosniak, one of my personal heroes. "The Woz" gets much too little credit for his contributions to the culture of Apple, in my opinion. I always highlight Frank Lloyd Wright because, well, his middle name is "Lloyd."

Final Thoughts

So, it is with courage and conviction that I hope everyone will replace any aspirations to be the top "anything" in their field with simply being the best you can be, knowing that you will improve only by doing something. This means that you will do your very best, but realize that when you are judged against the best in your field, you will likely not stack up too well. And that's OK. So, instead of striving to be a sport's MVP, strive just to make the team. Become a writer not to make a million dollars with a best-selling novel, but to express yourself or to communicate well with your colleagues and friends. Instead of producing the world's next killer app, design something that will help just a few people in some small way.

Trying to be the best you can be will make you want to try to do things you never did before. The key idea here is that you, and you alone, will be the judge of your success. If someone else judges you and criticizes you, you will know whether or not you did your best. You should accept the criticism, perhaps with an ear or eye toward something useful in the person's feedback. That is, instead of feeling "destroyed," you should be open to some information that will improve what you've already done. This is a very empowering and liberating feeling.

And, if you think your ideas are so obvious as not to have any worth, then check out this video by Derek Sivers:

Reference

Kelley, T., & Kelley, D. (2013). Creative Confidence: Unleashing the Creative Potential Within Us All: New York: Crown Business.

Postscripts

1. I gave a presentation with the same title as this essay on August 19, 2016 at the 3rd annual IDD@UGA Conference in Athens, Georgia.

2. It also just occurred to me that my taking on the identity of designer came at the very same time as my most successful accordion experiences. Hmm, maybe that's a correlation worth exploring and advocating.

Did You Hear the One About ... Affordances of a Digital Q Sort Activity

I heard a good joke recently. Here goes...

"A rich miser made his wife promise that when he died she would bury all of his money with him. After he died, at the funeral, she placed a box inside the casket with him. Later that day, a good friend asked the widow if she actually put all of his money in that box. The widow replied that she complied fully with her husband's wishes. 'On the day that he died, I put all of his money...'"

I'm going to be a little cruel and not tell you the punch line right away. What gives? Well, I'm doing this to make a point. And don't worry, I'll finish the joke near the end of this post.

Here's the main idea: Like good comedy, timing is important in good teaching and learning. For example, if you are a science geek like me and someone shows you a cool experiment with results that don't match your expectations, you want a full explanation of what's going on right away. (I always refer to this as the "Mr. Wizard Approach," in honor of Don Herbert and his teaching strategy on his popular TV shows of years long ago.) When curiosity and interest are piqued, a teacher has a unique learning opportunity, sometimes referred to as a "teachable moment." The need or wanting to know something is a powerful force that the best teachers leverage. Of course, if the teacher waits too long or doesn't recognize the opportunity, the moment will be lost, perhaps forever. How long is too long? Well, it all depends, doesn't it? Perhaps you've already lost interest in my joke and have moved on to checking Facebook. Or, more likely, you've skipped all this blather to try to find out the punch line below. (Well, maybe it's not there - boy, that would be cruel.)

OK, now let me get to the specific point of all this. I have recently been collaborating with Brandy Walker and Rich McCline of the Fanning Institute here on the University of Georgia (UGA) campus on the topic of using Q sorts within an instructional or learning setting. Brandy and Rich do a lot of outreach to community groups and organizations within the state of Georgia. Their work is not so much instructional as it is facilitative - that is, they try to help groups clarify goals and issues so that these groups can make good decisions. They have been using Q sorts within many of their workshops as a way to help the participants understand their subjective perspectives on the various important issues that the group is facing.

Brandy and Rich have been implementing paper-based Q sorts, so they are interested in the opportunities afforded by the digital tool I've slowly been developing. However, in one of our recent meetings, we began to talk about just what are the affordances of a digital approach, and also what are the affordances of the paper-based approach. To be sure, there are many excellent affordances to the paper-based approach. The tactile and visual elements of having a large Q sort board lying in front of you as you move the small statement cards about are very strong. It's also a very intuitive process. You know exactly what you are doing and it is easy to make quick modifications. The other significant affordance is the ability to have a Q sort with a large number of statements. The most I've seen in the literature is around 65 or so. After all, you have the entire space of the table at which you are sitting to use.

In contrast, my digital version currently only allows a maximum of about 25 statements and this is a real limitation to any serious Q sort researcher. It's not a big limitation for my purposes given my interest in using the Q sort activity as an instructional activity, but I know I need to think about ways to expand the number of statements while remaining true to the original Q sort procedure of having all of the statements available to the user as the sorting activity proceeds. Other electronic versions I've seen perform the activity in a fashion where you group the statements in stages, starting with low, middle, and high piles as step 1, then only work with those piles sequentially in the subsequent steps. I admit that I'm resisting that approach as I think it violates some aspect of the true Q sort approach. (I may be wrong.)

OK, So What Are the Affordances of a Digital Version of the Q Sort Activity?

Despite the charms and history of the paper-based version of the Q sort activity, I firmly believe that my digital tool offers significant advantages over paper-based approaches. As Brandy, Rich, and I quickly discussed the pros and cons, I agreed to come up with a tentative list of affordances for my digital approach. So far I've come up with four main affordances:

1. The easy preparation of an unlimited number of Q sort activities.
2. The easy and quick administration of any single Q sort activity either in a face-to-face or online environment (synchronous or asynchronous).
3. The ability to administer multiple Q sort activities within a single session easily and quickly.
4. The ability to provide real-time data analysis (suitable for instructional purposes) quickly to the participants during an active Q sort activity.

You should notice my fondness of the words "easily" and "quickly."

To conduct a Q sort with my digital tool, you enter a special code given to you by the instructor to bring up the Q sort activity. This code simply queries an online database that transfers the statements needed for the Q sort and also produces a Q sort board with the right number of slots. After the person finishes the Q sort, the answers are uploaded to the database. If I want everyone to do another Q sort, all I have to do is give them another special code and the app automatically and immediately resets. Creating the Q sort itself takes maybe 10 minutes once you have the list of the statements. I built the database to make it easy to duplicate and revise any Q sort in the library.

The fourth affordance is one that I've worked on quite a bit this summer with the two online courses I've been teaching at the University of Georgia. Up until the most recent version, only the instructor (aka me) could do the "quickee analysis" and then share the results with the group. The latest version of my Q Sort Tool puts these analysis features into the hands of the students. As soon as they complete a Q sort, they can then begin checking the results. I made several videos demonstrating and explaining all this for my students, but I'm not able to share these here because they contain personal data. Soon, I'll create some videos with the personally identifying information removed or masked in order to demonstrate how this feature works.

Why are these affordances so noteworthy? Again, you have to consider all this from a teaching and learning point of view. It's one thing to conduct a research study using Q methodology where the data are collected, analyzed, and reported. This involves a process that can take weeks or even months. The goal of traditional Q methodology is to better understand what are the different profiles within a group describing their subjective interpretations of a particular issue or topic. For instructional purposes, the goal is to get people to think deep and hard about a particular topic, followed by having some good discussions, reflections, and more discussions and reflections during a period of time when people actually care about the topic. These reflections are enhanced if you also know and consider your classmates' points of view.

Comparing the Digital to Paper-Based Q Sorts for Instructional Purposes

When Brandy and Rich conduct their Q sorts in their workshops, they have to prepare sufficient copies of the paper-based statements for every person attending the workshop. They also have to prepare a paper-based Q sort board for each person to use. The materials then have to be carefully assembled and distributed during the workshop. Brandy and Rich also prepare and post the statements on large flip chart paper mounted on walls around the room. Everyone then completes the Q sort individually. When finished, everyone is prompted to write down the statements they placed at the extreme ends of the Q sort scale. They are given a sheet of sticky green dots and red dots and told to find those statements on the flip chart paper on the walls, putting a green dot beside those statements they agreed with the most and red dots by those statements they agreed with the least. Then, Brandy and Rich use the flip chart paper and pasted dots to lead and facilitate a reflective discussion about the topic with the group.

It should be noted that the Q sort topic that Brandy and Rich conduct is based on a well-researched survey instrument that Rich has produced and validated over the years. Therefore, the statements they use in the Q sort are not submitted by the participants. Obviously, if the procedure was to engage the participants first in producing their own individual statements, they would have to figure out a way to get those statements far in advance of the workshop in order to have enough time to prepare the statement cards. In their case, they recycle the cards for the next workshop. I don't know if they would ultimately find tiresome the labor needed to constantly produce new statement cards for a new Q sort for each workshop group. That is, I wonder if they would abandon the Q sort activity under those circumstances. The other consideration is that the number of Q sort statements would have to vary, which would mean having at the ready Q sort boards with the right number of slots.

Most of the comparisons we could make between a paper-based and digital Q sort boil down to logistics, but there are cognitive issues at play here too. For example, I think it makes a profound difference if the Q sort statements are based on the participants' own views. I think this makes the Q sort itself much more meaningful and authentic because each participant is given a window into the thinking of their peers as they complete the activity. It's also quite meaningful and motivating to see your statement among the list. But, I think there is another important cognitive issue that relates (finally) to the issue of timing.

The Clock is Ticking

There are many things one can conclude from comparing paper-based and digital Q sorts. Let's say that you are perfectly willing to spend whatever time it takes to prepare the paper-based materials. But, consider the time it takes between a single person completing the Q sort and the start of the reflection and then the small- and large-group discussion. I assert that if too much time transpires then the "teachable moment" is seriously threatened. That is, people may either lose interest or forget the point of the exercise. Of course, knowing that Brandy and Rich are expert workshop leaders, they likely use the time well and engage people in conversations while everyone is up and about putting their red and green dots on the mounted flip charts. And, I can see some real affordances to the social aspect of this milling about that an expert workshop leader can leverage. Still, I think reducing the time between completing a Q sort individually, reviewing the group results, and then holding the reflective discussions is overall the preferred approach.

The point - again - is that timing is everything. Which reminds me...

"On the day that he died, I put all of his money in a bank account and I wrote him a check."

Yes, that is the punch line to the joke that began this blog post. Hmm, do you remember the set up?

(I heard this joke from Professor Young-Suk Kim of Florida State during her excellent talk at the 2016 AERA Conference in Washington, DC.)

Final Thoughts

I'm obviously a little biased here given the many, many hours I've spent developing my little digital Q sort tool and the web site with the database backend I've designed to support it. To be sure, there are many limitations to my digital approach. The most noteworthy is one I've already mentioned - the relatively limited number of statements that can be used. Another limitation is the fact that my tool is not web-based. You have to download and install a client-based app on your computer, which many people are reluctant to do, or simply find very bothersome to do. There is also a certain level of opaqueness in using any digital tool when compared to the totally intuitive nature of moving slips of paper around on a table, a difference that is not trivial.

As I end this posting, I think an additional and noteworthy point to be made is that my tool can also be used for traditional Q sort research. That is, my digital tool quickly and easily collects data in the needed format for uploading into a bona fide Q sort analysis program. Brandy and Rich also collect the full data for subsequent analyses. The IRB procedures they follow start with taking a photo of each person's completed Q sort (with the participant's permission). Later, someone from Brandy's research team manually enters each Q sort into an Excel spreadsheet. The steps Brandy and Rich need to complete to get to the point where they can run a statistical analysis is time-consuming and - from my perspective at least - arduous and cumbersome. Of course, I could not think of a better way to do it.

As I hope is evident, getting all of the Q sort data collected and ready for analysis in a paper-based approach is no small chore. The choice is either to convince each participant to accurately record their Q sort results to yet another medium (paper or a spreadsheet), or having the researchers move around the room to record the data in some fashion. The Q researcher yearns for "quickly and easily."

An aside, but it's also been on my mind that an interesting research study would be to compare the outputs of my "quickee analyses" with the traditional Q-style factor analyses. I hope to either focus some research on that question myself or support an enterprising doctoral student who would like to take it up.

The other thing that I always find fascinating about producing digital tools is the ability to come up with small, but important variations in the tool or what it can do. These are often made in combination with creative changes or enhancements to the instructional approach. It's amazing how many times an idea comes up with the preface "If only your tool could do this..." It's usually very easy to make these sorts of small revisions or enhancements.  But, again, I don't want to discount the hands-on tactile feel of moving paper or cardboard around on the table, or having a reason to get up and move about the room and having some short or long conversations with other people doing the same thing. I don't want to live life only in front of a screen. But, I think creative and innovative teachers always take full advantage of the affordances of all of the available resources available to them.

Lloyd's Physics Simulation: Prototype 1

I'm a real physics geek. If I see a cord hanging from a ceiling light swaying back or forth, I'm immediately enthralled with the physics of the motion. I can easily imagine Galileo using this pendulum as a timing device. I can quickly conjure up Einstein's thought experiment about the equivalence principle. This principle imagines one being sealed in a little rocket ship without windows and wondering - is this light cord swaying back and forth the way it is because my rocket ship is accelerating somewhere deep in space, or is my rocket ship still sitting on the launch pad and therefore in earth's gravitational field? The cord will produce the exact same pendulum swing in both scenarios.

I'm a proud owner of the three volume set of "Lectures on Physics" by Richard Feynman - also known as the "red books," and many of his other "less technical" publications, such as his book "Surely You're Joking, Mr. Feynman!" (A real Feynman fan knows the story behind the title; hint: it's about being subjected to another's pretentiousness.) Perhaps my favorite little anecdote in one of his writings is the example of why flanges on railroad car wheels are unnecessary - it's because the inner surfaces of all the wheels are curved. This causes the wheels to always "fall back" toward the center of the track - the flanges are there just as a precautionary, safety device, but really are not necessary. In fact, you should stop reading this blog right now and immediately begin watching part 1 of the recording of The Character of Physical Law at Cornell in the 1960s. (The introduction of Professor Feynman by then provost Dale B. Corson in this very first video is very funny.)

I could go on and on. In short, I may not be a physicist, but I know what "matters."

So, why didn't I become a physicist? Simply put, learning physics is really hard and, honestly, the mathematics of it all is beyond me.

So, what to do? Well, retreat to what I understand, of course, and that takes me to Newton's Laws of motion. I barely understand Newton's Laws of Motion, but I find them a constant source of inspiration and wonder. They seem so simple at first glance - an object in motion stays in motion, etc., but it gets complicated in a hurry as you consider that these laws of motion explain the orbits of the planets and were used to get Neil Armstrong, Buzz Aldrin and Michael Collins to the moon. (I've always had a fondness for poor Michael stuck in the command module orbiting the moon as Neil and Buzz were walking around about 70 miles below. So close.)

One other very timely example of the importance of Newton's Laws of Motion is happening right now. As I finish writing this blog posting on July 4, the Juno spacecraft is scheduled to reach its destination - Jupiter - this evening. In order to attain an orbit around Jupiter for the spacecraft to carry out its mission, it must slow down sufficiently for Jupiter's gravity to snag it. For that to happen, Juno's engine must fire for about 35 minutes at just the right time. If that fails to happen perfectly, Juno will just fly by Jupiter and the mission will end in failure.

Lloyd's Physics Simulation

A really good starting point for applying the laws of motion to everyday events is understanding the relationship between acceleration, velocity, and distance. This relationship has fascinated me since I was in high school. It's one of those sets of principles that seems perfectly easy to understand - until you really try. Then, when you finally get it, the understanding opens all kinds of doors to other learning. Differential calculus is a good example. Velocity is the first derivative of distance and acceleration is the second derivative of distance. This means that acceleration is the first derivative of velocity. Well, of course.

Wait, don't close that browser window! Let's explore acceleration, velocity, and distance by playing the first prototype of "Lloyd's Physics Simulation." This app is the result of only about five hours of work.

One of the most exciting developments in the LiveCode world is the option to export projects as HTML5, so I thought I would use this option to share this project, but you can also choose to download one of the standalone versions, or just watch a very informal video demonstration I made for my summer design course I'm teaching for the University of Georgia.

HTML5 Alert! It will likely take awhile to load the first time you run it. Depending on your Internet speed, it might even take a minute or two. So, be patient.

HTML5 | Macintosh Standalone | Windows Standalone 

Video Demo

If you ran the HTML5 version, you may have noticed some "weirdness" in how the simulation runs on the second or third try. The simulation speeds up for reasons I cannot explain. At some point, the simulation becomes unplayable. This does not happen when you run it as a standalone app. One simple solution is just to reload the web page in the browser. (This won't take as long as the initial download.) I plan on submitting this problem to one of the LiveCode user forums.

If you have been able to play the simulation, I hope you begin getting the gist of the relationship between distance, velocity, and acceleration. Distance is simply the how far the marble has gone in either direction in a given time. Velocity is the change in distance, such as 20 pixels per second toward the top at any particular moment in time. Acceleration is just the change in velocity, though it is usually expressed with the odd sounding phrase of "per second per second." But, that apparent redundancy actually explains acceleration well because if the velocity is changing (i.e. acceleration is not zero) the change in the ball's speed is likewise changing constantly. You get those really beautiful parabolic curves when the marble is accelerating. You will notice that the distance graph is a straight line whenever acceleration is 0 because only then is the velocity constant. These are just some of the patterns that will emerge if you pay close attention as you run the simulation.

OK, It Was Kind of Fun Trying Out the Simulation, But I Got Bored Quickly

Yes, unless you are a physics geek too, you will probably get bored quickly with this little simulation. There is the little challenge of keeping the marble from sliding off of the yellow track, but that gets old quickly. What to do about this? Well, that's where the design possibilities can get very interesting. I actually did a bunch of research about simulations as a learning tool some years ago. I always considered it a fundamental question of how much structure to overlay onto a simulation. I was keen on understanding to what degree completely free and open-ended exploration within a simulation would result in learning and motivation about the content of the simulation. Most people do get bored quickly when there is no structure. So, I began to experiment with overlaying simple design elements, such as little games. I wanted to see to what degree people needed more and more structure, which would culminate eventually with the ultimate in most structured designs, namely instruction. Some of my early work led to the design of a software package titled "Space Shuttle Commander" where the player was asked to do just that - be the commander of the space shuttle. To be successful, you had to know, or learn about, Newton's laws of motion. I gave it away for free and NASA actually published it among their free educational resources. Alas, this was many years ago and it only ran on the Apple IIe platform.

Here's a link to one of my "classic" (aka old) research articles about this (the complete reference to Rieber, Tzeng, & Tribble, 2004 is below). In other research studies I conducted specifically on the relationship between acceleration and velocity, I took advantage of that special moment when the marble changes direction. I called it a "flip flop" and built a little game around it.  I won't go into the details of that game now, but imagine what kind of games could be designed with this little simulation. For example, I can imagine having targets placed within the area of the line graphs that you have to try to hit with one of the graph lines.

Final Thoughts

You may have noticed my use of thick, thin, and dashed lines for the various graphs. We have been reading about accessibility issues in my UGA design class. If you are color blind, you would have difficulty taking advantage of the fact that I color coded the various graphs. But, by varying the line styles, you should be able to distinguish each of the graphs.

So, the laws of motion may not be as sexy as Einstein's relativity, Heisenberg's Uncertainty Principle, or Schrödinger's cat. But, for just about everything you and I observe in the world around us, they work very, very well. And, as my good friend and former Texas A&M colleague Ron Zellner is fond of saying ... "Action - Reaction. It's not just a good idea, it's the law."

Reference

Rieber, L. P., Tzeng, S., & Tribble, K. (2004). Discovery learning, representation, and explanation within a computer-based simulation:  Finding the right mix. Learning and Instruction, 14, 307-323.

Postscript

I've never been very certain about Heisenberg's Uncertainty Principle. As far as I can tell, I can either know where I am or where I'm going. Which would you prefer?