1 Introduction
1.1 Research Objectives
1.2 Motivation for Choosing Hackathon as an Object of Study
2 Related Work
2.1 Key Design Concepts: from a User-centered Approach to Participatory Design
2.1.1 User Experience
2.1.2 Participatory Design
2.2 Qualitative Study of Software Engineering
2.3 Hackathons as a Qualitative Case Study Tool
2.4 Team Diversity
3 Methodology
3.1 Case Study Design
3.1.1 Hackathon Setup
3.1.2 Participants
Men | Women | All | |
---|---|---|---|
PJAIT students | 34 | 8 | 42 (52%) |
Outside of PJAIT | 38 | 1 | 39 (48%) |
Total | 72 (89%) | 9 (11%) | 81 (100%) |
Teams without Women | Teams with Women | Total | |
---|---|---|---|
Teams with PJAIT students | 13 | 7 | 20 (80%) |
Teams without PJAIT students | 4 | 1 | 5 (20%) |
Total | 17 (68%) | 8 (32%) | 25 (100%) |
3.2 Analysis Tools
Juniors | Older adults | Total | |
---|---|---|---|
Before the event | 25 | 13 | 38 |
After the event | 21 | 13 | 34 |
Total | 46 | 26 | 72 |
4 Results and Findings
4.1 Social Dynamics
-
Scenario 1–Isolation of Older Adults: In this scenario, the programmers made no attempt to make contact with the older adults. After the official opening of the Hackathon, the younger adults went to their designated workplaces and started installing their hardware. Three teams adhered to this scenario. We noted that within these teams there was some discussion about the viability of cooperating with older adults. Some stated that the teams should use the perspective of real older adults because apps developed without inputs from a older adult’s perspective would lead to solutions based purely on negative stereotypes. In contrast, other voices were raised in defense of not cooperating with older adults and insisted that the group participating in the event was not representative, because they already had some experience with ICT.
-
Scenario 2–Older Adults as Consultants: Groups that followed this pattern of interaction utilized the help of older adults when designing their hackathon submissions but did not engage in the full interaction we had imagined when designing our hackathon. Rather than inviting the older adults into their groups, the juniors sporadically discussed selected issues with a group of four female older adults (IDs 4, 5, 12, 15) who sat in the corridor outside the designated programming area (actually a makeshift cafeteria for hackathon participants). The general layout of this space is shown in Fig. 1.×We noted that two of the four sidelined “Scenario 2” older adults were also involved in full-fledged cooperation with another team. This situation was described by all the older adults in the cafeteria as a boost to their self-esteem (“Look at us, we’ve helped three groups already - older adult (ID 12, female)). The older adults also emphasized their belief that they did not need to be present with the juniors, explaining that because the younger participants had obtained the information they needed from them, they could be of no further help by just sitting there in the team room doing nothing. When the junior participants were working at their stations and holding discussions among themselves, the observers noted the same rationalizations being made as those made by the groups that did not make use of the older adults’ help.Programmers did not want to treat the insight from older adults with full seriousness, because they deemed their experiences as not representative of the demographic as a whole. The next day when the older adults returned to help with testing, two participants (IDs 12, 4, both female) went to the group of their first choice. Moreover, while little testing was performed, the juniors requested the older adults to help the team prepare the final presentation of their work. In contrast, two senior participants (IDs 5, 15, both female) remained in the corridor. The juniors who had used their opinions during the initial stages of idea development did not return to them for help.
-
Scenario 3–Full Cooperation: This scenario includes teams that fully incorporated the older adults into their projects. Older adults played an active role during all stages of app development. We observed full cooperation in five teams. In all these cases the older adults were invited to work together with the juniors at their respective team desks. Figure 2 shows the typical team member seating arrangement around the table. As shown in the figure, we observed three main types of seating arrangements, all of which showed some degree of spatial separation between the two groups.×
4.2 Idea Development and app Design
5 Software Outcomes and Hackathon Follow-Up
5.1 Super Senior
5.2 Tiger: F1
5.3 Join
5.4 Remaining Applications
-
Where to pharmacy – An application that notifies older adults of local pharmacies that are offering discounts on medicine,
-
ELNERD – a browser designed for older adults, with a voice detection module for mobile platforms,
-
Papilot – A tutorial type application that aids older adults with their first experiences with a smartphone; contains an interface with heightened contrast and enlarged fonts,
-
Memories Savior – An application that facilitates the storage, retrieval, and exchange of memories between family members,
-
i100 – Medicine intake mobile manager
-
HoŻy seniorzy (Swift Seniors) – A platform for exchanging information about local events aimed at older adults,
-
MemoryCloud – System for creating memoirs,
-
Koło rodzinne (The family circle) – A communicator for family members,
-
Kolejki (Queues) – A social media platform, that through an exchange of information, appraises older adults on current waiting times at doctors’ offices,
-
Babcine Opowieści (Granny’s tales) – Geo-caching application for older adults; allows them to pinpoint a memory in graphical or textual form, to a specific place; later, when reaching the location other users can accesses this memory through their app,
-
Blink – A communicator based mostly on exchange of graphics (mostly emoticons),
-
Puk Puk (Knock Knock) – Designed to assist older adults in finding help for everyday tasks,
-
Album Wspomnień (Memories log) – facilitating the collection and cataloging of photos,
-
Silver Tinder – Imitates the swapping mechanism from Tinder; a platform for meeting new people in the local area,
-
Mobile Tigers – Medicine intake organizer
-
Silent Disco – Allows younger people to hold silent disco parties that would not disturb elderly neighbors.
6 Conclusions and Recommendations
6.1 Conclusions from Observation of Social Interactions Between Older Adults and Junior Developers
6.2 Conclusions About Effect of Participation of Older Adults on the Development Process
6.3 Recommendations Concerning Hackathon Organization Involving Older Adults
-
Mind the space: When making plans for a hackathon to which older adults will be invited to participate, it is important to carefully consider the location. The organizers should choose a location familiar to the participating older adults. If no such a place is available, a location with a simple room layout is best. If possible, the hackathon should take place entirely on one floor (preferably, the first or ground floor) to minimize confusion and the physical effort required to participate. This observation has not been made so far in previous work, as few or no hackathons have involved older adults.
-
Keep them in touch: When inter-generational cooperation is important, the first few hours of an event are critical in setting the tone and making participants feel welcomed when matchmaking occurs. Both junior and older adults participants must not be left to their own devices without any guidance. When this occurs, junior participants retreat to set up their work stations, while the older adults feel left out. To combat this outcome, the organizers should encourage communication from the very start, i.e., through pre-hackathon discussions and sessions to build rapport between the age groups. This finding confirms previous research about hackathon organization.
-
Take into account different collaboration strategies: Our initial assumption that each older adult would work closely with only one team turned out to be only partially correct. Some noncompetitive older adults were ready to help all the teams. Many of the younger developers, for their part, expected only short, infrequent sessions with the older adults to verify a design or idea. Therefore, it is worthwhile to create the opportunity for both participation strategies and/or to make it possible for older adults to drift from one type of collaboration to another. Because our study is the first to report different cooperation scenarios chosen spontaneously by developers and older adults who work together, this is a new recommendation for organizing hackathons.
-
Encourage user involvement: Technical aptitude, while necessary for creating a working prototype, is not a useful criteria when planning to build functional intergenerational teams. Too much focus on purely technical aspects can lead to greater feelings of isolation by older adults who are not skilled in this field. Therefore, supervision and mentoring with respect to the participatory design process and optimizing user experience is an important consideration for event organizers. For older adults participants who are skilled technicians (i.e., retired programmers or engineers), this is a good practice and may not be as critical as for those not from the field. Discretion is advised.
-
Change typical hackathon schedule and scope: While we have conducted a hackathon with typical duration (2 days and a night) and scope (full development process), we would advise future organizers of hackathons that involve older adults to consider changing schedule or scope (or both). In order to facilitate full participation of older adults we should start the hackathon earlier and perhaps we should organize it in shorter form of a one-day event. If the hackathon duration is shortened, the scope can be changed to a selected part of design cycle, namely the design stage in order to obtain better prototypes even without any code (encouraging the use of live mockups).