by Eric Gan | https://www.linkedin.com/in/eric-gan-cmu/ Hello my name is Eric and I’m a first year student in the School of Computer Science at Carnegie Mellon University. This past spring semester, I had the opportunity to work on writing code for the Smart Maker Video Reflection Booth. The reflection booth is a part of a larger NSF Smart Making Spaces project that revolves around how reflection practices support project based-learning. The booth provides students with a space to reflect on their projects and they are able to save these recordings so that they can look back on them in the future. These recordings allow the students to really see how they’ve progressed the course of their projects.
Setup The very first thing that I did was to solve the challenge of how I was going to write code. I needed to code on an Apple device, or a device with the Linux OS installed, both of which I did not have. In order to solve this problem, I decided to set up a Raspberry pi computer for development. It was sort of a hassle to keep switching from my actual computer to the Raspberry pi when I wanted to work and to switch back when I was done, but this arrangement allowed me to actually do my job. At the beginning, I was given template code for a basic program that gave a prompt to the user and then recorded the user answering the prompt. This was extremely helpful because I didn’t have to build the program from scratch. My job was to build upon this template and improve it by refining the existing features and adding new ones as well. Designing a Sign On One of my earliest objectives was to implement a 3-digit passcode feature so that only authorized users could use the program. The way this feature works is that a list of authorized passcodes would be uploaded to the directory of files as a csv file, which is akin to an excel or spreadsheet file. The user would then input their code in the program and the program would check if the inputted code was in the list of authorized codes. If it was, then the user would be sent to the next screen, which was the start of the program. However, if the inputted code wasn’t in the authorized list, then the user would have to try again. After two failed attempts, the program would lock itself for two minutes before anyone could use it again. CHALLENGE 1: My biggest challenge in implementing this was figuring out how the user could actually enter their code because the program had three options for traversing the screen. It could go forward, backward, or select. I knew that the forward and backward would be used to scroll through the digits 1-9. However, the user would have to select three separate digits, and there was only the select option left. In order to solve this, I assigned the select option to moving from selecting one digit to the other. For example, after the user scrolled to the digit that they wanted for the first of the three, they would press the select option and the program would move to selecting the second digit. CHALLENGE 2: Another difficulty I faced was to figure out how to solve the issue of saving the videos into personalized folders so that the person with the code “531” would know which folder contained only their own recordings. In order to solve this, I looked up a bunch of OS commands on how to create folders and save them. When the user entered their code, the program would check if a personalized folder existed already. If it didn't exist, the program would create it. Then, at the end, the program would save the recording to the personalized folder corresponding to the code that was entered. Designing Progress Bar, Save, and Re-Record After that, I quickly implemented a series of instruction slides, and refined the recording screen so that the user could see a progress bar that showed them how much time that they had left, sort of like the time bar for YouTube videos. The user would then be prompted with the option to save the video or record again. The teachers at Quaker Valley wanted to separate the implementations into an initial encounter, a final encounter, and an encounter that covered all the recordings in between. These features covered most of the first and final encounters. However, for the second encounter, I had to work on implementing some extra features. Evidence and Micro-tagging I had to implement a feature that allowed the users to tag their videos with an evidence option and up to three different micro-credentials. The program would prompt the user to select from these features and then when the videos were saved, the program would tag these chosen options at the end of the video names. One of the biggest challenges in implementing this feature was making the interface look presentable. I had to deal with spacing out the selection boxes and spacing the text so that it fit inside the boxes. For the evidence screen, It wasn’t too bad because I only had to deal with four evidence options. However, it became more challenging when it came to the micro-credentials because I had to deal with fourteen options. In order to solve this, I spent quite a bit of time sketching out the screens and calculating proportions so that everything was spaced evenly across the screens. For the code relating to selecting the micro-credentials, I also had to deal with the challenge of the restrictions on the selections. For example, the user had to select at least one micro-credential before moving on to the next screen so I had to write code to check that. There was also the restriction that the user couldn’t select the same micro-credential multiple times so I had to add another check for that. Final Reflections..
My time working on this project has been extremely helpful and I’ve learned a lot of things that I probably wouldn’t have learned if I wasn’t given this opportunity. I’ve never worked with pygame, the python library that provided the modules needed to display the items on the screen, before so working on this project has improved my knowledge in that field. I was also able to apply writing code to a real world product, which was extremely enlightening because this was my first chance to be able to contribute to developing an actual product. Finally, I’ve definitely learned a lot from the other aspects of the project, because this was a cross-disciplinary project, and not just one that revolved around writing code. For example, I was able to learn a bit about design and making the screens pleasing to the users. All in all, this was an extremely helpful experience and I would highly recommend working on projects like this to others.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Blog chronicling project activities and student work.
Areas
All
Archives
May 2021
|