3.1. Vision and Concepts
At the beginning of our research project, we had to start with a vision for the future digital smart city district. The goal was to think about the general solution space and make it broad, as well as to narrow it down afterwards to our concrete project setting. This activity required us to find answers to the following questions: How can digitalization support a smart city district? What do we need as infrastructure, who are our stakeholder groups, what services can we offer to them? Two examples are presented next: We worked on an “ICT concept” (Section 3.1.1
) during the first two years of our project and used this as a supporting instrument for developing concrete solutions afterwards (we also present some examples in Section 3.1.2
). Furthermore, we are developing a so-called digital ecosystem map, which is our means for communicating our digital solutions easily (Section 3.1.3
3.1.1. ICT Concept
Early in the project, we began investigating the potential of digital solutions to support future citizens of the smart city district in living an environmentally friendly life. Climate protection directly refers to the general goals of the project. They are in turn deduced from the German government’s 2050 climate protection targets, which are reduction of greenhouse gas emissions by at least 80% to 95% compared to 1990, increase of the share of renewable energies in gross final energy consumption to 60%, and reduction of primary or final energy consumption by 50% compared to 2008.
Within our scope, we want to explore and implement digital solutions that will support future smart city citizens in their daily life in two perspectives. On the one hand, these solutions shall provide value by solving users’ problems or addressing their needs. On the other hand, these digital solutions shall motivate, nudge, or support users’ behavior that is beneficial for climate protection and reduce, make unpleasant, or impede behavior that impacts climate protection negatively, but without compromising the first perspective.
We identified three major areas of concern for such digital solutions: energy, mobility, and community, and put our focus on user-facing solutions (applications). This does not imply that we completely neglect cyber-physical systems, but rather that the emphasis on users is at the center of our efforts. All proposed applications shall provide value to the future users. If this requires the use of cyber-physical systems, we still call them “applications” to stress the user focus. The first area of concern, energy, refers to all applications that help to reduce energy consumption or increase the use of renewable energy by smart city citizens. Mobility covers applications that support a reduction of overall mobility or increase the use of climate-friendly mobility means. Community covers applications that support the climate protection targets through changes in the daily life of smart city citizens. Potential solutions can be assigned to one or more of these areas, depending on their focus and design.
As the future smart city district is currently under development, no citizens, i.e., actual users, have been available for eliciting requirements or testing solution prototypes. We developed a set of proto-personas (see Figure 2
, cf. [26
]) representing the archetypes of future smart city district citizens. Through creativity and innovation workshops, ideation sessions, hackathons, and similar activities undertaken with researchers and local citizens alike, we have developed several different solution ideas for each of the major focus areas (energy, mobility, community) that match the expected needs of the proto-personas as well as the climate protection targets.
Yet, how does one communicate these ideas for potential future applications, evaluate their intended impact, and gather feedback from users who would be affected by these solutions in the future? In the early project phase, we did not build tangible prototypes of suggested applications because we first needed to explore the general direction of potential future solutions before investing in creating high-fidelity prototypes. Our goal, at that project stage, was to communicate our general vision of the digitally supported climate-friendly daily life in the smart city district to the general public.
One way we did this was by releasing the “ICT concept” document (see Figure 3
). The document covers descriptions of the project’s goals, the vision for a digitally supported smart city district, our approach and way of working in the project, the stakeholders we identified using classical requirements engineering (RE) methods and the proto-personas, the potential solutions and their intended technical resolution, and an outlook towards the digital ecosystem’s business model opportunities. All this combined makes up our vision of the digital smart city district. It is more than just the digital applications. Each part of the document’s content is described in simple, non-scientific language and enriched with informative and decorative figures to increase accessibility for a broad audience. We focused on the main ideas of each topic, not losing ourselves in lengthy descriptions and keeping each part concise.
With regard to our lead questions, the ICT concept fulfills a special role compared to other activities presented in this work. It summarizes and abbreviates the key results of requirements engineering activities and other related activities, aiming to make them tangible for a broad audience that, for the most part, is not immediately affected by any of the project’s outcomes. LQ1 is only slightly affected by the ICT concept, as it does not represent requirements engineering activities by itself, but summarizes and displays them and their results. However, lead question LQ2 can be discussed here.
The whole document has been designed in a way that increases appeal and accessibility. The document is printed on thick paper (see Figure 3
), which is appealing when touched to increase the chance of people picking up the document and reading it. We acknowledge the irony of printing a document on thick paper for communicating the vision of a climate-friendly smart city district. However, in this case, we valued the importance of communicating the vision effectively (i.e., the long-term effects) through a small print run over the short-term reduction of greenhouse gases achieved by not printing this document. In addition to the physical copies, the document is distributed online. Readers can access the document whenever they like, increasing the chance of it being read. Overall, we conclude that such a document is well-suited for communicating the general vision and idea of digitally supported smart city districts, as it reaches citizens and future users by reducing the obstacles for them to engage with such a topic. The ICT concept is less suited for creating a deep understanding. Hence, with regard to lead questions LQ3 and LQ4, this document does not provide any support on its own but may be used in conjunction with other activities (e.g., citizen events, backchannels for collecting feedback).
Creating the document required a significant investment of time, as not only the content needed to be transformed into simpler language, but also the visualizations and illustrations had to be drawn. Additionally, the layout process itself took time. Nevertheless, we regularly use this document as the basis for discussion and ideation activities. Hence, we conclude the lesson learned as follows: If one has the capacity and required capabilities (skills, software) for creating such an accessible document, it is worthwhile doing so if it is to be used not only for communicating the vision but also as input for later activities with the general public, as it makes the project’s goals and the topic of digitalization tangible.
3.1.2. Digital Services Prototypes
The digital solutions we investigated in the ICT concept aim to support future smart city district citizens in integrating climate-friendly actions into their daily life and reducing harmful activities. In addition to exploring digital solutions in that vision document, we created prototypes of two different applications.
The first one is called PfaffFunk and serves as a sort of social network for local communities. We expect this application to support community building and nurturing in the future. This application’s value proposition is to easily connect citizens of a certain area (e.g., the smart city district) with each other and provide a safe space for gathering and exchanging information, chit-chatting, and making arrangements. Yet, how would this application support the climate protection goals addressed in the smart city district? It lies within the aspect of building a community of like-minded individuals that all work together to reduce the overall energy consumption of the smart city district and their own carbon footprint. This is only an indirect form of support, but we have experienced similar community-building effects in another domain, smart rural areas, where a comparable application is being applied in real life. The application prototype is fully implemented, is available as native iOS and Android applications, and supports all features mentioned above, even though the local relationship is not yet present due to the smart city district not being established yet. Figure 4
shows screenshots of the current state of the application prototype.
The second prototype digital solution is called Fish n’ Tips and shows the vision of an interconnected application that interacts with other digital services and status information regarding the future smart city district. Its value proposition is that a personal coach gives appropriate individual hints to smart city citizens at the right time. These hints are intended to help citizens reduce the climate impact of their actions. For example, a user might be notified with a hint when they leave a window open for a longer time period while the heating is turned on. The information about the user’s flat is derived from smart home appliances that will be connected to the digital platform in the future smart city district. The prototype only supports a limited number of hints but can be used to communicate the general vision and idea. It is available as a web application and supports the use of dynamic data for generating the hints; hence, it can be used for truly interactive Wizard of Oz-style user tests. Figure 5
shows screenshots of the current state of the application prototype. These prototypes in and of themselves serve as manifestations of concrete aspects of the general vision of the digitally supported climate-friendly smart city district.
On their own, the digital solution prototypes only show a small slice of the overall vision for the digitally supported smart city district. Nevertheless, these are valuable tools regarding lead questions LQ2 and LQ4. Tangible prototypes, by their very nature, are helpful for communicating and testing concepts and future solutions without completely implementing them. A prototype is built to serve a certain purpose; e.g., a technical demonstration serves the goal of understanding a certain technology or framework or proving that a certain feature can be implemented. The digital services prototypes are built to serve the goals of communicating the vision of the digitally supported smart city district. We selected the prototypal features to support this goal (e.g., the type of hints given by the Fish n’ Tips application). With regard to lead questions LQ1 and LQ3, we see the digital services prototypes do not provide further support.
3.1.3. Pfaff Ecosystem Map
During the project, we had several points where we faced the challenge of communicating and explaining our ideas and what a digital city district means to different stakeholders. From our experience, this gets more challenging the less technological affinity people have, but sometimes this was even challenging when talking to people who do have a general technical understanding but are not deeply involved in digitalization topics. However, this is a very critical and important aspect from our point of view: explaining solutions so that others understand them, see the benefits, and are able to apply them.
In order to have a way to explain the big picture of a digital city district ecosystem on the one hand, but also details about technical solutions on the other hand, we created a so-called smart city district ecosystem map (Pfaff Ecosystem Map). This is a digital visualization of how we understand the digital smart city district. There are several views on this map, but it starts with a high-level view showing streets and buildings of the district and many interaction points for the user. The user can then dive into those parts in which they are interested and see more information when they zoom in. The map itself can show different aspects, for example, concrete services shown as apps, data flow, or technical details about the infrastructure. Such an instrument can be used to actively present the digital solutions to users, but it can also be used directly by the users to explore the map. First ideas how this can look like are shown in Figure 6
In addition, we are also thinking about using virtual or augmented reality (VR/AR) concepts. Of course, as we are currently not in the district itself due to construction work, and therefore we cannot use those concepts there. However, we can already test different tools and technologies to prepare for future VR or AR applications.
3.1.4. Summary and Conclusion
In our project, everything started with general concepts and ideas. This took some time. We needed to understand what digitalization of a smart city district is all about, who our stakeholders are, what their needs are, and what potential solutions could be. We needed to think about the different procedures we want to apply to achieve concrete and correct solutions, as well as about how to share our ideas and knowledge with the citizens. Through various workshops, literature and state-of-the-practice searches, expert interviews, and many discussions (LQ1), we arrived at an ICT concept that summarizes many of our ideas (LQ2). Part of this concept was early mock-ups and visual ideas of services, some of which were developed into prototypes in the subsequent project phase. This brought us to the situation where we had a (theoretical) concept on the one hand and concrete individual solutions in the form of prototypical apps on the other hand (LQ4). However, the bridge in the middle was still missing. We still needed to make it more concrete what a digital ecosystem as a whole means. Therefore, we are currently creating what we call a Digital Ecosystem Map to visualize the idea and the solutions in different ways (LQ2).
3.2. Smart City District Digital Ecosystem
The second part relates to concrete services and our technical infrastructure. Two main parts are in the center of what we call a smart city district digital ecosystem: The first part is a smart city district platform. This platform ensures that all services are running, that basic services such as single sign-on are offered, and that the required software quality is ensured. However, we experienced that an operative platform is sometimes not adequate for testing early prototypical solutions. Therefore, we developed a mock platform in addition. This mock platform gives us the opportunity to test new ideas and prototypical services very fast without considering qualities such as security or performance, which would be needed for an operative platform. The second part is a set of concrete services, developed as web services, apps, or webpages, for example. We start with one example service (Section 3.2.1
) and provide details on our mock platform afterwards (Section 3.2.2
3.2.1. The MiniLautern Game
Instead of creating a mobility service that will be out of date in a few years, we decided to pave the way for future mobility services. Our goal is to support citizens on their way to accepting more climate-friendly mobility measures and adopting climate-friendly mobility habits. We defined five helpful milestones on that way:
Citizens share the attitude that novel mobility measures are desirable.
Citizens feel able to use novel mobility measures.
Citizens have the intention to change their mobility habits.
Citizens try new mobility measures for the first time.
Citizens establish new mobility habits.
These milestones are inspired by the Theory of Planned Behavior [27
]. For the first milestone, we developed the game MiniLautern, which we will describe in more detail next. To achieve the second and the fourth milestone, we suggest offering offline events such as guided cycling tours with bikes from the local bike sharing system. In this way, new users could ask for help when facing a problem with the system. Moreover, we designed two apps, one called KLaus and the other Fish n’ Tips (the latter was introduced in Section 3.1.2
). KLaus is a homepage that informs about novel local mobility measures including real persons’ experiences. For instance, it explains how to use e-scooters and how the local bike-sharing system works. The content should mainly stem from the users themselves. Fish n’ Tips makes suggestions about which mode of transport is best for which trip and which is most environmentally friendly. For the fifth milestone, we developed Luba, an app supporting a competition between teams. The participants receive points for using environmentally friendly transportation modes. The competition should last for several weeks so that the participants can establish new mobility habits.
The basis for the game MiniLautern and the homepage KLaus was created during a Design Sprint [28
]. Over the course of five days, an interdisciplinary team interviewed experts in the field of mobility and citizens of the city of Kaiserslautern, generated multiple ideas and concepts, and put them together in two prototypes. Involving the experts and citizens, we got an idea of the citizens’ current attitude and requirements on mobility measures. After the Design Sprint, we continued developing the game; we elaborated the game concept and developed a web app.
MiniLautern (short for tiny Kaiserslautern) is a single-player game with citizens of Kaiserslautern as its target group (see Figure 7
). The player should improve the district by establishing novel mobility measures in the smart city district in Kaiserslautern. The player can choose from a list of measures (e.g., reducing the number of parking lots, establishing mobility stations with rental bikes, cars, and scooters or a coworking space). The challenge is to select those measures that have the most positive effect on the quality of life and the individual happiness level of the residents and the least negative impact on the environment.
In each round, a player can elicit the citizens’ needs by reading about regular destinations, attitudes, and the living situation of a certain number of citizens. Then, the player selects a mobility measure and receives feedback regarding the impact on environment, quality of life, and happiness. Depending on how positive or negative the impact is, the player earns a certain number of points or gets them withdrawn. Most mobility measures in the game lead to a positive impact since this reflects the scientific forecasts and since we aim to establish or strengthen a positive attitude towards novel mobility measures.
We placed the focus on promoting acceptance instead of creating a new mobility service for the following reasons:
First, the mobility market is currently undergoing major changes, at least in Germany. In cities, there is a shift away from privately owned cars towards public multi-modal mobility services. This upheaval is being accelerated by legal regulations that promote environmental protection, for instance by carsharing, electric cars, and the reduction of parking spaces. Changing legal regulations and new technical possibilities regarding vehicles, such as autonomous vehicles, increase the difficulty to predict the mobility market. Moreover, start-ups as well as well-known automakers such as Volkswagen and BMW are experimenting with novel mobility services themselves. It is difficult to identify gaps in the market that should be supported by publicly funded research projects such as our project.
Second, mobility does not end at the borders of the district. Most trips will lead the residents to destinations outside the district. However, solely the district is the subject of our research. This limits the solution space for novel digital services.
To sum up, developing digital mobility services that will fit into a future multimodal mobility system and will fulfill future mobility needs is a huge challenge.
We assume that our game is a suitable way to create a positive attitude towards novel mobility measures and therefore promote their acceptance. By playing the game, citizens learn about the mobility measures and their potential for the smart city district. We assume that a game is an unobtrusive way to get in touch with the measures even if the players have low motivation to learn about the measures. Thus, the game is a suitable way of disseminating the vision of the smart city district (LQ2). Another advantage of the game is that the players have to elaborate on the effects of the mobility measures, which is one prerequisite for building a strong attitude according to the elaboration likelihood [29
The game includes various game mechanisms. For instance, there is a high score for players who like to compete with others. Some players are motivated by learning more about mobility measures [30
], while others enjoy helping the fictional citizens. Addressing several player types increases the likelihood that the game will appeal to many representatives of the target group.
As mentioned before, the players can inform themselves about the mobility needs of fictional citizens in the game. The fictional citizens represent various groups of the population, including families and students. At the beginning, we planned to describe future life situations since the future mobility measures are meant to suit these future life situations. For example, in the future, more and more people will work at least several days per week from home, making commuting to the workplace obsolete but increasing the demand for coworking spaces and carsharing. However, we also want the players to emphasize with at least one fictional citizen so that they feel more engaged. Therefore, the fictional citizens’ life situations reflect current life situations and not future ones. A persona template [26
] was used as a guideline for creating the description of the fictional citizens. On the basis of the template, we are easily able to create new descriptions (LQ3). Moreover, the game is technically designed in a way that makes it easy to replace text. In this way, we made the game future-proof, so that it can even be applied right after the district has been built, which is relevant as not all mobility measures will be implemented right away. Furthermore, new mobility measures could be included in a similar way (LQ3).
Presenting the mobility measures as part of a game allows us to even present measures that might not be realized. Since it is difficult to foresee the future, we cannot be sure which measures will indeed make it to the district, even if the project members work hard on their implementation.
The game will be part of an exhibition in the district. At the exhibition, we want to get in touch with visitors and receive their feedback about the game and the mobility measures. Some measures cannot be changed anymore at this time, such as the low number of parking spaces, but others such as sharing systems for bikes could be adjusted to their needs.
We advise project teams who consider a similar game to:
Identify the key message you want to convey so that you stay focused when creating the game concept.
Learn about typical game and gamification patterns so that the game captivates players from beginning to end.
Learn about player types, their motives, and their favorite gamification patterns (e.g., as provided by Marczewski [29
]) so that the game appeals to many people.
Learn about psychological theories regarding behavior and attitude change (e.g., Theory of Planned Behavior [27
], Elaboration Likelihood Model [30
]) so that the players can be persuaded in the most effective way.
Think about a setting that encourages players to be open-minded towards the content of the game (cf. Ellen Mask).
Think about a way to take critical voices regarding the content and core message serious so that even these persons engage in the game.
Think about a way in which the players could personally relate to the game and the mobility measures so that they deal more intensively with the topic.
Create guidelines for creating and updating content such as mobility measures and mobility needs, and create a flexible architecture of the game so that the game can be adjusted to future circumstances.
3.2.2. Mock Platform
A digital ecosystem for a smart city district accompanies the user throughout the day. This results in high requirements for security, safety, privacy/data protection, etc. However, these characteristics stand in the way of the initial development and testing of new ideas. In order for a concept to be tested in its full scope, it is necessary that the prototype that has been created is also used in the later platform context. If a future productive platform were to be used for this purpose, the effort to dock the prototype onto the platform would be very high, since all technical requirements would have to be met. Since this has to be done for each prototype, development is very costly, which can lead to concepts not being tested in the first place. To counter this problem, we developed a prototyping platform called mock platform.
The mock platform is a platform that is intended to support and thus simplify and accelerate the development of prototypes. For this to happen, it aims to reduce the complexity of the productively used platform in such a way that restrictions that are unnecessary for prototype development are reduced as much as possible. For example, complex authentication mechanisms could then be circumvented. However, it is important that it does not impair the basic functionality of the platform, namely, the linking of services. When developing the mock platform, it was also important to us that new platforms can be easily extended with additional services or new functionalities without having to make major adjustments to the existing system. This should make it possible to use the mock platform for a longer period of time. During the development of prototypes in the context of a smart city district, we noticed that functions such as communication between several applications on a smartphone have to be developed again and again. Since this unnecessarily extends the development time, the mock platform should also provide many basic functions that are needed again and again during prototype development, such as a function for creating users.
In order for the mock platform to meet the above requirements, the communication protocol must be designed to be as simple and open as possible so that any new applications can be easily docked. Therefore, we decided to use an event broker based on the MQTT protocol as the central communication node. This MQTT broker follows the publish-subscribe pattern over which everyone can send and receive messages without a sender having to know the receiver (see Figure 8
top). For this to be done, a message is published on the MQTT broker on a unique topic, which serves as an identifier for these types of messages. A recipient must first subscribe to this topic in order to have this message forwarded. Through different subscriptions, a recipient can easily specify what kind of messages they are interested in and can thus pre-filter the messages. Through this asynchronous communication, one is able to add new senders and receivers easily because they only need to connect to the MQTT broker to participate in the ecosystem. However, not every communication is supposed to be sent via the MQTT broker. Messages should only be published if they have an event character, i.e., if they describe a status change, e.g., that a bus has departed or the streetlights have been switched on. A communication between two applications should only happen in individual cases via separate topics. However, in general, direct communication, e.g., via REST-API, should be preferred because these messages are usually uninteresting for other participants of the ecosystem.
Generally, every sender can decide for itself in which form it publishes its messages and on which topic. However, the recipient must always be informed about this specification so that it can always receive and process the messages. Now it can be the case that similar information, e.g., in the Smart Home area, is published by each Smart Home instance in different ways. In this case, it would be necessary for a receiver that is interested in all Smart Homes messages to be adapted to each sender. To prevent this, we introduced so-called shared topics for several domains. These define for each domain exactly in which form the information has to be published and on which topic (see Figure 8
bottom). Because newly added senders have to adhere to these specifications, already existing recipients do not need to be adapted. Furthermore, new recipients can easily receive and process messages from a variety of existing senders successfully. For this reason, extensibility is easily ensured. The shared topics are predefined by us as the provider of the mock platform and can be extended at any time if required.
Thus, the mock platform enables easy connection of different services through its MQTT broker and the shared topics. As a second component, we extended the mock platform with a variety of services. These provide the basic functions that are needed again and again during prototype development. For example, there is a user service with which unique users can be created, a storage service that can be used as a central database, and a Smart Home simulator that can simulate a complete fictive Smart Home instance. These additional services are also connected to the MQTT broker and publish various events so that potentially everyone can see what is happening on the platform. If applications want to communicate with these additional services, this is realized via a REST-API, since this represents synchronous communication and the publish–subscribe pattern of the MQTT broker only provides asynchronous communication.
With this ecosystem enabled by the mock platform, many domains such as smart home, power monitoring and distribution, appointment and events, and communication of a smart city district can be covered. In the context of the project, several conceptual ideas or laboratory tests will be developed and executed. For example, in collaboration with the consortium partners, a Smart Home laboratory environment has been created, wherein Smart Home devices are intended to simulate a later inhabited apartment of the city district. The sensors and actuators, such as light switches, thermostats, door and window sensors, or electric shutter controls, collect data. This information is made public to all participants by connecting it to the mock platform. This can add value by automating the processing of another service. For example, energy-saving tips and reminders for the residents could be generated if they forgot to close a window when leaving the building, resulting in unnecessary heat energy loss in winter. On this basis, we created a Smart Home simulator that processes messages on the associated shared topic and displays them in a three-dimensional interactive visualization. Thus, it is already possible for users to visually experience how the future system will behave, without the existence of a real home at this point in time.
The mock platform was deployed at two hackathons, where it showed that it can indeed provide helpful support for realizing or implementing new ideas. Participants rated it as easy to understand, meaning that docking of an application could be done quickly. In addition, the mock platform made it possible to interconnect the individual groups of participants, which was also one of the goals of the hackathon, by making it easy to link their applications with each other. In the future, the mock platform will be extended by further scenarios. The integration of car charging stations or smart street lamps, which can measure, e.g., air quality through a multitude of sensors, are planned.
3.2.3. Summary and Conclusions
Our ultimate goal from a digitalization perspective is to have a digital ecosystem that supports different stakeholders in adopting a more climate-friendly behavior. This should be unobtrusive, interesting, and really helpful, to mention but a few of the characteristics of such an ecosystem, at whose center is a platform running various services and apps. As a productive digital environment is not reasonable at this time due to the construction work, we concentrated on a mock platform that enables us to test new ideas and prototypes fast (LQ2, LQ4) and is flexible for future applications (LQ3). Where possible, we connected prototypes to real-world objects, such as Smart Home devices, or plan to do so in the future, e.g., for electric vehicle charging stations or a smart light bulb (LQ4). These concrete examples also make it possible for citizens and other stakeholders to understand how digitalization can support them and where advantages exist for them. Smart Home is an evolving trend, and we are able to show simple application cases to support citizens in their daily life with a Smart Home simulator running on the mock platform (LQ2, LQ4). Another way and example to inform citizens and, ideally, convince them to change their behavior to a more climate-friendly one is our MiniLautern game, where new mobility concepts are explained, but which also shows that change is not easy and does not suit all people (LQ2–Q4).
3.3. Dissemination and Events
The third part is dissemination and events. From the beginning, our goal was to communicate with many people. We wanted to spread our project ideas and how digitalization can provide support in many different facets when a smart climate-friendly city districted is created. However, we were also highly interested in feedback from citizens independent of whether they live in the future district or not. We wanted to reduce barriers and fear on the part of citizens and spread a positive understanding of what happens in the actual city district. For this, one early big idea was to organize a hackathon (Section 3.3.1
). Having no experience in organizing and conducting such an event, this took a large amount of effort. We later present details on what exactly this meant, but we can also state that this was a great idea in several regards. A second idea that we share here is a kind of workshop—a physical place in the Pfaff district for the discussion of digital topics, the creation of new solutions, and the transfer of knowledge, as well as where people should have an opportunity to come together to advance digitalization topics further (Section 3.3.2
). Our third example is from very early in the project where we had the opportunity to participate in a larger event, present our initial ideas, and collect feedback from citizens (Section 3.3.3
In an effort to come up with a solution approach for creating a large number of potential ideas that reflect the general vision of the future smart city ecosystem, we have planned, organized, and conducted yearly hackathon events. In general, a hackathon (neologism: hacking and marathon) is an event lasting between several hours (synchronous) and several weeks (asynchronous). Participants come together to creatively solve given challenges or problems, with or without restrictions on the technology to be used. Solving the challenges or problems and using the available technology in a clever and creative way refers to the “hacking” in the word hackathon. Hack(ing) is used in the sense of exploratory, playful programming and technology use, not in the sense of computer crime. The “marathon” part of a hackathon is based on the idea of a prolonged event (e.g., lasting 24 h without specific breaks) that challenges participants’ endurance and skills. For our hackathons, we called out challenges related to the future smart city district with a focus on supporting or enforcing climate-friendly behavior (climate-friendly perspective). Participants partly provided the user and developer perspectives and we added the technical and organizational perspective through the technology we provided, talks, and facilitator support. Up to now, we have organized three hackathons (2018–2020) with a total of over 100 participants, each with a different focus area, varying target audience, specific circumstances, and high-quality results.
Each of the three hackathon events followed common ideas and guiding principles, although their actual design did vary. Table 1
summarizes the major aspects of the three event instalments, discusses their main differences, and outlines the overall structure and focus of each hackathon. Figure 9
shows impressions of two of the three events.
All three hackathons provided valuable results that served as input for our research project. In total, 17 prototype solutions or solution concepts for challenges of climate-friendly smart city districts of the future were identified and created by the events’ participants. The number of solutions scales linearly with the number of participants, but this increases the risk of teams doubling on specific challenges or coming up with similar ideas. Hence, we learned that a decision needs to be made about the size of the event. The organizer needs to provide facilitators and support, guide the teams, and provide food and beverages and the event location (either on-site or the virtual collaboration tools). One cannot deny the effort required for planning, organizing, and conducting such an event. However, we see that the results are worth the effort. The quality of the results varied, depending on the technical skills of the participants. Nevertheless, they all provided a good understanding and visualization of the intended value proposition, making visions of future applications in the climate-friendly smart city ecosystem context tangible.
One may raise the question whether the effort we invested was worth the outcomes. Each hackathon event required serious investment in terms of person-days. The first hackathon event held in 2018 required approximately 40 person-days for event planning, organization, meetings of the organization committee, event facilitation, and follow-up activities. On top of this, the event required an investment of approximately EUR 2500 for catering and giveaways (e.g., custom T-shirts with the event logo), but these costs were taken over by external sponsors.
We anticipated that the investment in person-days would decrease for the second and third iterations of the event, but due to lessons learned, optimizations, and changing requirements (e.g., due to the remote event in 2020), the effort did not decrease significantly. Would the effort have been better invested in other project activities? In the following, we discuss this with respect to our four lead questions.
Does the hackathon help to elicit user requirements, without actual users, to gather such information without knowing the future citizens of such a city district (LQ1)? Overall, our experience was that the hackathons did not provide major benefits over other activities in this regard, even though the participants might be future users. Our participants were not requirements engineering professionals, nor did the events enforce specific user research activities in advance (e.g., interviews, field studies, observations). However, we did provide the proto-personas detailed in the ICT concept (see Section 3.1.1
). We saw that the participants working on the challenges and creating solution scenarios and prototypes just did their best, making educated guesses. However, due to the broad audience and the participants’ various backgrounds (i.e., age, social peer groups, country of origin, skills, experience), they reflect a broader part of the general society than the researchers working in this project. Additionally, through talks, documentation, and facilitation activities, we provided input to the participants about the lessons we had learned up to that point. Hence, we conclude that they were able to work with unknown requirements such as other project members. As the participants approached the challenges and problems more naïvely, they did come up with problems we did not consider worthwhile until they showed their solution proposals (e.g., a city gardening support application to increase the consumption of self-grown vegetables and thus reduce the carbon footprint of users, support for home composting through temperature sensors for optimal processes).
In addition, the broad array of solution proposals supports dissemination activities, as different visions of future smart city applications resonate with different target audiences depending on their own requirements and needs. This supports the communication of visions, concepts, and future solutions without having actually implemented them (LQ2). Additionally, the events’ participants serve as ambassadors and create a multiplier effect when they talk to their peers about the event. The word-of-mouth effect with respect to the events is hard to measure, but we strive to support this as much as possible. Marketing and dissemination activities are designed to reach an audience as broad as possible through email newsletters, the event website, leading and follow-up blog articles on our institute’s website, local newspaper articles, and guest contributions at local radio stations. This supports drawing attention to the project’s goals and achievements in general, and to the specific solutions created during the hackathon events.
How well do hackathons support dealing with the challenge that needs will change in the future until the concrete implementation of digital solutions and their usage by citizens (LQ3)? This problem is transformed into a feature during the hackathons, as the goal is not to implement a production-ready solution but a mere prototype to show what could be possible in the future. The underlying concept is to quickly test ideas and create awareness. A large number of participants have been students of computer science and related fields, who might be the future designers of smart city applications themselves, and the awareness for the hackathon’s challenges may potentially influence their future activities.
Finally, we want to discuss how to test visions, concepts, ideas, and prototypical implementations without users within the hackathon setting (LQ4). Our events ended with the teams pitching their value propositions and ideas to the other teams and, in the case of the first two events, to the jury. These pitches already served as small tests, obviously with a limited audience, but helped to uncover hidden problems and opportunities. The jury members rated the ideas on the basis of their professional experience and know-how, and the other teams’ reactions supported this by providing a more general perspective. At least one of the teams participating in the second hackathon continued working on their idea and solution, which led to them winning a prize in an innovation competition funded by a German federal ministry.
Hence, we conclude that the hackathon events were indeed worth the effort with respect to our leading questions in particular and the project’s goals in general. The fact that the events have changed their shape and have been adapted to reflect the current state of the project is a strength from our point of view, although this increases the difficulty of comparing them. For us, learning from the participants’ feedback is as important as being open for innovation and adapting to new requirements and circumstances.
3.3.2. City District Workshop for Information and Communication Technologies
In the future city district, we can use a historical building to present our project (and along with this climate-friendly city district topics), but also to create new solutions. In this building, which is currently being restored, there will be an exhibition, but it will also house a so-called city district workshop. In this workshop, we want to elaborate different digital topics with citizens in the area of climate-friendly solutions.
We will especially focus on two main objectives: First, we want to convey and teach (LQ2), and second, we want to design and develop solutions together (LQ1, LQ3, LQ4). Thereby, we want to make the topic of digitization tangible and experienceable. Concretely, as the topic is very broad, we will focus how the digital transformation can support a climate-friendly city district. Actual prototypes and our mock platform may make solutions very concrete. Furthermore, with events such as hackathons taking place in such a workshop room, we can reach people and bring them into contact with such topics.
In essence, we want to address two target groups: technical/digital non-experts and technically/digitally experienced persons. For the non-experts, the threshold must be very low and interest in digital topics needs to be stimulated. Such persons want to learn more and try things out for the first time. Our goal here is to break down barriers and create interest so that they can also take something away and implement it in their everyday life. The experts have two main roles: First, they can teach certain topics to non-experts and help them. Thereby, they support our topics and act as a kind of multipliers. Second, they also want to create concrete solutions. For this, they need interesting opportunities, for example competitive events or equipment that they do not have in their personal environment, but which they want to use to create solutions.
In order to reach both target groups, the city district workshop (a) must be known to them, and (b) has to be as attractive as possible. These two aspects are two concrete “requirements” for us when developing this workshop. A third requirement is (c) to cope with the challenge that it will take several months to really use the building, which is, as mentioned above, still under construction. A fourth demand is (d) to be very flexible, as different kinds of usage of the workshop should be possible. Table 2
shows solution ideas to these major requirements.
In order to develop the city district workshop, we had to answer several questions in the beginning: What is our goal? Who is our target group? What material and equipment do we need? What are our major requirements? All of these questions were first discussed internally. As the project has already been ongoing for about three and a half years and the workshop is being built in our hometown, we already learned quite a large amount about this specific environment and have been able to talk to citizens about the future city district. We furthermore have concrete experience from the past in developing creativity rooms. This knowledge was used by our experts to elaborate the future workshop. We decided to develop our workshop into a “learning and creation room” for digital topics around climate-friendliness, focusing on non-experts (i.e., citizens) and experienced digital people. We decided not to focus only on one concrete room, but to give the workshop a more mobile character so that we can “apply” the workshop everywhere. Of course, not all application cases can be used everywhere, but it is our general intention to pursue certain application cases independent of the location. The advantage of this idea is that we can already use the workshop although the building and the concrete room are not available yet. With this, we can already communicate the topic and talk to citizens and work with them (LQ2).
When the concrete room will be available in the future, the workshop will already be known to a certain extent, as will be the topic of climate-friendliness and how the digital transformation can support this. Of course, to be able to be mobile, our material and equipment has to be flexible. We need cases to transport material, and the equipment itself may not be too large. For example, we plan to have equipment such as a milling machine or a 3D printer. These are examples of equipment that makes the workshop attractive even for experienced persons, as such equipment is typically not available at home, but everything needs to be small and lightweight enough to be able to transport it. Further equipment examples are sensors and actuators for smart homes, moderation material, or even our mock platform for creating digital services (LQ1, LQ4).
We also strive to perform different events in our workshop (LQ1–LQ3). These may be talks, presentations to share knowledge and teach certain topics, but also hackathons that are highly interactive and force participants to create solution prototypes together. Such events will make the workshop attractive and can be used to spread the topic to the public. The participants will gain new knowledge and can then use this to further develop the district. In addition, because of the COVID-19 pandemic, such events can currently not be performed in person, and therefore we are also making video and streaming equipment part of our workshop. This enables us to communicate with citizens and experts during events via video and allows us to create concrete solution prototypes already.
A typical challenge with research projects and outcomes is the question of how to use them after the project is done. In our case, we and other project partners will be able to use the workshop as a dissemination tool, but also for creating further solutions. Due to the mobile and modular character, we can already use the workshop now even though the actual building that will house it is still under construction (LQ1–LQ4).
3.3.3. Event “Night of Science”
During the course of the project, we had the opportunity to be part of cultural events offered by the city itself. One such example is the “Night of Science”, an event where citizens and researchers all across the city present current topics and discuss them with people visiting the different booths. This was a great opportunity for us. First, we presented early ideas on how we understand the digitalization of the Pfaff city district, gave a brief overview of the project itself, and described the partners involved. Second—and that was the more important part for us—we wanted to use the opportunity to obtain initial feedback from the citizens. As already mentioned, the topic is relevant for many citizens of Kaiserslautern, as Pfaff used to be a big employer and some of the citizens who visited the booth had worked for Pfaff in the past. We wanted to talk to them, obtain ideas from them, and understand their feelings regarding the city district. In addition, we asked for direct feedback and created two posters for this purpose. On these posters, we explained the topics we address in the project so that people could first read about the project. We asked them whether they were interested in talking with us and invited them to participate in a very easy way. We had prepared four tasks for this on a DIN A0 poster:
We asked which mobility measures they were currently using most. We prepared answers, and they could post a sticker in the respective parts.
We asked what an app looks like that supports saving energy. They could use free text to answer this.
We showed a very early prototype of a communication app and they could post emoji stickers indicating how they liked it.
We asked very generally what they think about digitalization.
We made sure that the barrier for everyone was very low and did not force anybody to participate. However, many citizens talked to us and gave us early feedback on the posters (Figure 10
Of course, it is largely unlikely that the citizens who gave us input were people who will live in the Pfaff district in the future. Nevertheless, as an early feedback session, this was a great possibility as we did not have to organize a huge event but could simply focus on preparing our booth and being present on the day of the event (LQ1, LQ2, LQ4).
We also want to mention that creating those posters was time-consuming. Questions like “what to present”, “how to present”, and “how to create easy ways to invite citizens to participate” were not easy to answer, and creating a nice-looking poster also took some effort. However, the results were worth the effort from our perspective.
3.3.4. Summary and Conclusions
Promoting concrete solutions, spreading new ideas, and convincing citizens with concrete solutions are some goals of dissemination activities. We do, of course, also use traditional and standard ways, such as a project webpage or articles in the press. However, we did not only share ways of how to inform the public, but also how to gather feedback from them. For this, we organized three hackathons, and plan more in the future (LQ1–Q4). While this was a time-consuming task in terms of preparing and conducting these events, it was very worthwhile with respect to, for instance, including people outside the project, developing new prototypes, and sharing our ideas. A newly developed mobile workshop will be used as a flexible place to again create new solutions, disseminate ideas, and offer events to citizens (LQ1–LQ4). Such events can be used to teach new ideas or topics, but also for discussions, including discussions with citizens. Finally, the third example was the Night of Science event in which we participated and where we also had the chance to talk to citizens and understand their feelings and thoughts regarding the recreation of the Pfaff district as a climate-friendly district and how digitalization can support this (LQ1, LQ2, LQ4).