This project, including this writeup, was a combined effort between Celine Lee, Bruce Zhang, Stanley Ren, and myself.

Whether you’re moving to a new city or trying to change up your daily routine, volunteering is a great way to meet new people, build new skills, and engage with the community around you. However, trying to find the right place to volunteer is tough, and all the scattered information across the internet and bulletin boards can be overwhelming. To solve this, InvolveMe is an app that effortlessly connects you to organizations and other fellow volunteers, making volunteering more fun and social." —from the InvolveMe promo video

As described in the video, InvolveMe fills the communication gap between aspiring volunteers (possibly like yourself!), other fellow volunteers, and organizations. We felt that younger demographics, such as students in high school or post-secondary, enjoy being social and engaging in activities that broaden their experiences and skills. Volunteering is a prime example of these kinds of activities, but the difficulty in finding a volunteering role of interest is a big barrier to overcome. Having a platform that consolidates these opportunities while providing useful discovery features will reduce the friction to start volunteering, ultimately encouraging more youth to get involved. Our end goal is to make volunteering more social, connecting like minded people to make a bigger impact for the greater good.

Anticipated Users

We identified three main user groups for our app, and created personas to associate each of them.

Persona A: University Student

Being university students ourselves helps us understand the needs of others in this category; having moved to Waterloo for university from somewhere else, we all sought a sense of community, and felt that volunteering and getting involved was one of the best ways to do so.

Persona B: High School Student

We chose to include this persona since in Ontario, high school students are required to fulfill 40 hours of volunteer work in order to earn their secondary school diploma. This app will be very helpful to them for finding a volunteering position in order to get certified or some other kind of acknowledgement.

Persona C: Outreach Coordinator for a local food bank

Organizations seeking volunteers often have employees working several duties; in this case, the outreach coordinator is responsible for not only recruiting volunteers, but may also be occupied with finding sponsors, marketing the food bank to donors, collaborating with supermarkets and schools, and so on. This persona embodies the non-technical user; that is, whereas an HR professional may be familiar with job board sites such as Indeed, a persona like this one probably would not.

User Interviews

To get a good sample of data, we aimed to interview an equal number of potential volunteers and organization members who are familiar with the recruiting process. With this in mind, we ended up interviewing 4 people:

1. 4th year Health Studies student
2. 4th year Computer Science student
3. President and Personnel Manager at Waterloo Chamber Orchestra
4. Director for Canadian Glass and Clay Gallery

For the students, we decided to ask a series of questions focused on the following three topics:

1. Their interest with getting involved with the community
2. Prior experiences with searching for volunteering roles
3. Relation of volunteering work to their everyday life

For the coordinators, our questions focused on:

1. Their role in the organization
2. Value of volunteers
3. Experience with their process of recruiting volunteers

Each one of these interviews provided very insightful findings. From interviews with students, there was a general consensus that volunteering grows both professional and soft skills. In addition, if the volunteering role is relevant enough, it can also serve as a great practical supplement to their area of study. For example, the Health Studies student said that her volunteering experience gave her a better view into the world of social health, an area she is very interested in. Another common theme was that current methods of finding volunteer jobs make the task difficult. Each student had a different source of information they sought from, but all said that the variety of jobs were lacking.

For volunteer coordinators, social media can be a good way to reach potential volunteers, as it is cheap and can reach a wide audience. However, it is difficult to target any particular audience for more specialized roles. Coordinators also said that their volunteers contribute to the organization’s image, so it is important to find people with matching values. In addition, social media is only a tool for outreach and not a comprehensive solution for recruiting volunteers, so another solution is needed to facilitate registration, making the process fairly complex.

Affinity Diagrams, Storyboarding, and Crazy 8s

We used affinity diagrams to identify key issues amongst all our interviewees. Through this process, we found many issues relating to the search process of volunteer jobs. For example, many people wanted more info on how to get involved, find something that matches their interests, and spend less time searching.

Later on, we incorporated these themes into our storyboards, where we brainstormed different scenarios where people use our app. Some of our storyboards can be seen below.

Envisioning these scenarios allowed us to better understand our use cases and identify key areas for our app to tackle.

1. Help volunteers find jobs they are interested in, possibly to fulfill their volunteer hours.
2. Provide more social features to connect users.
3. Provide features to organizations that would let them recruit volunteers efficiently.

For each of these key features, we drew Crazy 8 diagrams to brainstorm possible UI designs.

Work Models

Work models are built to describe work from the point of the people interviewed. There were various models we could choose, but we opted to use the flow model and cultural model.

The flow model defines how work is broken up across people and how people coordinate to ensure the job gets done. The model could help us understand the current volunteering and recruiting process and identify areas of friction that can potentially be solved by our app.

The cultural model represents the external influences that can affect a user's perception and adoption of the app. It also maps out how users may be connected socially, which is helpful for understanding how to better design our social features.

Initial Design Ideas

Based on the information we gathered from the user interviews we were able to gain a general understanding of what the users were looking for and their expectations for an engaging app. We then developed some initial sketches and wireframes of the application.

The organization profile page shows the organization’s name and logo. There is a follow button that the user can click to subscribe to updates (such as new events). The user can also scroll down to see a schedule of upcoming events that the organization is hosting, and other status updates. At the bottom, there is a map that shows the organization's address and contact information.

The user profile page similar to that of LinkedIn's, where volunteer recruiters are able to see a user's skills, bio, past experiences, accolades, and more. However, since volunteering is meant to be fun, we also added a button that would take you to your badges and accomplishments where you can keep track of how much you’ve contributed to your community.

The volunteer role search page differs from the event search page, since here, users would be able to find a recurring volunteering role (rather than a one-off event). Designed for scannability, the list in the main view lists the role/job title, organization, level of commitment and distance, so that users are able to quickly see what kinds of volunteering roles are available. If a user is interested in a role, they could tap on the role to see more details about the position.

The social feed mirrors the homepage feed of websites like Linkedin or Facebook. It gives an overview of everything that is going on, from both organizations, friends, and people you follow. It keeps users engaged and keeps friends connected to each other by showing updates on what they’re up to. For example, it shows when people register to attend an event in order to encourage their friends to join in as well.

Paper Prototype and Evaluation

We wanted to simulate and test some features that were most important, including the social feed, event listings and search, and sharing. We tried to be creative and have some fun in the process. For example, we used long strips of paper and a device frame to simulate scrolling, letting us easily create longer screens. We also folded paper to create pop out buttons and drop down menus.

Our goal with the paper prototypes was to identify how intuitive our features were to use and understand. We asked our testers to perform various tasks, such as browsing the social feed and finding content on it, searching and signing up for volunteer positions, and checking their medals.

Overall, the results of our evaluation were promising. Testers thought the prototype felt user-friendly and straightforward. They performed most tasks successfully, save for a few issues such as unexpected placement of some features, and nomenclature. The most prominent issue was the confusing surrounding recurring and single-time volunteering roles, which we named "roles" and "events" respectively. This was most likely because people envisioned events also containing roles, rather than a strict distinction. Some of the problems may be caused by the low fidelity design's missing colours and detail. Overall, these evaluations provided us with constructive feedback and directions for future improvements.

Design Iteration

In response to the results from our paper prototype evaluation, we performed a few changes.

Categorizing opportunities & simplifying filtering

We iterated through different designs to explore ways that volunteering opportunities can be presented to users in hopes of solving the confusing between recurring and single-time volunteering opportunities.

At first, we had a single tab for the volunteering page, where recurring and single-time roles were separated using a selector at the top of the screen. Since through testing, people were confused about the distinction between the two types of roles and the purpose of the selector, we decided to list them directly as separate tabs in the bottom tab bar. While this made clear that there is a distinction between the two volunteering types, users were still unsure about what the difference actually was. Finally, we decided to combine both types under one tab with extended filtering features that describes the nomenclature.

We also decided to surface some filtering options outside the filtering modal to make it easier to set filters and to see which filters are currently set. This also helps with making the two volunteering types clear, as the type selector is the first surface filtering option.

Surfacing medals

We also made medals a more prominent feature rather than embedding it under the user profile. We added a preview of the upcoming medals that can be unlocked to further encourage students to volunteer.

Agenda feature

Finally, we also added an agenda feature to help users keep track of their upcoming commitments.

High Fidelity Prototypes and Evaluation

While paper prototypes were very useful in testing our major design concepts and decisions, our goal for the high fidelity prototypes was to test our more intricate design decisions, such as the colour scheme and design of UI components.

In terms of colour theory and the use of colour, we chose our primary colour to be orange, which invokes a sense of cheerfulness, friendliness and trustworthiness. As for our iconography, we chose a more rounded icon design which encourages users to interact with our app more (than icons with sharp corners and edges).

Heuristics tests

The four heuristics that we tested for are:

1. Visibility of system status
2. Match between system and real world
3. Flexibility and efficiency of use
4. Aesthetic and minimalist design

We chose these heuristics because we believed that these four would be the most critical in accomplishing our overall goal – engaging volunteers. We’ll go into more detail for each heuristic below.

1. Visibility of system status

We decided to test for this heuristic because our app deals with a lot of interactive data – for instance, on the social feed, users can interact with the data on the feed by sharing it. We wanted to ensure that our UI reflected user interactions as they expected.

2. Match between system and real world

We want to ensure that our choices of taxonomy and iconography make sense to users, since a lot of it was based on assumptions. Furthermore, based on what each part of the app is named, we want to ensure that are able to see what they had expected to see.

3. Flexibility and efficiency of use

One of our primary goals is to facilitate the networking between organizations and volunteers. In order to achieve this, we must be efficient in communicating the info and allowing users to perform the tasks needed to achieve the tasks they want to perform.

4. Aesthetic and minimalist design

Very high-level, since the goal of our app is to "strengthen cultural organizations", we designed our app to be as friendly as possible with our choice of colours, use of images and rounded corners. We depend on the "aesthetic design" heuristic to evoke a sense of community and friendliness to our users. Furthermore, information users want to see should be organized well so that it is easy for users to find exactly what they’re looking for.

Results

Overall, the results of the heuristic evaluation were fairly successful. Only minor changes to be made were identified.

1. Visibility of system status

Bad: No indicator that tells you whether a post has previously been shared or not.

Good: Users were able to easily check that they were confirmed to volunteer at a given event.

2. Match between system and real world

Bad: Icons were sometimes inconsistent with iOS standards; 'achievements' is a more recognizable word compared to 'medals'.

Good: Easy to learn and use since design patterns used are similar to apps already used by testers.

3. Flexibility and efficiency of use

Bad: Order of "Volunteer" and "Feed" on navbar should be swapped.

Good: Call to action is evident on all pages; overall narrative of app is easy to follow.

4. Aesthetic and minimalist design

Bad: Somewhat cluttered due to the abundance of information.

Good: Friendly-feeling app that promotes interaction; consistent aesthetic experience.

Cognitive walkthrough

For the cognitive walkthrough, we prepared a series of tasks for the testers that covered all main features of our app. The tasks are as follows:

1. You are exploring the app for the first time, and you want to see organizations and events you can potentially volunteer at
2. You notice that you accidentally made a typo in your name; edit it so that your name is spelled properly.
3. You see a post that you think that your friends will enjoy. How would you share it with your friends?
4. You are very interested in an organization called WarmWorkers. Check to see all of the upcoming events scheduled that you can volunteer for.
5. You have some time this weekend to volunteer. Sign up for some positions to volunteer for this weekend
6. Now that you have signed up for some events, you want to see a summary of your upcoming events. Check the list of events you have signed up to volunteer for
7. You’ve successfully signed up for your first volunteering gig and earned a new medal! How would you see the other volunteering medals that you could earn by being more and more involved in your community?
8. You realize that you have a lot of homework and now will be unable to attend one of your volunteering positions. How would you cancel your attendance?

Results

For the most part, our testers expressed that our app was easy to use. However, there were two main difficulties that our testers had while using the app. First, when asked to sign up for positions to volunteer at this weekend, the tester correctly went into "Volunteer" tab but thought that the events under "This Week" were things that the tester had already signed up for. Furthermore, another tester mentioned that in the events screen, they can’t see which of their friends are volunteering, an info which is displayed on the previous screen.

Changes

Based on our feedback from both the heuristic tests and cognitive walkthrough, we decided to make the following changes:

1. Iconography changes

To meet user expectations regarding iconography, we decided to change the icons used in two contexts to make their action more clear.

Share button: we decided to use the icon that more accurately reflects iOS iconography as opposed to the share icon as seen on Facebook.

Agenda button: the hamburger menu icon that used to be at the top was meant to bring up a larger date picker; however this icon used did not accurately reflect this action, so we decided to change it to a calendar icon.

2. Contextual share button

To make whether or not a user has shared an item with their friends before, we decided to disable the "Share" button if they have already shared it.

Although we got more feedback, we decided not to change our prototype based on all of them, since we felt that the results were somewhat skewed due to testers not having more time to become familiar with the app.

Closing Thoughts

Throughout each step of the design process, we made new discoveries that allowed us to better tailor our product for both aspiring volunteers and organizations. However, since it was much easier to reach young adults for their input, that demographic is the one that we engaged with the most in the process. We were able to achieve a good understanding of the needs of that user group and refine features tailored to them as a result. The same couldn't be said for organizations, which ended up taking a back seat in the design process.

While we had a good understanding of our user group of young adults, we were still lacking information about what influences their decision in choosing where to volunteer. We made a lot of assumptions about what information to show, and in what order, in the Volunteer page. In the future, we would expand on our areas of research through our interviews, and put more effort into continuously engaging representatives from organizations as well. There were also features we discussed earlier on in the design process but didn’t have time to include. For instance, the feature we highlighted was the ability to allow users to print out a certificate of their volunteering involvement. This would have added a lot of value for certain users, especially those in high school needing verified volunteering hours. We should have focused more on this feature in retrospect.

While we felt short in some areas of the design process, we still felt that we achieved our original mission of fostering a community for volunteering and minimizing the friction for young adults to get involved. Even for us personally, having an app like this when we were starting undergrad would have been invaluable.

My 2A term surprisingly felt less demanding compared to first year. Don't get me wrong, there were still moments where I was under stress to finish assignments or understand alien-like concepts, but overall I felt more relaxed and focused. With this term behind me, it's a good time to write about the courses I took.

CS 245

This is probably the horror course you read about on UW Flow. While there could be improvements to how the course is taught, the material itself was still interesting. Some of the weekly assignments could be finished relatively quickly if you kept up with the material, and they were also great practise for the midterm and exam. Tip: if you find some of the course slides confusing, try going through Lubiw's slides from a previous term. They're more concise and easier to understand.

CS 246

A big step up from CS 136. You now graduate from C to C++ and get to learn all the quirks that the language has. A lot of useful content is covered in this class, such as the programming design patterns. Each assignment is split up into two due dates, where the first is for the test cases and the second for submitting the actual code. Don't underestimate the time required to do the test cases, some of them can be very tricky to find. The midterm was also difficult and long (I think the average was a 62%), but the final was fair. Also be sure to take good notes since they'll be what you study from. I was lucky to have Nomair for this course. He's the best.

Stat 230

The beginning is almost the same as what you learn in high school data, but the content ramps up quickly from there. There's also no weekly assignments, but the 3 tests and 2 midterms make up for it. Be sure to keep up with the content or it will be difficult to catch up in time the end for the final (which is kind of what happened to me).

Psych 256

Surprisingly applicable to CS for a psych course. You get to learn about the different ways of representing the mind and intelligence, and how each of these approaches can relate to one another. Unlike most psych courses at this level, the tests are comprised of only short answer questions, with one short essay question at the end. I personally found the content more interesting near the end when we started discussing neural networks. This course is great for those who are interested in AI.

Psych 207

Some overlap with psych 256, but with much less attention on CS topics. There's a greater focus on cognitive disorders, experiments, and case studies. For some reason, my prof glanced through most of the physiology content in the textbook, which just so happened to the topics I was most interested in. Despite that, the course was enjoyable all around and a great compliment to psych 256.

I must admit, I didn't expect the job application process to start so soon. I mean, I knew exactly when it would start according to my co-op sequence, but it just felt like time passed much faster than it should have.

The application process began two weeks into my 1B term, so I luckily had time over the break to brush up my resume and short-list a few companies. There were only about a hundred jobs targeting the Computer Science and Software Engineering disciplines on Jobmine at this point, but that was enough to get an idea of the skills companies were looking for. I also planned to read McDowell's Cracking the Coding Interview to prepare for any technical interviews that I could come across. I never got around to doing it though, which turned out to be a big mistake that I'll talk about later.

Besides the things I did myself to prepare, CECA also provides a lot of services to help with the job search, such as resume critiques and mock interviews. I never got around to using these services though. What I did take attend regularly are Employer Info Sessions, which I encourage all students to take a look at, co-op or not. You get to learn a lot about companies and get an inside look on what it's like to work there. They also often talk about the work of previous co-ops and sometimes even share interview tips. Of course, the free food is a plus. I was lucky to have the option to view these sessions in my first term when I wasn't applying for jobs, since most of the sessions were scheduled after the job application deadline for the first round.

When the job postings opened, I used up almost all my applications to apply for more than 50 jobs (openings from IBM and Blackberry didn't count towards the quota). This was much more than originally planned, but it turned out to be a good strategy since there weren't many postings I was interested in in the second round. I also pushed my luck and applied for a few "higher up" companies, such as well-known startups and Silicon Valley companies, just for the slim chance that they might give me an interview.

As it turns out, that's what happened. It also happened to be that the interviews of these companies were the most technical (no surprise, really). You can probably see why not reading Cracking the Coding Interview was such a big mistake now. I performed so badly on one of them that I wouldn't be surprised if the company would straight up toss my resume out the next time I applied. Thankfully, my other interviews went much better, mostly because they didn't nearly have as many tricky technical questions.

In retrospect, there were a lot of things I could have done to improve. The main ones were spending more time preparing answers to potential interview questions, and practicing solving and explaining solutions to coding problems. My time management could have been better too. I ended up skipping most of my classes the week I had three consecutive interviews. I thought it was worth it to spend the extra time preparing for the interviews and catch up on my missed classes the week after during reading week. This turned out to be a pretty good decision, although I probably could have avoided doing this altogether if I prepared more in the beginning of the term.

In the end, I received 6 interviews and 2 job offers, one from the first company I interviewed for and one from the last. I ended up taking the offer from the first company, TD! I am super excited to work in their innovation lab in the Communitech Hub next term.

My first job hunting experience was definitely a positive one. I was fortunate to find a co-op position early in the term, so I didn't have to worry about employment or interviews during finals. It was also great to have the extra interviewing experience. It's safe to say that I felt much more confident in my later interviews than in my first. Overall, CECA was right about treating co-op as an extra class. Finding a co-op job can be a lot of work, but there's no denying the valuable experience you get from it.

This year, a thousand students from across the world gathered in Waterloo's Engineering 5 building for Hack the North, Canada's largest international hackathon.

As this was my first hackathon, I arrived with little knowledge of what to expect. I wasn't familiar with the structure of the event or what I was supposed to do when I got there. I didn't even have a project idea in mind. But somehow, the uncertainty didn't bother me – it only made things more exciting.

Fortunately, soon after checking in, I was introduced to another fellow hackathoner by a friend I ran into. Since we were both looking for a team, we decided to work together on whatever we decide to make. Being with a partner made me feel more confident about the whole event. Although I wouldn't have minded working alone, I felt that working with someone else would be much more worthwhile.

During the opening events, my partner and I joined with two other people, making us a team of four. We just so happened to all be first year Waterloo students at our first hackathon. With the building so full, we were also fortunate to have a table in a nice classroom that my original partner found beforehand to work in. Our workplace had a great view of the hallways and workplaces around and beneath us. I found it a bit intimidating at first, but I soon learned to enjoy it. Settled down at our table together for the first time, we were calm but motivated, and we were ready to make something.

My team spent the next half hour deliberating on what our project should be. Our ideas were all over the place: a web app that maps the prevalence of a given job across different geographical regions, a smart Android app that tells you when to sleep based on your schedule for the next day, a Google maps-like app that gives step by step directions to each room on campus, and much more. Despite all the crazy ideas we had, we settled on something smaller and within the scope of a 3 day hackathon.

Introducing WatIsFood

Inspired by the popular WatIsRain app, WatIsFood aims to solve the hunger epidemic experienced by university students. The app helps them find food by mapping out all the open food serveries on campus. It also displays store details such as descriptions and operating hours.

Development for the app went smoothly at first, but as expected, we eventually ran into various problems. Being responsible for developing the map and marker display for each restaurant location, I faced the challenge of developing an efficient way to display this information.

Map drawing

I originally wanted to store and display the map as a vector file. This had the advantage of being able to zoom without losing image quality, which is essential when navigating a map. However, the lack of a native way to display vector files on Android and a suitable third party SVG library quickly led me back to the drawing board. With the option of having a vector map out, I decided to instead use a single high quality raster image. Of course, during testing, I was greeted with an abundance of out-of-memory errors due to the large size of the map. I tried to break down the map into smaller tiles, with separate tiles for each zoom level to improve image quality, but time restraints led me to back out from this approach. Eventually, I settled with just shrinking down the map image to an acceptable size. It definitely wasn't the best solution, but it'll work for now.

Marker drawing

Drawing store markers consisted of two parts: positioning the markers on the map and overlaying them on top of the map. Having a fixed size image made positing the store markers a breeze. The markers were positioned based on the coordinates of the stores on the image, and their visibility was determined by whether or not the store was open. Drawing them, however, required much more experimenting. The most obvious way to draw the markers was to overlay them on top of the map in separate ImageView. Unfortunately, this approach led to a lot of lag when panning and zooming on the map. The next option was to draw the markers directly on the map and display it as a single image. I used Android's built-in bitmap functions to merge the images, and after some more memory optimizations, the marker drawing was done.

Marker touch detection

This was the part of development that caused me the most headaches. The process seemed simple at first – just get the coordinates of the touch event on the ImageView and check if it's within a certain radius of a marker. Despite being a seemingly straight forward task, I found a major issue during testing. Sometimes, the dialog that opened when tapping on a marker did not correspond with the store that the marker represented. This bug seemed to occur completely random at first, with some markers working one minute but not the next. After a few long hours of debugging, I found that the problem began occurring after the map has been zoomed. As the map image was originally set to fill the viewport, the top left-most corner of the map had the coordinates (0, 0) as desired. However, once the map had been zoomed out and is no longer filling the viewport, the coordinates of that particular point changed. The coordinates (0, 0) now represented the start of the ImageView and different coordinates represented the start of the map. In essence, the coordinates obtained were of the ImageView itself, not the image it was displaying. I tried to compensate for this behaviour by processing the numbers using the map zoom level and the screen dimensions but to no success. As time was running out, my team and I decided to disable map zooming altogether to prevent the bug from occurring. This was another Band-Aid fix that I was not proud of, but It was nice to finally move on to refine other parts of the app.

Wrapping up

We finally finished our app an hour or so before the submission time. Although several compromises were made during development, we were still surprised that we even got this far. The last few hours of the event was spent on preparing a presentation of our app. It turns out that we were the last team to present to our panel of judges, so we had a lot of time to spare. Unfortunately, when it was our turn to present, the judges didn't seem very interested. It might have been because we were the last of a hundred or so teams they saw that day, or our idea wasn't that interesting in the first place. It was understandable either way; we were novice hackathoners, and we were tired too.

Despite the sheer amount effort devoted to developing WatIsFood, our achievements with our project wasn't what made the event great. What made it great was being part of a community that was motivated for both their own achievements, and to help others reach theirs as well. We were fortunate meet developers from companies such as Instagram and Big Viking Games, who not only gave us insight about their job in the company and future employment opportunities, but also helped us with developing our app. I also enjoyed listening to the many seminars that were offered, including one where we got to do a small Q and A session with the president of Y Combinator, Sam Altman.

With so much to do, it's easy to get lost in it all. Looking out the window of our workspace down at the atrium below, you can see everybody buzzing around like bumblebees. But despite the chaos, you'll never have trouble finding someone that's happy to stop and chat, and this is where the magic comes from at Hack the North.

View WatIsFood on ChallengePost