Planning an In Class Activity Guide

Overview

The in class activity is very useful for a multitude of reasons–it’s a great opportunity to test out collaboration features, get honest feedback from first-time users, and test the feasibility of communication features. This section focuses on the different in class activities you can pursue. More specifically, it goes over how to plan, execute, and create an effective post-activity survey.

Planning

• Purpose

  • The first step in planning an in class activity is to establish a purpose. Here are some important questions to ask yourself:

    • What software would you want to focus on?

    • What features are testable within a single class activity time slot?

    • What is some information you can only get through testing the software with the whole class?

• Choosing actual features to use

  • After establishing the purpose, the next step is to figure out the content of the in class activity. You would want to select a task that is appropriate in terms of time and difficulty and try to stray away from something that you can do in your own time (unless there’s a specific reason why everyone in the class should do the activity.) Getting feedback on specific features/aspects of the software, testing group collaboration features, testing reliability of communication features are some good ways to spend the time allotted for the in class activity. In addition to selecting the features to use, start to think about what information/opinions you would want from your classmates from the in-class survey and come up with a proper scale for each question you are planning on asking. More information about the survey is written a few sections below. Lastly, you should estimate how long it will take to complete the activity. It’s important to note that most activities take 5-10 mins longer than anticipated.

• Writing the class activity wiki article

  • Writing up the class activity in a wiki entry is also another important part of executing a successful in class activity. Your classmates will rely on this wiki entry for the most part, which means the wiki entry must be as accurate and detailed as possible. Include video tutorials wherever possible, and make the instructions descriptive (ex. Instead of writing something like “change the color of your brush,” write something like “navigate to the menu on your left wrist, where you will see a brush icon. Select that with your right controller and choose a color of your choice. Then, start drawing with it.) It’s also important to include some guiding questions that your classmates should be thinking about while they do the activity (ex. If you are trying to figure out how long it takes for a user to locate and load in a dataset, include something in the wiki entry like the following: “Before you get started with loading in the dataset, start measuring how long it takes to do this process.

• Back up activities

  • Regardless of how many times you rehearse your activity, there will always be a chance that some aspect of the activity might malfunction. Therefore, it’s always important to have a backup plan prepared. If you are testing data visualization software, have an extra dataset ready for use. If you are testing communication features on collaborative spaces, be prepared to ask the class to use a different piece of software in case the software malfunctions.

Executing

• Pre-installation

  • Pre-installing the software before the class is a major time saver. Make sure to ask your classmates to do as much of the installation process before class starts by sending them an installation tutorial or guide.

• Start of activity

  • Start off the activity by verbally explaining what the activity entails. Go over any confusing parts of the activity, and take any questions before your classmates get started with the activity.

• Middle of activity

  • Take any questions that your classmates may have, and cycle through the breakout rooms to check up on your classmates (if you decided to break up the class into smaller groups.) It’s important to check up on your classmates, especially since many of them may be hesitant to ask for help.

• End of activity

  • Ask your classmates to start the survey around 5-10 mins before the allotted time ends (depending on the length of the survey). You can also choose to ask your classmates to fill it out after the class ends.

Post-Activity Surveys

The surveys are the most important part of the in class activity. You would be using the results you get from the in class activities as evidence for the content you write on your wiki articles. There are a few things to consider regarding post-activity surveys:

• You only get one chance

  • There’s only one chance to get as much information as you can about your classmates’ experiences with the software. You need to make sure you’re getting enough information, the right type of information (qualitative/quantitative), and relevant information.

• Think about how your quantitative criteria are scaled

  • The way you phrase your questions and designate scales for responses (Ex. 1-10, Always/Sometimes/Rarely/Never, etc.) make a great difference in how accurately you can convey information about the software to the readers of your wiki page. Here are some example scenarios that depict good and bad usages of certain scales:

    • Scenario 1-you are trying to answer the question “How often do you encounter bugs/glitches in the program.” It’s much easier to convey this information by asking your classmates to report the number of occurrences of bugs/glitches through a 10 minute timespan, rather than asking them to report their answer on a scale of “Always/Sometimes/Rarely/Never.” Although the latter option is technically a quantitative scale of 1-4, it gives an inaccurate depiction of how often bugs actually occur because we didn’t even define what “Always,” “Sometimes,” “Rarely,” “Never” mean.

    • Scenario 2-you are trying to answer the question “How navigable is the software?” It’s much easier to convey this information by asking you classmates how many minutes it took to access/figure out a specific feature in the app, rather than asking them to answer the question on a scale of 1-10.

• Think about how broad/narrow your question is

  • There’s usually only around 5 minutes to fill out a survey, so you may be inclined to throw in as much information in a question as possible. An example of this would be the following: “How would you rate the communication/collaboration features of this app.” Although this way of asking questions may sound efficient, you might end up with false/skewed information. This is because you are asking for the surveyees to rate both the communication and collaboration features with one shared value, when the two are actually very distinct criteria. Make sure you are as specific as possible with how you phrase these questions, since you are better off not asking vague questions (like the example above) compared to asking them–you could save some precious survey answering time by not including the question.

• Think about the overall purpose of the survey

  • As mentioned above, there’s a limited amount of time to fill out the survey, which means each question must be phrased in a way such that surveyees are able to answer it as accurately and as fast as possible. One other thing to look out for is whether or not the questions are aligned with the goals of the class activity. For example, if you are evaluating data visualization software, you should be almost solely focusing on the collaboration and communication aspects, as well as overall feedback on the software. You shouldn’t be asking questions you can answer yourself, such as “What are the key features of this software that make it unique compared to other similar software?”