In addition to the learning gains from the lab activities using GLIDE, the par- ticipants also reported on the utilitarian benefits of using it through the project report submissions and the focus group interview.
5.5.2.1 Deployment and Handling the Remote Resources
As a web-based application that communicates with project repositories on GitHub, GLIDE is designed to access user data including website resources on the remote server. In addition, GitHub pages simplifies deployment of website into a single configuration item. This application architecture and configuration support very easy deployment and handling of remote resources. The partic- ipants acknowledged the usability of this feature as one of the direct benefits they can get from GLIDE.
Adam: “You don’t have to upload files to your private server. You don’t have to connect to the FTP. Everytime you commit and push, you upload them.”
Trea: “I would say uploading would be tedious, something like that, because the file names and stuff like that without GLIDE. Because GLIDE is like simple. DreamWeaver is usually easy, but if you’re using it for the first time, it’s not.”
This utility resonates with the teachers’ needs we identified in chapter 4 that deployment requires technology supports for novice students as it involves the basic background knowledge on how to deal with web servers, which can hardly be assumed for them to have. Even though the dataset collected only from the students doesn’t explicitly reveal how teachers would like it, the teach- ers’ needs we observed in chapter 4 suggest that this feature would also help them reduce the managerial cost in teaching.
5.5.2.2 Better Organization of Project Resources
A branch as the unit of work appeared to have assisted in organizing the par- ticipants’ project resources. It makes clear distinction of one’s work from the others, encapsulates relevant files and folders, and labels the work divided for individual contributions.
Bruce: “I’d say I felt the workload is less because it’s all separated into branches. If not, it’s too much to work on.”
Kaleb: “There is also that part where that’s like time management for work efficiency. We know when we need to get things done. We learned to manage our time much better.”
Project 2 and project 3 tasked the participants with the same lab activities with the same levels of requirement, so there are no clear reasons to say the workload actually reduced. One possible interpretation is that Bruce’s com- ment on the perceived workload implies the participants might have benefited from better organization of project resources that the Git workflow of GLIDE approach provided. Moreover, Kaleb’s comment implies that this practical ben- efit might have also improved their collaboration process by clarify the tasks already done and to do next for the collaborators. Work efficiency and time management that Rick mentioned were not the direct goal this study tried to achieve through GLIDE approach, however, the way GLIDE and the feature branch workflow transform student tasks suggested this positive impact on their collaborative lab activities.
5.5.2.3 Tools for Peer Review
The participants reported that the combination of GLIDE and GitHub provided usable and useful tools for peer review, which they think improves the quality of their work.
Rick: “We’ve done separate pages on our own. Sometimes, we need someone to look over our code and ‘oh, you have a mistake here. Fix this and that’, a peer edit, basically. You’re advised to make your pages better.”
Interviewer: “What was the most memorable thing about project 2?” Derrik: “For everyone in my group, including me, it was nice that everyone actually contributed. We communicated [on GitHub] and used GLIDE.”
The specific tools that the participants used for peer review include pull re- quest to notify when they’re ready for a review (on GLIDE and GitHub) and the merge conflict editor (on GitHub) to make changes in the shared code. In project 1 without GLIDE, review was only possible by visiting another collabo- rator’s computer without any systematic tools support. This also seems to be a practical support for peer review or peer instructions for teachers, judging from the teachers’ report that they actively employ peer instruction to teach lab ac- tivities in chapter 4. Derrik’s comment shows that the combination of GLIDE and GitHub worked well as tools for peer-driven code review. They were able to communicate using the editor on GitHub in resolving merge conflict for inte- gration, while writing individual code on GLIDE. We argue that our approach presented a rare example of natural integration of peer-driven code review for in-class collaborative lab activities.
These examples show the practical assists in performing lab activities that the participants were able to directly get from GLIDE approach and the Git workflow. This supports the argument that GLIDE approach is feasible to im- plement in actual classrooms without demanding too much to the students in terms of making adjustments in the way they perform the tasks. As a scaf- folding tool for novice students, GLIDE seems to have provided the sufficient affordances and ease-of-use as well as the effectiveness in the task performance.