Keywords

1 Introduction

Midtown Buzz (MB) (midtownbuzz.org) is a partnership between Georgia Tech and Midtown Alliance (MA) (www.midtownalliance.org), a non-profit membership organization and a coalition of business and community leaders tasked with improving the quality of life for those who live, work or play in the Midtown neighborhood of Atlanta. This collaboration is focused on engaging urban communities through mobile innovation. Since 2013, we have been collaborating with the Midtown Atlanta community with the goal of transforming the area into an innovation district. This approach provided us with an opportunity to utilize Midtown as a living laboratory for civic computing research. During the two years of this project we have engaged in a participatory design process with stakeholders ranging from MA staff, local start-up companies, student developer teams, and community thought leaders to pursue a variety of activities with the goal of fostering innovation, exploring the needs of people in the Midtown area, and developing new technologies, techniques, and applications to address the identified needs.

We learned that an obstacle to civic computing, despite our myriad of activities, was taking concepts and ideas and maturing them sufficiently such that they actually impact the community in a positive way. In this paper we will share details on the key activities we have explored via Midtown Buzz, lessons learned, and our resulting hypotheses about what approaches can help technologists and researchers as they collaborate with community organization to bridge the chasm between good ideas and best intentions to sustainable results that provide long-term value.

1.1 Related Research and the Challenges of Civic Computing

There have been a large number of initiatives and research projects with similar goals. At the national level, Code for America (www.codeforamerica.org) connects technologists with local governments to create new solutions for civic. Cities such as Portland, Oregon [1], Pittsburgh, Pennsylvania [2], and Melbourne, Australia [3] have been the sites of collaborations between computing researchers and community organization that utilize the “neighborhood as living laboratory” [4]. And as we discuss throughout the paper, many of these projects encountered opportunities and challenges similar to those of Midtown Buzz.

Our use of participatory design as a keystone of the project is also informed by a host of related civic computing initiatives [5–10]. Many of these projects found, as we did, that the use of rich media, collected from local sources, and presented in within a “storytelling” is a promising method for to creating meaningful digital experiences for the community [11–13]. And that more significant impact can be achieved by leveraging grassroots initiatives and the “do it yourself” spirit [2]

There are many similarities between the approach and findings of the Midtown Buzz project and that of Civic Nexus [14]. Of particular relevance, was their focus on learning how to work with organizations, and determining what is a “good” outcome from such work. A major lesson we learned from the MB project was that an obstacle to creating substantive impact was, at root, due to a mismatch in expectations from the MA and GT sides of the project. We each had a different conception of what activities we should pursue and what a successful outcome would look like. For example, the MA team was eager to deploy mobile applications via “app stores” to achieve a critical mass of users while the GT team was more focused on understanding community needs and exploring the design space via prototype experiences. Similarly, in their RE-ACT project, Sabiescu et al. found a conflict of vision between the researchers and the community collaborators [13]. As Shapiro et al. explain, the failures of such participatory design projects are often not technical but social/analytic/political [15]. Throughout the two-years we have continually endeavored to educate each other regarding the language, work practices, tools, and metrics of success in our respective domains.

While we entered this process with enthusiasm and hubris, we soon learned that it was not as simple as “turning the crank” to take good ideas and convert them to a deployed application or initiative that was providing value in the community. The main challenges were two sides of the same coin: failure to launch and the difficulties of sustainability.

Throughout this work we had a variety of activities such as brainstorming charrettes, workshops, design sprints, and focus groups with diverse stakeholders. Exciting and novel ideas emerged from these activities that were meant to feed into a pipeline that would convert these ideas into impactful projects. The ecosystem of mobile applications is already robust (and for some application types, oversaturated). Therefore, we theorized that the solution was for us to identify, via ethnographic inquiry and ideation, where there were still unmet needs and then assist in the creation of technology artifacts informed by these needs. Over time, we realized that some of the conventional methods for jumpstarting implementation were not as successful as we would have hoped and that our project was stymied by a failure to launch. Hackathon teams, formed based on chance, struggled to work together after the event was over and startup companies fizzled due to lack of funding or the changing focus of their founders. Approachable toolkits that would allow non-technologists to create novel user experiences required extensive resources to create, iteratively develop, and to support long-term, and for outreach to attract developers. And there was an omnipresent concern that we not attempt to “compete” with commercial applications that would have considerable more resources behind them.

And thus, our other challenge was related to sustainability. As we attempted to turn our ideation into reality, there was a question about who would do the implementation. Our MA collaborators were eager to provide mobile experiences to the community, but did not have in-house technology expertise. There was a fear that a deployed application would quickly become irrelevant and useless without a dedicated steward to support and update the application. Similar community based technology projects such as Romani Voices [13] and Johnson and Hyysalo’s social media project [5] encountered stagnation and conflict later in their projects when the researchers stepped back from active development. We realized early on that the key to a successful intervention was often rich data sets, but resources would be required to initially access the data and to make sure that its connection to our applications were properly maintained,. And in some cases, a user need that kept emerging from our research (e.g. the need for real-time guidance to parking spots) would have required an entire infrastructure initiative (e.g. sensors embedded in street such as those used in the SFpark initiative, sfpark.org), rather than just the creation of mobile software. Ultimately, the problem was who should (and could) be in the business of building and maintaining applications? Working with external commercial interests is an option, but what if there is no profit associated with the service/application despite the fact that it would provide great value to the community?

As a result we re-evaluated and evolved our plan throughout the project, which is not unusual for civic computing initiatives [10]. In the following section we detail our two years of activities and describe the strategies we developed in response to these challenges.

2 Midtown Buzz Activities

In this section we will describe a subset of activities that made up the Midtown Buzz initiative to highlight lessons learned. As an overview, the entirety of Midtown Buzz activities are summarized by the following statistics Demo Days: 3,Brainstorming Sessions: 6,Developer Workshops: 3, Hackathons/Sprints: 3,Curated Data Sources: 29,Developer Tools (Argon, Beacons, Glass), “Tastemaker” Panelists: 24, Partner, Outreach: 15+, Teams Supported: 12, Community Participants: 2000+

2.1 Brainstorming

We launched this project with an initial brainstorming workshop that included ~60 participants from the community. The goal was to understand what needs and desires the residents, workers, business owners, and visitors had in the context of Midtown Atlanta. The participants were divided into groups of 10–12 that were focused on a particular domain: health and wellness, wayfinding and walking tours, or transportation and sustainability. The groups contained a scribe and a facilitator that were members of the GT team as well as participants from MA. The facilitators urged the participants to not focus on technology, but to instead think about how their experiences in Midtown could be enhanced. The groups explored novel territory with their discussions. The most promising topics that emerged could be categorized as a desire for authentic voices, the need for curation and personalization, and the potential of immersive experiences:

  • Authentic Voices. A common theme was that, while there are already considerable resources for finding recommendations for restaurants, entertainment, and other businesses, current resources lack authentic voices and feel as though they are driven by marketers and advertising. The participants wanted to have the experience of being guided around the city by a resident who could help them discover lesser-known places. The participants wanted to be privy to the more detailed “insider” view of the community that would resonate with the visitors’ current interests/needs (e.g. vegan dining, nightlife, street art, child-friendly places, etc.). Our findings are similar to those from the Virtual Town Square project, which provided a location-based interface for residents to share rich hyper-local content with each other [16].

  • Curation and Personalization. Our participants used the word “curate” repeatedly as they described the need for a contextual lens thru which data would be filtered. They imagined rich user-generated content about the neighborhood, and the ability to vote this content up or down (similar to Reddit [17]). The voting could drive the automatic generation of “personas” that categorized the content and provided the users with a set of “lenses” with which to view the community. They wanted to personalize their “hyper local” and “authentic” experience based on these personas (e.g. a new mother getting in shape, an architecture aficionado, an avid indie music fan etc.), noting that the user might choose drastically different personas of information at different times depending on their changing interests and needs.

  • Immersive Experiences. The participants felt that existing mobile applications are often focused on information about locations (e.g. the restaurant star rating, the location of a business, the upcoming show schedule at a venue) and do not attempt to convey the experience of visiting the area. The participants expressed the desire to access the experiential aspects of a space or community (i.e. “being there without being there”). They felt these immersive experiences could help with decision-making (e.g. which restaurant to go to, which apartment building to visit) and could entice people to visit areas in real life. They imagined augmented and virtual reality applications that would provide a far richer experience than current mobile applications.

The findings from this brainstorming defined our design philosophy going forward, a focus on allowing users to “feel like a local,” accessing authentic information tailored for their current needs, presented, when possible, in more immersive ways.

2.2 Hackathons and Supporting Developers

Hackathons have become popular in recent years [8]. They can provide various benefits to the sponsor including visibility, rapid exploration of the design space, and the, often erroneous, belief that working applications will result. The competitors may participate from a desire to use their skills for an altruistic purpose, motivated by prizes, or from a desire to raise their profile in the developer community and in the eyes of the sponsors. For example, often our GT students compete in hackathons as a way of building their portfolios and getting access to potential employers. Some participants, and sponsors, imagine that the projects will persist following the competition, ideally turning into actual startup companies. However, as others have noted prototypes are not products and products are not businesses [18]. While we initially envisioned our workshops and hackathons as a relatively simple method of launching new innovation in Midtown, we soon learned that it was difficult, even with support from us, for the teams to gain traction following the event. The key findings from our hackathon activities include the need for diverse teams, the importance of focusing on ideas rather than developing software early on, and requirement for external support following the event:

  • Diverse Teams: In both our Midtown events as well as the Convergence Innovation Competition (cic.gatech.edu) we have found that a homogenous team often struggles to take the next step to realize their vision following the event [19]. For example, a CIC team we worked with closely built an AR restaurant application to let diners view a menu through different lenses depending on their food preferences. The idea was novel and the team was strong in technical skills. However, the members lacked knowledge of user experience and interface design and they also did not have domain knowledge about the restaurant industry. They were eager to write code and to start a company around their idea, but needed considerable support from the GT team to design an application that met the needs of patrons and restaurateurs. Conversely, a later team from our “Storytelling Hackathon,” had an intriguing idea that was basically a location-based acting version of karaoke. They produced a compelling concept video and seemed very motivated to bring the project to fruition. The team had formed from scratch the day of the event, and as a result they possessed differing personalities, and none of them were strong software developers. Again we tried to support them, but despite their eagerness, this lack of ability to build initial versions of a working application and their conflicting work styles stymied them. The challenge, of course, is how the planners of such an event can facilitate the creation of more diverse and effective teams.

  • Ideas Rather than Code. Despite the importance of having a team that consists of members who understand the user experience, the domain, and possess the abilities to implement their ideas, we also found that reducing the focus on producing code during the event enhanced the creativity of the participants. Our first few workshops and hackathon events were very focused on developer tools, live data feeds, and implementation. We found the results to be bland. Our later Google Glass Design Sprint (where participants brainstormed novel uses of Google Glass) and Storytelling Hackathon (where teams were tasked with designing novel mobile applications that provided information by capturing “stories” from local residents) were all about conveying the concept and the user experience. In the Storytelling we specifically recruited non-technical community leaders and “tastemakers” to participate along with software developers. We instructed the teams to spend their time going into the community and collecting content (video, audio, still images) to create a concept video that would convey what it would be like for a user to experience their idea, rather than producing prototype code. We asked them to think about how rich location-based information (for a wide range of applications such as wellness, transportation, public safety, and entertainment) could be conveyed in a “storytelling” context. This was informed by the outcomes from our early brainstorming that highlighted the need for rich content from authentic local voices. While some of the submissions were outlandish (e.g. proposed zip lines taking visitors across the city and a giant aquarium arching over the interstate) the results were far more exciting and the participants far more motivated than those from our previous activities.

  • The need for support. Early in this initiative we realized that greater impact could be achieved via mentoring of external developer teams rather than via the GT team building applications ourselves. We had also found that even motivated and skilled teams from our hackathons needed additional support to take the next step with their project idea. We recruited promising student teams from the CIC and our hackathons that had a novel idea, a potential business model, and a team interested in taking the project further. We found that the GT student teams often lacked HCI expertise. The teams focused on technologies and features and struggled when designing the user experience, focusing on how to produce a minimal viable product, and how to collect and act upon user needs. As a result we provided similar mentoring to a variety of teams and companies. In particular the companies benefitted from getting connected to local resources such as business owners, community organization, and economic development opportunities.

Despite all of these activities and mentoring relationships, however, we were disappointed in the lack of substantive impact that was generated for Midtown as a result. There were certainly positive outcomes. The students gained valuable experience. MA was able to explore a wide range of user needs and possible application ideas. Awareness about Midtown and their commitment to innovation was increased, and there were a suite of tools and data sources (to be discussed in the next section) produced that we and others can continue to leverage. The vision of an ecosystem of deployed applications and startup companies testing their initial offerings in Midtown, however, was not realized. Our experiences highlight the serious challenge that exists in bridging the gap from early ideas and excitement to working systems in the hands of community residents.

2.3 Data Sources

Through our experiences with the Midtown Buzz projects as well as GTJourney (gtjourney.gatech.edu) [20] we have learned that the key to fostering the creation of novel and useful applications is in making rich data sets available to developers. As we observed in our Midtown Buzz brainstorming, as well as in GT mobile applications classes and student competitions (GTJourney and CIC) users often express a need for application ideas again and again, and the obstacle is data. As an example, for a decade or more, students at GT in various classes and competitions would attempt to build websites and applications to track the on-campus busses. The challenge was not in identifying the user needs or creating an application; the stumbling block was that there was no way to access real-time location information for the busses. The GTJourney initiative then did the heavy lifting of working with various departments around campus to either access existing data (e.g. class location information for campus buildings) or instrument systems to collect data (e.g. trackers on the busses) that allowed the applications to be built quite easily. Therefore, in Midtown Buzz we have worked extensively with key stakeholders and data owners to identify both the technical and policy changes needed to release data, and we have created systems that provide data through APIs in a way that is scalable and protects privacy when necessary. A sample of the current data available through Midtown Buzz includes: public land use (historic buildings, open space, properties, public art), events/special deals, attractions (retail, restaurants), transportation (bike rack locations, bus/shuttle routes, EV charging stations, logged commuter data, traffic counts, parking, Zip car locations), and public services information (SeeClickFix reports, Energy Star Certified Buildings, Rainwater Cistern Tracking, Solar Energy Installations). This work allows the developer community to innovate and compete on the applications and use cases while leveraging the same data. This process resulted in a few key lessons learned:

  • Understanding the Need. It is not intuitive to understand what it means to provide relevant and useful community and location based data as a service. The challenges include understanding the type of data that is needed (by both the end user and the developers), how it can be collected (who owns the data? How can it be accessed?), and how the service that provides it should be structured (e.g. data format, update rate, level of detail, access control etc.) to make it useful and secure.

  • Resources are Necessary. As is discussed by Sanders et al. [20] it takes resources in both time and expertise to identify and create these services. The time element makes such efforts on a college campus difficult because students are not at the institution long enough to launch and then maintain the data sources and services so they can quickly become stale or unusable.

  • Long-term Support is Key. And related to the need for resources is the requirement for long-term support. Developers cannot rely on a service, no matter how valuable initially, if there is not a reasonable belief that the data will be kept fresh and the services technologically up-to-date. In our experience the answer for a university is to have full-time research faculty as the keystone of the efforts, as they have the experience, work cycles, and longevity in their positions to be appropriate stewards. And to fund their participation we look to spread the cost of support (in money and time) across funded research projects, courses, and students competitions. For example elements of this project were interwoven with the Argon initiative [21, 22] Cycle Atlanta and One Bus Away research [23], GT Journey [20], and CIC [19]

2.4 The Tastemaker Panel and Storytelling

When creating urban computing solutions Kukka et al. discuss the requirement for “insider” support in understanding the social, cultural, and political contexts of the community [24]. While Sabiescu et al. leveraged in-depth interviews, focus groups, and observations with key community members to capture rich content for their “Romani Voices” [13]. Therefore, consistent with the theme of identifying “authentic voices” and collecting rich content, we approached a diverse set of interesting people with a large social media following who also have authentic knowledge and information about the Atlanta community. This “tastemaker” panel consisted of influential community members from the areas of local art, community advocacy, real estate development, foodie, local deals, photography, public media, street art, cycling, local publications, live events, local businesses, pop culture, and sports; they participated in Midtown Buzz in a variety of ways. The group participated in brainstorming workshops, collaborated with developers in the hackathons, and provided domain knowledge for our student and entrepreneur teams. They also provide the much needed hyper-local knowledge and insights to seed our own technological artifacts, the Midtown Buzz portal and prototype storytelling experience (discussed in the following section). They continue to be a resource for our civic computing initiative at GT and for MA and have proven to be one of the most impactful components of this project.

Our participatory design activities with the panel culminated in a prototype storytelling application built using our Argon framework [22] ([21] describes Argon and the MB experience in greater depth). Our goal with the storytelling approach was to focus on personal expressive content to create rich community resources that were differentiated from the type of location-based mobile applications that currently exist, which are motivated by efficiency and productivity. A philosophy inspired by related urban computing projects [11, 12, 25]).

3 Discussion and Future Work

The most significant outcome from the Midtown Buzz initiative was the discovery that the community is hungry for mobile experiences that prioritize the authenticity, experience rather than efficiency, and “local voice” of the content. Our activities also guided us into a new direction for our research, focusing on a lifecycle of content, crowd-sourced voting, automatic categorization of content into “persona” groups, and providing filtering/searching tools for users based on the concept of viewing (figuratively, but sometimes literally) a community through different lenses depending on current interests and needs. This will be the focus of our subsequent phase 2 efforts.

The major lessons learned a very much aligned with those of the Civic Nexus project [14]. The first being the need for inquiry as part of the design and the challenge in this type of project of even identifying what exactly the community partner and the researchers should be working on. Merkel et al. state about their project they “were trying to find ways that we could work together…It has been difficult to find “the project” to work on with this group.” The original plan for Midtown Buzz seemed very straightforward – engage in participatory design exercises and build technology prototypes. We quickly realized that true impact on the community would not come from us building a small amount of technology to deploy, but by identifying directions for new projects, establishing community connections, and helping others to realize them [7]. We had to spend considerable time and resources working with MA to figure out what type of activities would meet their needs as well as those of the community and of our researchers. Toward this end we undertook a variety of activities such as developer workshops, hackathons, and mentoring, but as we discussed above, we learned that extracting substantive community impact from them is very difficult. In the end, the contribution of this research project is greater insight into the process of carrying out a collaborative civic computing project rather than reporting on the creation of digital artifacts that transformed a community.

The second lesson learned was related to sustainability and the technical expertise of our community partners. Merkel et al. note that their community partners had little in-house technology expertise. This meant that the partners were not able to contribute significantly to the technology process and the results were artifacts that did not meet their needs and/or systems that they could not maintain. The Civic Nexus team then explains that you must make learning about technology part of practice. Similarly, our collaborators’ lack of technology knowledge meant that we struggled to manage expectations as it was not clear to them what technology ideas and timelines were realistic. There was also an ongoing question about who should be responsible for initially building apps, and what the plan for sustainability would be, especially between the stakeholders with data, MA, and the technology team. On one hand, it would seem that MA does not need to be in the business of building and supporting technology, and yet, as was found with Civic Nexus, a external research team sweeping in and creating solutions does not typically lead to long-term success. Rather a community of active stakeholders who take responsibility for long-term maintenance is needed [26]. It is these questions that led to the creation of the Argon-based mobile application and storytelling prototype. Argon is approachable for non-technologists as it is based on standard web authoring tools. This allows MA to continue to improve and expand these artifacts rather than having to let them stagnate. In Phase 2 of the project we are “stepping back” from this aspect of the project (a technique also recommended by Merkel et al.) by sharing a student who physically works at the MA offices, helping them to build more storytelling content while teaching their staff how to work with the tools.

4 Conclusion

Presently, there is considerable interest in civic computing and a belief that coupling technologists with community organizations can produce significant positive impact. However, through our research on the Midtown Buzz project we have learned that significant barriers exist that make it challenging for good intentions and innovative ideas to reach the level of maturity needed to achieve this goal.

Over the course of two years, we worked closely with the Midtown Alliance organization and various community thought leaders, residents, and business owners to explore what the next generation of mobile civic-focused applications could and should be. This process started with ethnographic inquiry and progressed to participatory design, support and collaborations with external developers, community events, tool building, and technology prototyping. While the original plan of collecting user needs and building applications proved naïve, we found that successes came from close collaborations with a diverse set of stakeholders from the “Tastemaker” panel, local entrepreneurs, and motivated groups of students. Our main lessons learned are: that current location-based applications do not provide the rich hyper-local authentic content that users desire, access to data (and persistent services that can be trusted) is key to empowering developers, hackathons and other short-term interactions with potential contributors alone are insufficient, and that an important part of a collaboration with community organization is empowering them via technology awareness, education, and accessible authoring tools.