Search

In autonomous mobility-on-demand (AMoD) systems, passengers will solely interact with autonomous vehicles via digital user interfaces (UIs). Hence, UIs are crucial for acceptance and user experience (UX). As a foundation for deriving empirically grounded design guidelines, we investigate two approaches for mobile interaction: chatbots and ‘classic’ graphical UIs (GUIs). We evaluated prototypes of both in expert studies (nGUI = 6; nChatbot = 5) and a between-subjects simulator user study (n = 34). The latter enabled participants to experience a complete AMoD journey. While both concepts receive good acceptance and positive UX evaluations, the GUI results in significantly higher attractiveness and user satisfaction ratings. A significant interaction effect reveals a higher intention to use the chatbot in scenarios with a change of plans, but the GUI in ‘happy path’ scenarios. Interview data and emotion curves support this effect. Balancing the concepts‘ advantages and disadvantages, we provide design recommendations and propose to use GUI-based mobile applications with integrated (text-based) conversational elements for future human-AMoD interaction.

Unit testing is reported as one of the skills that graduating students lack, yet it is an essential skill for professional software developers. Understanding the challenges students face during testing can help inform practices for software testing education. To that end, we conduct an exploratory study to reveal students' perceptions of unit testing and challenges students encounter when practicing unit testing. We surveyed 54 students from two universities and gave them two testing tasks, one involving black-box test design and one involving white-box test implementation. For the tasks, we used two software projects from prior work in studying test-first development among software developers. We quantitatively analyzed the survey responses and test code properties, and qualitatively identified the mistakes and smells in the test code. We further report on our experience running this study with students. Our results regarding student perceptions show that students believe code coverage is the most important outcome for test suites. For testing practices, most students were ineffective in finding known defects. This may be due to the task design and/or challenges with understanding the source code. For testing pitfalls, we identified six test smells from student-written test code; the most common were ignoring setups in the test code and testing happy path only. These results suggest the students needed more introduction to these common testing concepts and practices in advance of the study activity. Through this experience, we have identified testing concepts that require emphasis for more effective future studies on testing behavior among students.

In the first two chapters, we introduced you to voice interaction technology and the reasons why some things are harder to get right than others for humans and machines in conversational interactions. Now it’s time to jump in and get your own simple voice-first interaction up and running. You'll stay in the familiar food domain; it’s a convenient test bed for introducing the core concepts—finding a restaurant is probably something you’re familiar with, and it covers many voice-first concepts. The task of finding a restaurant seems simple, but things get complicated fast. When you expand functionality to deal with real users, you’ll stray from the “happy path” quickly, but let’s not worry about real life yet.

As the evolution of Process Mining has not always been on the happy path, the idea of learning from failure has been adopted as a guiding principle for this book, applicable to this chapter as well as to the use cases in Part II. This chapter presents ten samples, reflecting challenges which were posed, pitfalls which were learned hands on, and failures which have been experienced. Samples range from data availability to process conformance checking and shall help the reader to avoid similar experiences.

Extracting and exploiting the flexibility of electric demand has been shown to reduce the needs of network upgrades and generation capacity increases. Demand Response (DR) in considered as one of the few available solutions for accessing the untapped energy potential of small and medium customers. Over the past decade, rigorous research has produced significant results in optimally dispatching DR in an attempt to maximize flexibility extraction. However, the vast majority of works assumes a “happy path” scenario in which DR requests are always successfully completed. Hence, there is a large gap in the literature that fails to account for non-deterministic factors that manifest in practical deployments, e.g., the stochasticity of end-user behavior that can drastically influence the DR's outcomes. Investing on that notion, a novel, distributed, multi-agent system (MAS) that aggregates consumers and prosumers and handles automatically OpenADR-compliant DR requests is introduced, following virtual power plant (VPP) principles. Agents of the proposed MAS are able to service DR events originating from a higher level, e.g., Aggregators or Utilities, and optimally dispatch them to their assigned customers. The proposed framework ensures 100% DR success rate, compared to conventional methods, by not only optimally exploiting aggregated flexibility through a combination of clustering and optimisation engines, but also through a dynamic, bi-directional DR matchmaking process that can mitigate observed deviations both internally (intra), as well as, externally (inter) in real-time. Via experimentation, we demonstrate the framework's efficiency in ensuring technical DR fault-tolerance along with its ability to deliver savings of up to 3 orders of magnitude to Aggregators and the customers serving the DR requests.

To simplify the evaluation and certification process for mobile medical applications, a methodology for simple testing has been developed.For this purpose, certain actions of the apps are provided with timestamps in order to be able to reproduce the entire behavior of the testers within the scope of the test study. Therefore, the tester does not have to come to a test laboratory to fulfill certain tasks that are set by the test leader. Nevertheless, all main and secondary functions are tested naturally, as is the entire app.With the help of these asynchronous remote tests, the testers can test the medical app in their familiar environment. Thus the test environment is not present and the testers act naturally. The timestamps are not noticed by the testers and require only little additional programming effort.The results are automatically transferred to a database of the developer and evaluated in terms of usability, compliance, risk factors, learning curve and validity. It is possible to automatically compare the timestamp with a previously defined Happy Path and other previously defined reference values.

The paper describes the second part of the happy path of a user transaction through a Hyperledger Fabric Blockchain Network. The full cycle of a user transaction originates from the Client Application (an actor outside the Hyperledger Ledger Network but inside an organization that is part of a set of organizations that jointly run the Hyperledger Fabric Blockchain Network). In the process of making the Hyperledger Fabric Blockchain network knowledge explicit, essential parts of FBM were applied in cooperation with the developers of the Fabric Blockchain platform.

(a) Situation faced: Business process models serve various purposes. As precise documentations of an implemented business processes, they provide inputs with which to configure process monitoring systems, enabling the specification of monitoring points and metrics. However, complex business processes have a quantity of variants that can impede the activation of process monitoring. To mitigate this issue, we seek to reduce the number of process variants by performing behavioral analyses. (b) Action taken: Variants of a business process originate from points in the process model where the control flow might diverge, such as at decision gateways and racing events. We systematically identify the underlying semantics to choose from a set of alternative paths and characterize the resulting variants. This effort offers the opportunity to reduce the variability in business processes that is due to modeling errors, inconsistent labeling, and duplicate or redundant configurations of these points. (c) Results achieved: For a sub-process of an order-to-cash process from the e-commerce industry, we discovered 59,244 variants, of which only 360 variants lead to a successful continuation of the process. The remaining variants cover exception handling and customer interaction. While these variants do not lead to a successful outcome and might not qualify for the “happy path” of this process, they are crucial in terms of customer satisfaction and must be monitored and controlled. Using a set of methods (actions taken), we reduced the number of variants to 11,000. These actions reduced overhead in the process and normalized decision labels, thereby significantly increasing the process model’s quality. (d) Lessons learned: We elaborate on the impact of variants on the configuration of a process monitoring system, and show how the number of model variants can be significantly reduced. Our analysis shows that the semantic quality of the process model increases as a result. This reduction effort involves a structured approach that considers all variants of a business process, rather than focusing only on the most frequent or most important cases.

Software processes have to be flexible in order to handle a wide range of software project types and complexities. Large companies that depend on custom-built software may therefore define different software processes in order to adapt to different recurring project contexts (e.g., hot-fix versus migration projects). However, the stakeholders do not always follow the intended “happy path”—not the least because any software project typically has to deal with a considerable amount of uncertainty. Following an agile process may not be possible due to a company’s culture or policy restrictions (e.g., in the healthcare or financial domain) though. In this chapter, we present an approach to introduce more flexibility into software process models by adapting case management techniques to the domain of flexible software process management, in order to cope with key issues that come with software process evolution. Key functionalities of the approach have been implemented in a prototype and showcased to developers and architects via a live experiment. The feedback is promising as it shows that the approach helps to quickly identify context-specific actions and artifacts. This in turn reduces effort in structuring the daily work of software process stakeholders in an environment of evolving process elements specific to different kinds of projects, roles, and technologies.

Mapping apps are the greatest game-changer for encouraging people to explore the city. You take your phone out and you know immediately where to go. However, the app also assumes there are only a handful of directions to the destination. It has the power to make those handful of directions the definitive direction to that destination. A few years ago, my research started to focus on understanding how people psychologically experience the city. I used computer science tools to replicate social science experiments at scale, at web scale [4,5]. I became captivated by the beauty and genius of traditional social science experiments done by Jane Jacobs, Stanley Milgram, Kevin Lynch[1,2,3]. The result of that research has been the creation of new maps, maps where one does not only find the shortest path but also the most enjoyable path [6,9]. We did so by building a new city map weighted for human emotions. On this cartography, one is not only able to see and connect from point A to point B the shortest segments, but one is also able to see the happy path, the beautiful path, the quiet path. In tests, participants found the happy, the beautiful, the quiet paths far more enjoyable than the shortest one, and that just by adding a few minutes to travel time. Participants also recalled how some paths smelled and sounded. So what if we had a mapping tool that would return the most enjoyable routes based not only on aesthetics but also based on smell and sound? That is the research question this talk will start to address [7,8].

While many educators have added software testing practices to their programming assignments, assessing the effectiveness of student-written tests using statement coverage or branch coverage has limitations. While researchers have begun investigating alternative approaches to assessing student-written tests, this paper reports on an investigation of the quality of student written tests in terms of the number of authentic, human-written defects those tests can detect. An experiment was conducted using 101 programs written for a CS2 data structures assignment where students implemented a queue two ways, using both an array-based and a link-based representation. Students were required to write their own software tests and graded in part on the branch coverage they achieved. Using techniques from prior work, we were able to approximate the number of bugs present in the collection of student solutions, and identify which of these were detected by each student-written test suite. The results indicate that, while students achieved an average branch coverage of 95.4% on their own solutions, their test suites were only able to detect an average of 13.6% of the faults present in the entire program population. Further, there was a high degree of similarity among 90% of the student test suites. Analysis of the suites suggest that students were following naive, "happy path" testing, writing basic test cases covering mainstream expected behavior rather than writing tests designed to detect hidden bugs. These results suggest that educators should strive to reinforce test design techniques intended to find bugs, rather than simply confirming that features work as expected.

Traditional S-BPM successfully focuses on standardized business processes which are performed according to a fixed predefined process model. Yet a substantial share of business processes is difficult to predict with exceptions to the core processes occurring frequently.

Modern lifestyles disconnect people from nature, and this may have adverse consequences for the well-being of both humans and the environment. In two experiments, we found that although outdoor walks in nearby nature made participants much happier than indoor walks did, participants made affective forecasting errors, such that they systematically underestimated nature’s hedonic benefit. The pleasant moods experienced on outdoor nature walks facilitated a subjective sense of connection with nature, a construct strongly linked with concern for the environment and environmentally sustainable behavior. To the extent that affective forecasts determine choices, our findings suggest that people fail to maximize their time in nearby nature and thus miss opportunities to increase their happiness and relatedness to nature. Our findings suggest a happy path to sustainability, whereby contact with nature fosters individual happiness and environmentally responsible behavior.

Development is over, the beta is out in the wild, and for the first time in weeks, you can sit back and relax. Right? Well, it’d be great if things were that easy, but they aren’t, and now you’re getting bug reports. Things are crashing, things are slow, and people are finding new and uncharted user journeys, which take them far away from the happy path you so carefully laid out before them.