CODELINK

Learn, Collaborate, and Compete Against Others

Overview

Course

This project is the final project for COGS 123 (Social Computing). During this course, we analyzed how we can implement social interactions & experiences in a computing experience. Given some social setting, our overarching goal was to allow people to connect with one another and have a meaningful shared computing experience.

Problem

Websites designed for coding practice, like LeetCode, cater primarily to individuals who already possess a sturdy coding background. Additionally, existing coding platforms offer limited opportunities for social engagement. To address this gap, our team developed a prototype for CodeLink. This platform fosters a collaborative coding space that combines elements of competition and practice-oriented matches. CodeLink was designed to inspire and motivate novice programmers, encouraging them to learn together in a more interactive and supportive environment.

Literature Review

“The Costs and Benefits of Pair Programming” by Alistair Cockburn and Laurie Williams

Problem solving time decreased when working together on programming and that communication was key. This resulted in a statistically significant difference in collaboration versus individual work on a problem.

“Improving the CS1 experience with pair programming” by Nagappan et al.

Beginners that paired up were able to produce better results compared to solo programming.

Research on User Insights of Programming

Our Main Questions

What coding languages were people most familiar with?
What challenges did people face while programming?
What features would be useful in a platform for learning coding?
What competitive environment format would people prefer?

Participants

Convenience Sampling
29 Participants

Findings

Java and Python

Around 20 of our participants were familiar with both Java and Python - this helped us choose a default language for our prototype.

Motivation and Learning

Around 20 of our participants struggled to find motivation and learn new concepts - this gave us insight on creating a collaborative environment to keep one other accountable.

Tutorials, Collaboration, and Mentoring

Users wanted some way to learn to code with others, along with some assistance from outside sources if needed.

Live Competitions

Over half of the responses preferred to have live competitons in which they could compete with others in real time.

Research on Competitive Market

EliteCode

EliteCode aims at gamifying LeetCode by allowing users to play ranked 1v1 matches for Elo. CodeLink differs from this, as it is collaborative and introduces unique ways for users to work together to solve problems, such as switching between roles (Driver and Navigator).

LeetRooms

LeetRooms aims at collaborative coding with others through text chat. CodeLink offers a similar collaborative environment, with the main difference being that it offers a competitive aspect as well. Unlike LeetRooms, CodeLink is geared towards beginners that want to better their skills beside and against others at a similar skill level.

Design Process

User Flow

A typical user flow involves the user either selecting to play competitive or practice. Both formats would lead to the user selecting their difficulty level, as well as deciding whether they want to play with a friend or a random person around the their same skill level. Then, they select their programming language and press play. Once both parties are ready, both users on a team start off with either being a driver or navigator, switching roles after every problem. By the end of the experience, users learn from each other and are able to hone their skills.

Low-Fidelity Prototypes

These were used to outline the user flow, as well as how we might iterate our ideas on the final prototype.

Home Page

Difficulty Page

Competitive Lobby

Driver Role

Prototyping Round One

Link

Description

We had a total of 10 participants and split them up into two groups of five. We provided problem links via repl.it, an online collaborative integrated development environment (IDE). Each team chose one device to work and collaborate on. They were given two beginner-friendly problems to solve in under 15 minutes, and the first team to finish was declared the victor. (Example problem on left)

Feedback and Observations

The feedback we received was mainly concerning our collaborative approach and the team size. Through our observations, the large group sizes made it difficult for people to communicate ideas. Also, if everyone was collaborating on one screen, it was physically difficult for the people furthest to help out and learn. We took these insights and made the necessary changes in our second prototyping session.

Changes

Switching Roles

“I think each person could have a different role whether it be doing one section of the problem or debugging…”

Team reduction to 2

44.4% of the responses felt that “less teammates” would be better

Incentive for winning

“Just raise the competitiveness by including other features that way we don’t just hear it, but feel it a lot more…”

Prototyping Round Two

Link

Description

This time, we iterated our prototype from round one and chose to split up our 8 participants into teams of two. This decision was made to better support and facilitate ideas and communication about the problems. Next, we implemented a leaderboards system (as seen on the right) where teams could access problems and see how their progress measures against other teams in real-time. After every problem, users marked the corresponding box (hints or without hints). The time limit was 10 minutes, and users switched between driver and navigator roles after each problem. The team with the most points at the end won candy!

Feedback and Observations

The feedback was positive with people really enjoying the team reduction and incentive change. We also noted that in these group sizes, people were able to communicate more efficiently and felt more like a team. Another observation we had was that people forgot to switch roles after every problem, which we took note of to emphasize in our final prototype.

Changes

Practice Matches

“...We were more incentivized on completing it instead of someone learning it”

Shorter Descriptions

“The coding problems were not so difficult, but they take time to read”

Strict Rules for Roles

57.1% of people said switching roles helped learning and we noticed some teams forgot to switch after every problem

Final Prototype

Home Page

Users can access this screen at any point throughout their time on the website, whether that would be in-game or not. The top left button serves as a way to navigate back to the home page to then further access our main features.

Skill Level

After either entering ‘Play’ or ‘Practice’, users are prompted to select their skill level, with each difficulty containing a short description of what they entail.

Competitive

Users play matches that are in a two versus two format. They are able to select the language they want to play in, as well as whether they would like to queue with a friend or random person. Users play to compete for a spot on the leaderboard for rewards.

Practice

Similarly, practice has the same features as competitive, but caters towards people who just want to learn in a very low-stakes environment.

A Closer Look at Competitive

Queue

After clicking "play", users are prompted to a queue. In order to proceed after matching, all players press "ready" to start the match. Information about the match is given, and users can communicate with each other via text and voice chat. Roles are displayed, along with a reminder description for each.

Driver and Navigator

As the driver, you are in charge of writing code with guidance from your teammate. People are able to chat and talk to each other via the bottom left chat area. As the navigator, it is your role to closely follow along and help "steer" the code in the right direction. Navigators are locked from typing code directly, as shown with the icon next to "</> Code". Hints are also available at a very slight point deduction.

Leaderboards

After competitive matchers, rating is granted based on your performance. The new rating will be reflected onto the leaderboards, with top finishers receiving rewards.

Challenges

Although many users had taken some beginner course of a programming language, most of them were hazy on the syntax. That made it difficult for some teams to work through problems without additional help from outside sources.
Some users forgot to turn off repl.it's AI code helper during the prototyping sessions which undermined the competitive aspect. Although repl.it was a convenient platform to host our collaborative environment, its extended features were excessive and ultimately belonged outside our scope.
Our problems were geared towards Python only, as it would have been difficult to port and moderate problems across various languages in our sessions. Also, we felt it worked best to choose the language with easier syntax that most people were familiar with. Realistically, in our final prototype, we would allow people to choose whatever language to play in.

Social Insights

We observed during the prototyping sessions that paired-programming was not so common among university students. They were unfamiliar at first with how to work together, even though they knew each other already. However, they were quick to adapt to our collaborative approach. In the end, they actually preferred working in teams to solve problems.

Reflection

Our research revealed strong interest in a competitive and beginner-friendly learning environment, catering to beginners and fostering team-based learning on pair-programming principles. The two prototyping sessions helped a lot in deciding what iterations to make. Even with our relatively small number of participants, all feedback received was valuable.

Contributions

Jacky Huang - I worked on the design process which includes low-fidelity prototype, high-fidelity prototype, and the user flow. I also worked on the research for our topic and competitive market. I also worked on the online portfolio and Phase 4 slides.

Jason Artley - Worked on initial project ideation, competitive research, and helped with setting up & designing both prototyping sessions. Work also involved closely working with teammates on the online portfolio page and final presentation.

John Hoang - Worked on Code problems and hints, tweaks and changes to the project path, as well as the online portfolio

Ryen Huang - Worked on project ideation, topic and competitive research, and helped facilitate prototype testing.

Charlie Nguyen - Worked alongside Jacky to work on the low and high-fidelity prototypes. Aided in user research and prototype iterations.

Links

Page updated

Report abuse