Full-class review games using students’ smartphones (TiLT Forum 2018)

Hello, TiLT Forum!

My presentation is about two free websites that enable teachers to run full-class review games: Quizlet and Kahoot.

Quizlet.com is a free website that hosts millions of sets of student- and teacher-created flash cards.

Quizlet supports creating flash cards in virtually any language, including those with non-Latin alphabets (e.g., Chinese) or right-to-left writing direction (e.g., Arabic and Hebrew). In addition, Quizlet has text-to-speech functionality in 17 languages, including English, Spanish, French, German, Chinese (Simplified and Traditional), Portuguese, Arabic, Italian, Japanese, Korean, Russian, Turkish, Dutch, Greek, Swedish, Finnish, and Romanian.

In addition to studying your material as flash cards, you can play various games and do other types of learning exercises.

Here is a study set that I created for one of my classes recently:


Quizlet Live is a new game mode offered by Quizlet.com. It’s a team game designed to be played in the classroom. Students work in groups of 3 or 4 and are incentivized to answer carefully and to discuss and collaborate with each other. Slow and steady wins the race.

Try out a demo of the Quizlet Live game here to see how it works: https://quizlet.com/livedemo

Setting up a Quizlet Live activity:

  1. Log into Quizlet.com. (This is a mandatory step!)
  2. Go to your Account Settings page and make sure you are in the system as a Teacher, not as a Student (you only need to do this one time):
  3. Open any Quizlet card set (or create your own).
  4. Click on the “LIVE” button on the card set you wish to play Quizlet Live with.
  5. Click the “Create Game” button.
  6. Instruct students to take out their phones (or other internet-connected devices) and go to quizlet.live (note that the address is .live and is NOT the same as quizlet.com).
  7. Instruct students to enter the six-digit join code and enter their names.
  8. After all students have joined the game, click the buttons on the screen to run the game.

Kahoot! is a review game somewhat similar to Quizlet Live, except that Kahoot! is a highly competitive game that incentivizes students to answer as quickly as possible.

Here is an example game I created: https://play.kahoot.it/#/k/68b27a0f-776b-42ba-b896-e8672646a0d2

Setting up a Kahoot! activity:

  1. Create an account at kahoot.com
  2. Under “Create new Kahoot!”, choose “Quiz”
  3. Complete the form (title, description, etc.) and click the “Ok, go” button
  4. Click the “Add question” button to create your first question.
  5. Type your question and set the time limit / points options.
  6. Type up to four answer choices in the boxes near the bottom of the screen.
  7. Click on the checkmark next to an answer to mark it as correct. (You may mark more than one answer correct.)
  8. Click “Next” at the top right of the screen to go back to your quiz.
  9. Either…
    1. Click the “Add question” button to add another question
    2. Click the green “Save” button at the top right of the screen to save your quiz
  10. After you click “Save”, you are given options to edit, preview, play, or share your new Kahoot quiz.

Running a Kahoot! activity:

  1. Click on the “My Kahoots” button near the top-left of the page. (If you don’t see the “My Kahoots” button, try clicking the purple button with three lines near the top-right of the screen.
  2. Click the “Play” button next to the Kahoot! quiz you want to run in class.
  3. Choose either “Classic” or “Team mode”, and set any other game options you wish to use. (One popular game option is “Randomize order of answers”, for example.)
  4. Make sure students can see your computer screen via the classroom projector/monitor.
  5. Instruct your students to go to kahoot.it (not .com) on their phones, mobile devices, or laptops. Instruct them to type in the game-pin which has appeared on the classroom screen.
  6. Click “Start” when everyone is ready.
  7. Enjoy! After the activity, you can download all students’ answers from the “My results” section of the website (click on your username at the top right of the webpage).

Mac computer lab headaches! A script to handle keychain errors, docks, and users logged in in the background

I’m primarily a university-level ESL instructor. However, one of my responsibilities is to manage our English Language Institute’s computer lab, which has 20 iMacs. Here are some of the issues I’ve struggled with:

  • Keychain errors. My university uses Active Directory for usernames and passwords, and Macs don’t play nicely with Active Directory. Every time that students and faculty are forced to change their passwords through the university’s web interface, it breaks their keychains on all campus Macs, since the login password is no longer the same as the keychain password. Dealing with keychain errors is annoying enough under one-device-per-person circumstances, but when people use multiple computers over the course of multiple semesters and change their password multiple times, the problems snowball out of control.
  • Messing up the dock. It’s pretty straightforward to set up a default dock for new users. However, most of our students lack familiarity or comfort with Macs, so if a student accidentally drags an important icon (like, say, Microsoft Word) out of the dock, they may have difficulty finding the application again. Under these circumstances, it’s desirable to “reset” the dock to a known good state every time a user logs out so that any mistakes they made will be wiped away.
  • Users not logging out. This is a big one. If a user fails to log out properly and ends up with their whole session still stored in memory in the background, system performance plummets for anyone else who logs into that computer. This is a huge problem in a lab setting because it’s difficult to train users to always properly log out, and each computer is logged into so many times every day that it only takes a couple days for most computers to have at least one user still accidentally logged in in the background.

One solution to these kinds of issues is to have a very tightly controlled computer lab where no user data is stored and where the computers constantly restart and reset themselves to known good states. But I’m not comfortable doing that; I want students to be able to log back into a computer to retrieve a file if they accidentally saved it to the lab computer instead of their personal flash drive, for example.

So instead, I wrote a logoff script to do some basic maintenance to help me solve these issues. Macs don’t provide an easy built-in way to run logoff scripts, so I use Offset to run the script for me.

My script does the following:

  1. Delete the user’s keychain every time they log out (step 1 of script). This prevents keychain errors and improves security, since it ensures we aren’t storing people’s passwords on our public computers.
  2. Replaces the user’s dock with a known good configuration (step 3 of script). That way, if the user accidentally messed up the dock, it will be back to normal the next time they log in. Yes, this does mean that users cannot customize their docks– but in a lab setting, what a student customizes on one computer won’t carry over to another computer anyway, so why give them the illusion of choice? Better to keep things standardized.
  3. Kicks off anyone who’s logged into the computer in the background (step 5 of script). This dramatically improves system performance.
  4. Restarts the computer if it’s been on for more than a day (step 5 of script). This is a necessary step to fully purge keychain files.

Here is the script I created. I am not a bash expert or a MacOS expert, and I make no warranty for the functionality or safety of this script; I’m presenting it only for example purposes to help others in similar positions. If you want to adapt this script, you will likely need to make changes.

echo "$(date) - Script execution beginning" >> /Library/Logs/lab_logout_debug.log

### Step 1: Delete the last user's keychain; we always want to do this upon logout no matter what
# Credit to https://github.com/aysiu/Mac-Scripts-and-Profiles/blob/master/RemoveLastUserKeychains
echo "$(date) - Entering step 1" >> /Library/Logs/lab_logout_debug.log
# Get the last user's username
lastUserName=$(defaults read /Library/Preferences/com.apple.loginwindow lastUserName)
# Remove the keychains for that user
sudo rm -rf /Users/"$lastUserName"/Library/Keychains/*
sudo rm -rf /Users/"$lastUserName"/Library/Keychains/.f*
# Add to log file
sudo echo "$(date) - Keychain deleted for $lastUserName" >> /Library/Logs/lab_logout.log

### Step 2: Decide whether we need to run the rest of the script.
#           If we're at the login window, and if the script has not run
#           in the last 120 seconds, then we want to run it now.
#           Note: Checking when the script last ran prevents the script from 
#           killing the login window over and over and over again in a loop!
#           I chose 120 seconds because it would be unusual for someone to be
#           logged in for less than 2 minutes.

echo "$(date) - Entering step 2" >> /Library/Logs/lab_logout_debug.log
echo "$(date) - initializing shouldrun to false" >> /Library/Logs/lab_logout_debug.log
echo "$(date) - trying to find the last time run log file" >> /Library/Logs/lab_logout_debug.log
# Can we find the log file that stores the last time the script was run?
if [ -f /Library/Logs/lab_logout_last_time.log ]
    # We found the file!
    echo "$(date) - found last time run log file" >> /Library/Logs/lab_logout_debug.log
    # Store the current Unix time in seconds
    currenttime=$(date +%s)
    # Read the Unix time in seconds that the script last ran
    lasttime=$(cat /Library/Logs/lab_logout_last_time.log)
    # Calculate the difference between the times: How long ago did the script last run?
    delta=$(expr $currenttime - $lasttime)
    echo "$(date) - Current time: " $currenttime >> /Library/Logs/lab_logout_debug.log
    echo "$(date) - Last time: " $lasttime >> /Library/Logs/lab_logout_debug.log
    echo "$(date) - Delta: " $delta >> /Library/Logs/lab_logout_debug.log
    # Did the script last run MORE than 120 seconds ago?
    if [ "$delta" -gt 120 ]
        # Yes? We should run the rest of this script.
        echo "$(date) - set shouldrun to true (delta large enough)" >> /Library/Logs/lab_logout_debug.log
        # No? We should not run the rest of this script.
        echo "$(date) - keep shouldrun at false (delta too small)" >> /Library/Logs/lab_logout_debug.log
    # We didn't find the log file that stores the last time the script was run, so let's assume we need to run the script.
    echo "$(date) - didn't find the last time run file" >> /Library/Logs/lab_logout_debug.log
    echo "$(date) - set shouldrun to true (file not found)" >> /Library/Logs/lab_logout_debug.log
# Should we run the script?
if [ "$shouldrun" = "true" ]
    # Yes, we should run the script!
    echo "$(date) - shouldrun evaluated as true - executing remainder of script" >> /Library/Logs/lab_logout_debug.log
    echo "$(date) - Executing lab logout script." >> /Library/Logs/lab_logout.log
    ### Step 3: Copy the dock for the user
    echo "$(date) - Entering step 3" >> /Library/Logs/lab_logout_debug.log
    cp /Library/lab/com.apple.dock.plist /Users/$lastUserName/Library/Preferences/
    echo "$(date) - Dock copied for this user:" $lastUserName >> /Library/Logs/lab_logout.log
    ### Step 4: Record the current time as the last time the script ran
    echo "$(date) - Entering step 4" >> /Library/Logs/lab_logout_debug.log
    # Record the current time to the lab_logout_last_time file, overwriting any previous file content
    echo $(date +%s) > /Library/Logs/lab_logout_last_time.log
    echo "$(date) - Current time recorded" >> /Library/Logs/lab_logout_debug.log

    ### Step 5: If the computer has been up for at least 24 hours, then restart;
    #           otherwise, just kill loginwindow

    echo "$(date) - Entering step 5" >> /Library/Logs/lab_logout_debug.log
    echo "$(date) - Current uptime: $(uptime)" >> /Library/Logs/lab_logout_debug.log
    # Has the computer been on for at least one full day? 
    # (i.e. does the word "day" or "days" appear in the output of the "uptime" terminal command?)
    if [[ $(uptime) =~ .*day.* ]] 
        # Uptime is at least one day, so let's force a restart. This will fully clear keychains and (obviously) log out all users.
        echo "$(date) - Uptime greater than a day; attempting a restart" >> /Library/Logs/lab_logout.log
        sudo shutdown -r now
        # Uptime is less than one day, so let's just kill the loginwindow process to make sure no one's
        # logged in in the background.
        echo "$(date) - Uptime less than a day; killing loginwindow." >> /Library/Logs/lab_logout.log
        # Kill loginwindow to log out any users who are logged in in the background
        sudo pkill loginwindow

    # No, we shouldn't run the script!
    echo "$(date) - shouldrun DID NOT evaluate as true, so script did not run" >> /Library/Logs/lab_logout_debug.log

Basic installation instructions:

  1. Install Offset.
  2. Paste my script into a new file with a .sh extension. (the specific filename I personally use is “lab_logout.sh”)
  3. Make any necessary changes to the script. Note that it won’t run as-is; at the very least, you need to put a dock.plist file in the /Library/lab/ directory for step 3 of the script, or else remove that part of the script.
  4. Move the script file to /usr/local/offset/logout-every so that Offset will run it for you.
  5. Make the script file executable. I run this command in Terminal, and it seems to work, but I’m not an expert, so ymmv: sudo chmod 755 /usr/local/offset/logout-every/lab_logout.sh ; sudo chown root:wheel /usr/local/offset/logout-every/lab_logout.sh

That should do it!

Recorded Speaking Activity (RSA): Pedagogy, Implementation, Evaluation and Creation

I had the pleasure this past weekend to co-present about the Recorded Speaking Activity we do at my institution. Check it out below!

I presented earlier this year at TESOL International about the benefits of using Google Drive for collaborative activities, and incidentally, this is a demonstration of those benefits, as my colleagues and I used Google Slides to create this presentation together. I don’t think I posted my TESOL International presentation on this blog, but I gave a similar presentation at Three Rivers TESOL 2016.

Three Rivers TESOL 2015 – Collaborative Projects the Easy Way Using Google Drive

This is a companion post for my presentation at Three Rivers TESOL on 11/7/2015. In the live workshop, we will do hands-on activities with Google Drive. This post contains some introductory prose and a link to a “how-to” document for setting up Google Drive projects for your own students.

Students collaborating using Google Drive. Photo: Charlotta Wasteson, CC BY 2.0
Students collaborating using Google Drive. Photo: Charlotta Wasteson, CC BY 2.0

Have you ever assigned a group project such as a panel speech or a group presentation? If you have, you know that the logistics tend to get messy. In my experience, students in a group often each create their own PowerPoint files and then try to paste them all together into one group file. This requires a lot of emailing and effort, and the final product usually looks inconsistent and shabby due to varying slide designs, fonts sizes, and so on. Plus, if one or two students aren’t pulling their weight, their poor or missing work may come as a surprise to their fellow group members on presentation day.

But what if all the members of a group could work on the same file at the same time?

Google Drive is a free online office suite created and maintained by Google, Inc. The program is accessed via a web browser (on PCs/Macs) or via mobile apps (iOS/Android). Where Google Drive differs most substantially from Microsoft Office is that it makes collaboration very easy: everyone working on a project can edit the same document at the same time, and built-in commenting and chatting features enable the collaborators to coordinate their efforts. The online nature of Google Drive also means that teachers do not need to “collect” work. Rather, teachers have permanent, ongoing access to the document and can monitor student work live as it happens.

See here for instructions:

Using Google Drive for Collaborative Student Projects

The above document contains all the instructions you need to get a project up and running. It’s certainly a bit simpler to set projects up if your institution uses Google Apps for Education (GAFE), but this is not a prerequisite. As long as the teacher has a Google account, the teacher can create the projects and enable students to work on those documents without needing to log into a Google account.

Give it a try!