Computer Science (CS) is a growing field in our modern world and will continue to shape our society. However, CS is not always welcoming and inclusive to students who are interested in pursuing a career in CS.
Oftentimes, the software and Integrated Development Environments (IDE) act as a barrier to become a member of the field as a whole due to inaccessibility and complexity of User Interfaces (UI).
To foster the interest of talented students, we must improve the accessibility and inclusion of introductory CS courses and beginner software.
Background
GOAL: IDENTIFY A FOCUS.
As part of the task, we needed to identify an issue within Grinnell College's Computer Science (CS) Department and design a solution for it. Within the group, we each proposed topic ideas and after some deliberation, we decided to focus our work around barriers to entry for computer science.
Research Phase 1
GOAL: IDENTIFY A PROBLEM.
In the beginning, we each searched for research papers and news articles on potential barriers of entry. After browsing through dozens of articles, we combined our findings and combed through the major pain points. Some discoveries included:
- Accessibility barriers for persons with disabilities
- Confusing Integrated Development Environments (IDE)
- Complex and unintuitive error messages
- Unstandardized programming syntax and formatting
With these concepts in mind, we dove in to observing Grinnell's entry Computer Science Course, CSC-151.
Research Phase 2
GOAL: IDENTIFY A PROBLEM.
We observed the introductory CSC 151 class on Functional Problem Solving. In this course, the students are working with the programming language Scheme in the IDE DrRacket. It was safe to assume that these students are relatively new to programming since they are in the introductory computer science course, but even if they had background experience in coding, Scheme is a fairly obscure and old language so no student was expected to have been previously exposed to the language.
The class was structured with the professor going through the reading assigned for the day’s class, answering any questions, followed by the students utilized pair programming for the daily lab. Each group began with a designated driver and navigator and would switch off every 15 minutes or so. We had two of our group members walk around the class and observe different groups and their methods and approaches for working through the lab. One team member focused more on the code and how students would go about working through conceptual problems while the other team member focused on emotional reactions and how the students utilized pairprogramming.
The first need we sought to investigate was using good programming strategies, particularly relating to commenting, documenting, formatting, and variable naming. Secondly we hoped to investigate how to address students’ struggle to remember function names and the parameters these functions take. The final need we addressed is the accessibility of the introductory course, specifically in regards to people with disabilities
After sitting in multiple classes as well as interviewing students, we confirmed the problems that our online research had presented. We saw students struggling to interpret the errors presented by the IDE DrRacket, having difficulties navigating the IDE, as well as constantly typing the wrong syntax. Although none of the students in the class identified as having a disability, we presented the programming software to students from Disability Resources and also found that DrRacket had severe accessibility issues.
Insight: We were quite surprised to see our online findings accurately reflecting the issues faced by Grinnell College Computer Science students and were interested in investigating further. Although satisfied with our data collection, I personally would have loved to have a larger sample size as Grinnell College only offers two sections of CSC-151 with around 24 students each. I also wish that we had the opportunity to investigate if the issues we found were directly related to DrRacket or if they were applicable to other IDEs.
Ideation
GOAL: FIGURE OUT HOW TO SOLVE THE PROBLEM!
To assist us with accurately targeting our users, we created four user personas.
- Persona 1: April (template, lazy)
April enjoys finishing the assignment as fast as possible with as little effort as possible. When they get stuck on a problem they would rather look up the solution online rather than going back and reviewing readings or past class work. They would not mind going online and finding the chunk of code that does what they want: they may not understand it clearly, but if it works they are happy. Next to someone who understands things better, they lose confidence and tend to accept the solutions without understanding it.
- Persona 2: Julius (template, hard-worker)
Julius does the readings the night before their upcoming computer science course, and make sure that they have a good understanding of it. If they have some free time, Julius might test the newly learned templates given in the reading and make sure that they have understood its limitations. Next class, Julius is well prepared and they feel confident during labs. When working on a code, Julius wants to think through it clearly and predict the result, before actually running it. Julius enjoys being a little challenge and to build upon previous works. When working on a problem, Julius thinks of the templates they learned from the readings, and utilize the same format. When getting to more complex topics, such as helper recursion, Julius might fall into the trap where they call the helper recursion on the wrong variables, because of blindly following previous templates.
- Persona 3: May (creative, lazy)
May enjoys doing minimal work (eg. no reading) for maximum understanding and creative problem solving. They like to look at existing code and learn the logic from the example someone else made outside of class. They enjoy solving a problem without doing much work and by relying on their observations. May is a strong observer above all else but they strengthen their skills by doing as opposed to viewing. They also like procedures that can accomplish large tasks such as map, let, let* because they inspire creative and efficient processing. They want to be concise but creative with their solutions. They also dislike elaborate documentation because they value their own time and believe short and sweet is much easier to understand than over wording.
- Persona 4: June (creative, hard-worker)
June is fascinated with computer science and is driven to find out everything about computer science. She does all of the readings before class, is actively engaged during class time, and goes above and beyond with programming assignments. This means that she completes the assignments, but does not stop there, working towards finding alternative solutions and coming up with some of her own. She loves expressing her creativity when programming and enjoys the experience of coding.
Using these personas, we began ideating potential solutions. The solution we finalized on was twofold:
- Creating an accessibility page for DrRacket
- Designing a Function Finder extension to assist with DrRacket
Prototyping
GOAL: CREATE AN MVP
We developed three separate MVPs of the features we decided to focus on: an accessibility page and a function finder extension.
Function Finder
In our first draft of Function Finder, we drew out a sketch of our extension. The main changes to the IDE we implemented were adding a search menu on the right hand side to allow for users to search through the documentation of the programming language. Participants can call the Function Finder through the keyboard shortcut, by selecting it under the view dropdown menu, or by accessing it through the tool bar. Participants can search by the name of the procedure (eg. map), or by types (eg. from list to number). Then, when the user searches, Function Finder returns all possible results for procedures as well as a link that brings them to the DrRacket online documentation. Finally, the user can quickly browse through the 5 Ps of Documentation which were taught in the programming class:
- Parameters: what inputs the function used and their types
- Purpose: the purpose of the function
- Produces: what outputs are produced by the function and their types
- Preconditions: conditions which the inputs must follow
- Postconditions: conditions which the outputs must follow
These were used to help students gain a higher level understanding of the program and its purpose, an essential element of growth.
Insight: Here, we primarily wanted to portray the options given to users and have something we could quickly reiterate on. We then animated the UI through Powerpoint to allow for users to test.
In our final draft, we created a high-fidelity mockup of the Function Finder extension for additional experimentation.
Accessibility Menu
To help alleviate some of the issues faced by students with disabilities, we focused on giving as many customization options to users as possible. Examples include adjusting the font or UI size, changing the color scheme for a better contrast, text to audio options, and even the option to connect to a braille display.
Users can access the accessibility settings through the toolbar dropdown menu (view>preferences>accessibility) or a small blue eye icon in the left bottom corner. Through our accessibility and preference settings, users can change the font and UI size, have options to use text to audio and high contrast, as well as connect a braille display. For UI scaling and font sizing, the user can adjust them in a convenient way without having to access the preference tab:a font size slider at the bottom left hand corner. This way the user can quickly modify the font size to their preferences. In addition to these preference options and improvements, users can set some of these upon installation. When one installs DrRacket, they are given the option to theirFont Size, UI Size, and Color Scheme which acts as a guide to inform users that they can indeed modify these settings if they so choose in the future. To assist them in selecting their options, a small text box is used to provide a live view of the current selected options.
Insight: I wish we had more students who identified with a disability that could give us more input and guidance on how to better improve our accessibility designs. If we had more time, I would have reached out to disability non-profits or organizations for interviews and concept feedback.
Testing
GOAL: TEST THE MVPS
For experimentation, we created a playbook of questions for each prototype designed. We then collected data from participants to test the prototypes by asking them the designated questions and then documenting the methods and results. The questions included the following:
- Is it helpful to have accessibility features in the toolbar rather than deeper inside a menu?
- Should we show users the full documentation and an example for each function?
- How could the user access the Function Finder -- with a shortcut, toolbar, or a button?
- Would it help if users could select accessibility presets during the installation process?
- How can a user search for different procedures -- is it just by the name of a procedure, can they narrow down search results based on what type a procedure takes in, etc.?
From our testing, the user did not use the shortcut through the eye icon to access the settings. Instead, they accessed it through the toolbar. The user had confusion of the functionality of the icon as well. They played around with high contrast mode and made inquiries about the braille display. When it came to the settings upon installation, when they got to the preferences page, they took a bit of time looking through all of the options. The only two questions they asked was if these preferences could be changed later and if the font size could be changed to a more customizable, scalable format.The button was the users preferred way of accessing Function Finder, and the shortcut was the second favorite. It seemed to be a good idea to have the basic information of a procedure to be shown only and have links to find out more information. However, Function Finder can fail if the user does not know the correct type they are looking for. Users often had a hard time figuring out the correct type for the input and output to get to the desired documentation. Figuring out the possible types was also hard for users.
Insight: Similar to the problems brought up earlier, I believe our solution could be improved through multiple stages of testing with a larger sample size. This was especially the case for testing the accessibility features because we did not have students who both identified as a person with a disability and as a computer scientist. With more time, we could have reached out to other organizations and disability advocates within the computer science realm for feedback.
Our proposed function finding interface is intended to mitigate the difficulties students face with recalling all of the functions they have learned and, instead, allow them to use recognition to identify which function they need. To further increase the efficacy of this tool it could be synced up with the learning students do in class and would only display functions covered in the class so far. An alternative to this is to include an option to filter for functions only covered so far in the class but still allow students to access additional documentation if they choose. This is intended to help students get into the “flow state” for programming as it should eliminate most of the time needed to look up function documentation in a web browser and will decrease the memory load experienced by new students. Our proposed modifications were developed through need-finding, ideation, prototyping, and testing stages to address our goal of making the programming environment