Sensor blocks—monitor the environment, including motion sensors, light sensors, buttons, contact switches, etc.
Compute blocks—perform basic logic transformations (e.g., AND, OR, and NOT) or basic state functions (e.g., prolong, toggle, trip, and pulse).
Output blocks—provide stimuli and include light-emitting diodes (LEDs), beepers, electric relays, etc.
Communication blocks—provide wireless point-to-point communication or replicate a signal to send to multiple blocks.
5.2.1 Boolean Blocks versus Integer Blocks The integration of integer-based blocks is intended to expand the class of applications that can be implemented utilizing the eBlocks platform. However, with the addition of integer blocks, the construction of eBlock systems become more complex. Not only are there a larger number of building blocks to choose from, but the underlying communication changes. In Boolean eBlock systems, all blocks communicate using "yes" and "no" packets, while integer blocks need to handle numerical values. Instead of limiting eBlock systems to strictly Boolean blocks or strictly integer blocks, users should have the flexibility to create heterogeneous systems composed of both Boolean and integer blocks. Thus, the existing Boolean blocks have been updated to handle integer values. When a zero is received, the packet is interpreted as a "no," and when values greater than zero are received, the packet is interpreted as a "yes." Integer blocks similarly accept Boolean values, "yes" packets are interpreted as a value of one, and "no" packets are interpreted as a value of zero.
To determine if users are able to comprehend the updated protocol, participants were first asked to build a simple system that sounds a buzzer then a button is pressed. This system is composed strictly of Boolean blocks and 100 percent of users are able to successfully create the desired application, as shown in Table 1. Next, participants were asked to build an alarm to detect when a nonzero number is detected. The resulting system is a heterogeneous application composed of a constant block (integer-based block) connected to a buzzer block (Boolean-based block). Again, all users are able to successfully create the desired application. Additionally, when students were asked why the beeper sounded for certain inputs but remained silent for other inputs, participants were able to explain that nonzero values were converted by the beeper block as a "yes" and the beeper block turned on. However, a zero value is converted by the beeper block to a "no" and the beeper block turns off. Participates were additionally asked to construct a system to sound an alarm when a value of zero is detected (instead of a nonzero value as specified by the second system). In this system implementation, an inverter block is needed between the constant and beeper blocks. While 60 percent of participants were able to successfully build the desired system, many groups struggled with how to modify the system to meet the new specification. From discussions with participants, it seems that the difficulty with the third application centered on the identification and use of the intermediate block rather than the combination of Boolean and integer packets utilized by the application.
5.2.2 Timer Block Many of the applications surveyed in Section 4.2 contained the concept to time. One such application may determine the speed at which a ball travels given different inclines. The system would need to track the time taken for the ball to travel between designated starting and ending points, and given the distance traveled a student could then calculate the average ball speed. Other such applications may include measuring velocity, acceleration, time required for different liquids to boil, hours of sunlight versus dark, and so on. Thus, an important addition to the eBlock platform is the timer block, as shown in Fig. 3e.
Aside from specifying the functionality of the timer block, we are also interested in determining how best to design the timer block interface. Fig. 5 illustrates two interface possibilities. In Fig. 5a, a sentence-like structure is utilized. In previous usability experiments, we found that students were better able to specify Boolean expressions with sentence-like interfaces versus table-like interfaces [ 14]. An alternative interface is also provided, as shown in Fig. 5b, with a slight change in wording.
One group of students utilized the first interface to construct a system that monitored how long a magnet is near a proximity sensor by connecting the magnet sensor eBlock to the start input of the timer eBlock. When the magnet is within a predefined range, the timer block is activated and counts up. When the magnet is farther away, the timer stops counting. An integer display block is connected to the output of the timer block to view the internal value held by the timer block. Additionally, a button block is connected to the reset input of the timer block to zero out, or restart, the internal time value held by the timer block. As shown in Table 2, 100 percent of the participants were able to successfully create the desired application. A second set of participants was provided with an alternative timer interface, as shown in Fig. 5b, and asked to construct a system to detect the length of time a button is pressed. The underlying implementation of this system is identical to the first scenario, with the exception that the magnetic sensor block connected to the start input of the timer block is replaced by a second button block. The change in application scenario was an attempt to make the desired system functionality more clear, as well as have students use button blocks instead of magnetic sensors as some students needed clarification on the use of proximity sensors. Again, 100 percent of these users were able to successfully implement the desired system functionality.
In speaking with participants, they readily understood both timer block interfaces. Participants were able to figure out that the "start" input controlled whether the timer counted or not. Additionally, participants were easily able to adjust the granularity of time tracked by utilizing the slide switch to select the desired option. Several groups utilizing the second timer block interface initially omitted the button block connected to the reset input of the timer block, but were able to figure out the missing connection required to reset the count back to zero. Moreover, one group was able to optimize the system implementation by utilizing a single button. The button was directly connected to the "start" input, while the same button was inverted before connecting to the "reset" input, thereby eliminating the need for a secondary button.
Based on the usability results, the middle school participants were able to easily utilize the timer block, regardless of the interface provided. We observed that the actual wording of the interface as well as the instructions provided on the back of blocks were generally ignored. Instead, participants looked for keywords, such as the name of the block or the name of the interface signals, to understand the functionality of the block. Furthermore, by eliminating an additional "stop" input from the timer block interface utilized with university students, the average successes rate increased from 55 to 100 percent.
5.2.3 Threshold Block Another common operation found in a variety of applications is the comparison of two values. In Boolean-based systems, two values can be compared utilizing the two-input logic (or combine) block configured to detect the desired relationship. For example, to detect if two Boolean values are equivalent, logic blocks are configured to detect (i.e., XNOR gate), to determine if the logic block is configured to detect A'B, or if the user wants to detect , the logic block is instead configured to detect . However, once the eBlock platform is extended to the integer domain, a new block capable of performing integer comparisons is required. It is not feasible to utilize a logic block to detect if ambient temperature is greater than 85 degrees, or sound an alarm when the number of people in room is greater than 50. Thus, the threshold block was introduced as a possible block to perform integer comparisons.
Two interface possibilities are examined, as shown in Fig. 6. The first threshold block interface utilizes a sentence-like structure to indicate the functionality of the block. The second interface, as shown in Fig. 6b, is updated slightly to indicate that a "yes" is only transmitted when the input conditions are true. Participants were asked to construct three systems: one system to detect if the temperature in a room was greater than 60 degrees F, another to detect when temperature was less than 90 degrees F, and the last system to detect when the temperature is equal to 76 degrees F. One group of participants utilized the first threshold block interface, while another group utilized the second interface. In each of the systems, participants needed to attach the temperature sensor block to one of the inputs of the threshold block and a constant block to the other input. Then, the slide switch needed to be adjusted to the " ," " ," or " " setting depending on which comparison was needed. Lastly, the output of the threshold block was connected to an output device to alert user when the specified scenario occurred, a beeper, LED, or integer display can be utilized.
Again, we observed that most students ignored the sentences provided on the face of the threshold block, and instead, tried to determine the block functionality by utilizing the switch and input labels. On average, 87 percent of users were able to successfully identify which block was need to perform a comparison operation as well as select the appropriate setting to configure the threshold block to. However, as detailed in Table 3, interface 1 clearly outperformed interface two yielding success rates of 100 and 80 percent, respectively. We observed that the groups who struggled with the second interface often interchanged the A and B inputs (i.e., instead of detecting , the system was configured to detect ). At this point, it remains unclear whether the interface itself posed the problem, or if determining how to setup the comparison based on the system description was difficult. Further investigation is needed. Lastly, based on the feedback provided from teachers and students, the naming of the threshold block will be updated to comparison block, to more readily impart the block's functionality.
5.2.4 Range Block An alternative type of comparison operation is range detection. For example, a user may want to see if the temperature in a fish task or greenhouse is within a recommended range. If the temperature fluctuates beyond the specified limits, an alarm is activated or a thermostat is automatically adjusted. Thus, the range block depicted in Fig. 3d is introduced. The range block can be configured the block to detect , , or . Instead of creating single purpose block that only detects if an input is with a predefined range, we decided to incorporate additional comparison possibilities in hopes of reducing the total number of blocks needed within the kit.
Fig. 7 illustrates two possible user interfaces. Similar to the threshold block design, a sentence structure is utilized, with a small change between the two interfaces wherein the first interface points the user to the status lights to determine the outcome of the comparison performed, while the second interface simply reminds users that a "yes" is transmitted with the comparison is true. Participants were asked to develop an application to determine if temperature detected was greater than 60 degrees Fahrenheit but less than 90 degrees Fahrenheit. One group utilized the interface shown in Fig. 7a, while the second group utilized the interface in Fig. 7b.
While the successes rates presented in Table 4 indicate that the first range block interface is superior, this is not necessarily the case. Most participants were readily able to select which block was needed to perform the range comparison. However, determining how to connect the various input blocks proved problematic. To create the desired system, two constant blocks are required. One block is connected to input A and specifies the low bound (60 in this example), while a secondary constant block is connected to input C to specify the high bound (90 in this example). Additionally, a temperature sensor is needed to detect the current temperature of the room and connected to input B of the range block. Many students tried to utilize two temperature sensors and one constant block. Others were unsure of which blocks should be connected to which inputs. We believe that the discrepancy is more closely related to the students' experience levels than difference between the interfaces provided. The first group of participants had a stronger knowledge of math and was able to translate the textual system description into an equation. While the second group of participants struggled to convert the problem statement into an equation and was unsure of even which input blocks were needed to implement the desired functionality. Additional testing is required to determine how best to reduce the ambiguity of the range block. Future iterations could update the interface to include arrows to correlating inputs to the comparison performed, updating the relative placement of inputs and switch, removing the additional comparison options, or by simply renaming the block.
5.2.5 Comparison of Threshold and Range Blocks Currently, comparison operations can be performed using either the threshold or range block. Fig. 8 demonstrates how both types of comparison can be accomplished by using only threshold blocks or using only range blocks. A comparison can be implemented using the threshold block, as depicted in Fig. 8a, by simply connecting both inputs to the desired values and configuring the block to either detect greater than, less than, or equal. Alternatively, a comparison can also be implemented by utilizing the range block, as demonstrated in Fig. 8b, by connecting two out of the three inputs of the range block. Depending on which two inputs are connected, a less than or a greater than operations is performed. The second type of comparison operation of interest is range detection. Again, this function can be implemented utilizing either the threshold or range block. If a user is limited to threshold blocks, the range operations can be implemented by utilizing two threshold blocks and a two-input logic block, as shown in Fig. 8c. The first threshold block evaluates whether , while the second threshold block evaluates . To determine if both comparisons are true, the outputs of both threshold blocks are connected to a two-input logic block, outputting a true value only when AB is true (both input comparisons are true). Similarly, a range operation can be performed by using only range blocks, and results in a much simpler system as indicated in Fig. 8d. To detect range utilizing a range block, all three inputs are simply connected, with the block configured to detected .
Because the threshold and range blocks have overlapping functionality, providing that a single block to perform both a comparison and range operation will not only reduce the number of blocks users need to choose from, but reduce the cost of the overall kit. However, the usability of the eBlock platform as a whole remains the top priority. From the usability experiments conducted in Sections 5.2.3 and 5.3.4, it seems that the threshold block is a more user friendly choice, while the range block seems more difficult for users. However, we must not only consider the usability of an individual block, but how well these blocks are utilized in a variety of applications. Fig. 8 clearly demonstrates that range detection requires a more complex setup when using threshold blocks versus the correspond setup using a range block. While the comparison operation yields similar complexity when either a threshold or range block is utilized, the connections to the threshold block are less ambiguous. Previous simulator-based testing [ 42] indicates that users preferred blocks that most closely matches the desired functionality. Overall, participants who were asked to construct a range operation experienced higher success rates when range blocks were utilized instead of threshold blocks, 53-13 percent, respectively. Similarly, participants who were asked to construct a comparison operation experienced higher success rates when threshold blocks were utilized instead of range blocks, 84-51 percent, respectively. Preliminary results indicate that providing a larger set of straightforward fixed-function blocks, even when overlapping functionality exists, is preferred to provide a smaller set of blocks that require clever uses of these blocks. As the physical platform continues to expand, we will see whether this trend continues.
5.2.6 Open-Ended Project In the previous usability experiments, participants were always provided with application scenarios and their task was to construct the corresponding eBlock system to meet the desired functionality. After participants had a chance to acquaint themselves with the eBlock platform, and see potential uses for these blocks, they were provided with an opportunity to define their own application. Participants were provided with a kit consisting of 11 blocks, including but not limited to a temperature sensor, button, timer, two-input logic, threshold, range, beeper, and LED blocks and given 45 minutes to design systems for home or school use. However, participants were encouraged to develop any system they thought would be useful, and did not need to strictly adhere to the aforementioned specifications. Table 5 indicates a subset of systems created by participants, including a breakdown of system characteristics. Specifically, the number of sensors utilized, the complexity of the system created in terms of the longest path between a sensor and output node, the number of integer and Boolean blocks integrated within the system, and whether the timer, threshold, or range block was incorporated into the end application. Initially, when presented with the open-ended project, most users began with simpler systems consisting of a single input and output block. Such systems included a light detector that connected a light sensor to an integer display, a weather station composed of a temperature sensor and integer display, or a magnet detector that libraries could utilize to detect whether a book was checked out before leaving the premises. Several groups graduated to more complex systems involving both integer and Boolean blocks. These groups were extremely creative and able to invent a wide range of applications, including a missile system which would deploy the rocket at the end of a count down tracked by the timer block. Another group developed an alarm system which would sound a beeper when a prespecified temperature was exceeded for longer than 60 seconds. In observing these participants, we found that they were able to determine their own uses for the building blocks provided, as well as develop an assortment of application possibilities. Among the integer blocks, the threshold and timer block were commonly utilized. While no groups utilized the range block, this is not surprising as the initial usability results showed many users struggled with usage of this block.
5.2.7 Observations and Experiences While platform development and testing is still early, we can see an increase in the confidence level among the student participants and remain optimistic that the eBlock platform has the potential to enhance STEM education. Initially, students were extremely timid in utilizing the building blocks and many students thought because the blocks looked similar, they all had the same functionality. All blocks, with the exception of the timer and integer display, were prototyped to fit into small 3.6" 2.6" 1.1" black plastic boxes. While each building block was labeled and a description of the functionality provided on the back of each box, students tended to ignore these. Instead, in order to determine what each block did, students connected blocks together and observed the resulting action given different input conditions. Furthermore, while block labels were color coded to indicate an input, output, or intermediate block, this difference was not noticed by students who instead tried to connect two inputs or two outputs together. While the connectors were specifically chosen such that these connections were not physically possible, student still tried to force the connectors together. As students worked with blocks, they eventually understood the difference between these blocks types and could explain the purpose of input, intermediate, and output blocks. Additionally, while the small debugging lights (green, yellow, and red status lights) on each block were initially provided to help us test and debug blocks during the development stage, we notice that students also studied these lights to determine the status of individual blocks as well as trace the system behavior to determine at what point the functional derivates from the desired behavior.
After observing and speaking with student and teachers, we found that students were very enthusiastic about creating their own interactive systems with eBlocks. After several sessions, timid users grew more comfortable with the eBlock platform and indicated that they especially enjoyed the open-ended project where they were able to create self-directed systems with varied complexity and functionality. Several students asked how to obtain their own kit to take home and utilize. One participant talked about these blocks so much at home, we later found out that their parents obtained a commercially available electronic kit for this participant to use. While we have not yet conducted formal surveys with student after using the eBlock platform, most students were able to identify tasks related to engineering and a few students even expressed interest in pursuing engineering.
While the initial usability experiments focused on evaluating various block interfaces, we remain cognizant of the need to provide support materials for teachers and their involvement in developing project modules. As we approached several afterschool programs, we found that while teachers embraced the idea of using new interactive technologies within their programs, they were extremely weary of presenting the materials themselves. Most teachers asked if there would be someone from the university to present the materials and oversee students while utilizing the eBlock platform in case any problems arose. Additionally, as we explained the long-term goal of utilizing the eBlock platform within classrooms, teachers were unclear in how these building blocks related to existing course materials. Thus, we have found the importance of providing a comprehensive project booklet to facilitate the introduction and use of the eBlock platform as well as the need to work with teachers to determine the feasibility of using these project ideas in a real-world classroom setting.
Lastly, while students were successfully able to determine the functionality of individual blocks and construct larger systems through trial-and-error, in many instances, there did not appear to be an organized plan to approach the problem proposed. Integrating a section on the basic process of scientific inquiry [ 52], which includes making observations, planning experiments, and how to collect and interpret data, would be a helpful addition to the project booklet. Students utilizing the scientific inquiry method have shown improved retention [ 1], better performance, and positive attitudes about learning science [ 18], and asked more reflective questions [ 9].
The authors are with the Department of Electrical and Computer Engineering, University of Arizona, 1230 E. Speedway Blvd., Tucson, AZ 85721. E-mail: firstname.lastname@example.org, email@example.com.
Manuscript received 21 May 2009; revised 10 July 2009; accepted 23 Sept. 2009; published online 7 Oct. 2009.
For information on obtaining reprints of this article, please send e-mail to: firstname.lastname@example.org, and reference IEEECS Log Number TLT-2009-05-0092.
Digital Object Identifier no. 10.1109/TLT.2009.41.
Anuradha Phalke received the BE and ME degrees in electronics from Shivaji University, Kolhapur, India, in 2004 and 2006, respectively, and the MS degree in electrical and computer engineering from the University of Arizona in 2008. Her research interest includes the development of interactive platforms for use within middle school settings, to expose students to STEM-related topics, and increase interest in engineering. She is currently working as a systems engineer for LSI Corporation in Colorado Springs.
Susan Lysecky received the MS and PhD degrees in computer science from the University of California, Riverside, in 2003 and 2006, respectively. She is currently an assistant professor in the Department of Electrical and Computer Engineering at the University of Arizona. She coordinates research efforts for the Ubiquitous and Embedded Computing Lab, and her current research interests include embedded system design with emphasis on self-configuring architectures, human-computer interaction, and facilitating the design and use of complex sensor-based system by nonengineers. She is a member of the IEEE and ACM.