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?

Lloyd's Video Analysis Tool: Now in the Mac App Store

Yes, Lloyd's Video Analysis Tool, an app I started over two years ago was just accepted by Apple and is now in the Mac App Store. It took three tries to get it in and although there was much frustration and anxiety associated with the first two rejections, I learned a great deal about many things, some of which I'll try to summarize briefly in this post.

First, some words of thanks to two people in the LiveCode community who helped me get through the last grueling quarter mile on this project: Klaus Major and Jacqueline Landman Gay. I also need to send special thanks to Sam Rowlands of Ohanaware. Apple found a bug in my app the second time they reviewed it which led me to a very confusing journey into the world of Apple's sandboxing approach to apps. I was finally able to understand the problem well enough to come up with a workaround thanks to their help. While on the subject of Ohanaware, they make a fantastic product called App Wrapper 3 that I heartily endorse. It "wraps" your app with Apple's developer certificates and automatically gets the app ready for uploading to Apple's iTunesConnect. I'll be purchasing a yearly subscription from here on out at a very reasonable cost of only $49.99. (Please note that was an unsolicited and unpaid endorsement!)

A Question I Had Long Pondered: Do I Even Want to Submit to the Mac App Store?

To be honest, I knew submitting to the Mac App Store would probably be a hassle given my previous experience submitting iOS apps to Apple. One has to figure out the whole "Apple certificate thing." Plus, I knew already that it was going to be a struggle to figure out how to then add the proper certificates to my Mac app because, unlike iOS apps, LiveCode does not provide a way to do it as part of the standalone creation process. (As it turned out, App Wrapper 3 made this step incredibly easy.) I also didn't know if my $99 annual Apple developer fee for iOS apps would count for Mac App (as it turns out, it did). In anticipation of all of this, I had done some research on "alternatives to the Mac App Store" and found a company called FastSpring. I like the company and so far they have provided great support. Now that my app is in the Mac App Store, I'm reviewing my options at this point. I still might offer the app for purchase at FastSpring also, assuming it doesn't violate some Apple policy. I already know that FastSpring is fine with me selling on the Mac App Store. FastSpring also did not require the Apple developer certificates, though I knew this would tremendously impact my sales as the app would then not be "recognized" by anyone Macintosh as coming from a "trusted" source due to way Apple's Gatekeeper software works. My point here is that FastSpring has been very easy to work with and flexible. I think further exploring a relationship with them will teach me more about the business side of app development, which I think my students will be interested in knowing more about.

But, I'm getting ahead of myself in telling this story. To back up, I was pleasantly surprised to be able to successfully acquire the needed development and distribution certificates from Apple. And, thanks to App Wrapper 3, I was able to easily add these to my app and produce a downloader file suitable for uploading to iTunesConnect. So, I decided I would just to submit a "lite" version of my app to Apple and sell the app itself on FastSpring.

I was also ambivalent about what to do for Windows users. Almost all of the problems reported by my beta testers over the past year have been about the Windows version. I didn't want to sell something to people if I wasn't confident it would work. All my development and testing of the app was on the Macintosh for the Macintosh, but it's obviously very easy just to also export a standalone version of the app to Windows with LiveCode. And, it did work for Windows users most of the time (as my students who are Windows users reported). So, a few months ago I decided that I would sell only the Macintosh version but the purchase would also come with a free (though unsupported) copy of the Windows version. That is, I would make it clear you were buying the Macintosh product and the "toy inside" (to use a breakfast cereal metaphor) was a free Windows copy. I felt this was ethical and met my own standard of "truth in advertising."

Mac App Store Rejection 1

First, I want to point out that I received feedback from Apple within about two hours of submitting the app the first time. Despite the fact that the app was rejected, I was very grateful for the quick turnaround.

Two reasons were given for the rejection. First, it appeared to the reviewer that it was a demo app and these are not allowed by Apple. I knew that going in and actually made the case in my "Notes to the Reviewer" when I submitted the app that this "lite" version was not a demo in that one could use the app to do real work even though the app intentionally had limited functionality. However, the reviewer still felt I was in violation of Apple's policy, but also gave me feedback that this objection could be overcome simply by indicating that another app would have to be purchased for complete functionality. Even though I felt had already done this, I apparently put this information in the wrong place. OK, so that objection could be easily surmounted.

The second reason for rejecting the app was that "the app enables additional functionality in a non-standard manner. Enabling features within the app with mechanisms outside of the App Store is not permitted." The reviewer is referring to the "unlocking" strategy I created on my own (click here to read about that). I obviously wasn't surprised that this strategy was termed a "non-standard manner," but I didn't think it would be a show stopper. I think the key phrase is "outside of the App Store" because obviously Apple wants all purchases to be made inside so that Apple gets their share.

After sleeping on it, I decided to just go ahead and submit a fully functional app to the Mac App Store. I submitted it around Noon last Sunday.

Mac App Store Rejection 2

Apple responded that they had rejected the app at about 10 pm Sunday evening. Three reasons were given: 1) the app wasn't "sandboxed appropriately"; 2) there was some discrepancy in how I named the app in various places in the submission process; and 3) "Apps that exhibit bugs will be rejected." Reasons 1 and 2 were easy to deal with, but a bug? The reviewer was nice enough to send me a screenshot of the error with a description of what s/he was doing at that moment, which was very helpful. Here's the screenshot:

This screenshot shows LiveCode's "Bug Report" dialog box that I wisely incorporated into the app some time back. Unfortunately, the Apple reviewer did not actually choose to send me the bug report. So, I spent the next day trying to recreate the error.

I actually was able to recreate the error rather quickly given that I knew where to look based on the reviewer's feedback. It was a "division by zero" error, something I had seen before when the video didn't load properly. The reason for the error is that I use a little custom formula that uses the duration of the movie in the denominator. If the movie doesn't load, this value is 0, hence the error. But, I had never seen the error before under these circumstances. Thus began a three day journey into discovering why.

Troubleshooting the Bug

Although I'm tempted to really get "into the weeds" at this point, I'll just jump to the cause and the solution. This is again where I need to thank Klaus, Jacque, and Sam. Without their timely responses to my calls for help, I would still be scratching my head. (If you want to read my detailed description of the error and the troubleshooting that ensued with Klaus, Jacque, and Sam, you can click here to read all about it in my posting to LiveCode's Mac OS forum.)

The problem was rooted in how Apple's sandboxing technology works. I already knew that all "apps were islands" in iOS and Mac OS, so I wasn't trying to write anything outside of the app's sandbox area. But the app does need to read outside the sandbox to get the path to the project video. This path is then stored correctly within the walls of the sandbox. But here was the really confusing part - the app successfully "found" the video outside of the sandbox, but it wouldn't load it. I just couldn't wrap my head around this because the user obviously had successfully been able to get the video to work when the project was first created. Why wouldn't it work now? I became even more confused when I discovered (after a few hours) that if I created a second video analysis project from scratch using exactly the same video, the first, older project would now work! But, if I quit the app and restarted, both stopped working ... unless I created a third project from scratch that also used the same video.

So, I figured the problem had something to do with Apple's sandbox technology. I initially put the blame on LiveCode's Player object. Sam explained to me what was needed to solve this problem, namely the programming some some key "entitlements" into the to allow it to access to the user's main area on the hard drive. Unfortunately, Jacque explained that this solution wasn't possible with LiveCode. I am so grateful to have learned this from Jacque because I likely would have spent many more days trying to figure it out. The solution I finally used is really just a workaround. I discovered that I could "reconnect" an old project to the video simply by asking the user to "confirm" the location and name of the project's video using LiveCode's "answer file" command. It was easy to include in the script the name of the video plus opening the video's enclosing folder in a dialog box. The user simply had to click to confirm the video. This re-established the link to the video and the link was sustained as long as the app was running. Yes, this added a little bit of inconvenience to the user, but there really was no other way to solve the problem.

Third Time's a Charm

I made the modifications along with a few last minute improvements to other parts of app, then submitted my third version to iTunesConnect around 1:00 pm on Friday. I tried to do other work after that, but I found myself checking for email from Apple every few minutes. As the afternoon rolled into the evening, I began to think those earlier speedy turnarounds from Apple were flukes. And, this was the Friday before Memorial Day weekend - the unofficial start to summer here in the USA - so I worried I might have to wait until Tuesday at the earliest to get a reply.

Interestingly, I mentioned to my wife around 7:30 pm that given that Apple's headquarters were in Cupertino, California, perhaps the reviewer was also on "California time" making it was only 4:30 there. I joked that the reviewer would say to him/herself "Maybe I'll review just one more app before my long weekend" with my app being the next one in line. Well, at 7:49 pm, I received an email indicating that my app was now "In Review." Then, at 8:50 pm I received word that my app had been approved!

Giving Out Free Copies

I've also updated the Web site for "Lloyd's Video Analysis Tool" where people can download the free version of the app to check it out before purchasing. This free version still has the "upgrade" feature that unlocks the app with the right secret code to give it full functionality. As I long planned, this will be my way to give out free copies of the app to people of my choice, such as my beta testers, all students and faculty in the College of Education at the University of Georgia, and definitely to Klaus, Jacque, and Sam. I designed the free version so that it would likely be more than sufficient for use by my colleagues who are requiring some sort of video analysis by their students as a course requirement. Having a functional, free version that teachers could use was important to me. I'm not worried about making money on this app, but then again, I'm not opposed to it either.

Final Thoughts

There is so much else I learned that I could write about here. And maybe I will since I took good notes (as always). My understanding of Apple certificates is clearer to me than before, though this still remains fuzzy. This process, at least to me, is about 5% intuitive and 95% memorization (hence the need for good notes). This is the kind of process one tends to learn by repetition. Fortunately, I have several other apps I'd like to wrap with certificates so that Gatekeeper will "trust" them when I ask my students to download and install them.

Now you might be asking how you can get a free copy of the app. Well, if you buy me a beer or two (or three) the next time we meet, that might do it. But, given that the app only costs $7.99 you will probably save quite a bit of money by just buying the app outright!