In Autonomous Public Transport (APT), particularly with shuttle buses, passengers travel in smaller, more intimate vehicles—and in the future, such vehicles may operate without an authoritative driver or host. This setup may lead to potential safety concerns, as passengers are left alone together. Additionally, this future absence of a driver or host means that there is no one to address questions or uncertainties that may arise. One proposed solution is introducing a robot onboard the bus, serving a similar role to a human host. To explore this solution, an experiment was conducted in Barkarby, Stockholm, Sweden. Passengers, generally unfamiliar with APT or social robots, experienced two short rides on a bus equipped with either an embodied Furhat robot as the host or a disembodied voice agent in the ceiling. Data were collected from passenger-agent interactions, post-questionnaires, and semi-structured focus group interviews. Results indicate a division in passenger preferences, with some favoring the robot and others the voice assistant. Passengers asked more questions to the robot, suggesting a clearer affordance for interaction. While the questionnaires did not show significant differences, passenger behaviors indicated that they anthropomorphized the robot more. The interviews revealed that passengers felt more secure with a human operator and doubted the robot’s authority during incidents with aggressive passengers or accidents. Our findings show that social robots can help make autonomous buses feel more welcoming and interactive. Future APT systems have many design issues that need to be resolved before riders can find them safe and appropriate to use, and social robots can play a role in resolving such issues—both the ones we see today, and potentially ones that will appear in the future.

Virtual Reality (VR) locomotion methods are mainly ground-based, room-scale, or discrete, making them ill-suited for flying experiences. Although leaning- and controller-based techniques are promising for flying in VR, we lack empirical evidence of their advantages. We compared combinations of leaning- and controller-based methods for steering and velocity in a user study (N = 24) using a broom metaphor to integrate these methods into an understandable locomotion reference. The steering methods were: 1) controller-pointing (CP) and 2) headset-leaning (HL); and for velocity control: 1) controller linear displacement (CLD) and 2) headset linear displacement (HLD). Results indicate that HL increase presence compared to CP. However, combining HL with CLD worsens coin collection rate, completion time, mental load, control factor ratings, and enjoyment. In contrast, HLD worked well when paired with either steering method. CP-CLD led to the highest coin collection rate and lowest mental load. All methods had comparable feelings of flying.

JavaScript packages are notoriously prone to bloat, a factor that significantly impacts the performance and maintainability of web applications. While web bundlers and tree-shaking can mitigate this issue in client-side applications, state-of-the-art techniques have limitations on the detection and removal of bloat in server-side applications. In this paper, we present the first study to investigate bloated dependencies within server-side JavaScript applications, focusing on those built with the widely used and highly dynamic CommonJS module system. We propose a trace-based dynamic analysis that monitors the OS file system, to determine which dependencies are not accessed during runtime. To evaluate our approach, we curate an original dataset of 91 CommonJS packages with a total of 50,488 dependencies. Compared to the state-of-the-art dynamic and static approaches, our trace-based analysis demonstrates higher accuracy in detecting bloated dependencies. Our analysis identifies 50.6% of the 50,488 dependencies as bloated: 13.8% of direct dependencies and 51.3% of indirect dependencies. Furthermore, removing only the direct bloated dependencies by cleaning the dependency configuration file can remove a significant share of unnecessary bloated indirect dependencies while preserving function correctness.

Creating Mixed Reality applications poses distinct challenges for development and design. One of the challenges is designing Mixed Reality application-specific experiences in the wild. In this paper, we present a structured reflection approach to revisit projects from the past. In applying this structured reflection to the data collected during a nine-month industrial project, we unveiled the Virtuality-Reality Clash. To generate a sufficient data corpus, we structurally analysed git commits, tickets, emails, handwritten notes, and weekly snapshots of the 3D designs. The clash could be narrowed down in our data corpus to the situations in which we were fusing the real environment with the virtual content. Finally, we could find five design patterns for MR experience. With these patterns, we aim to help developers and designers of MR applications identify situations where Virtuality and Reality clash and propose approaches to address them.

Rowing has great potential in Virtual Reality (VR) exergames as it requires physical effort and uses physical motion to map the locomotion in a virtual space. However, rowing in VR is currently restricted to locomotion along one axis, leaving 2D and 3D locomotion out of the scope. To facilitate rowing-based locomotion, we implemented three steering techniques based on head, hands, and feet movements for 2D and 3D VR environments. To investigate these methods, we conducted a controlled experiment (N = 24) to assess the user performance, experience and VR sickness. We found that head steering leads to fast and precise steering in 2D and 3D, and hand steering is the most realistic. Feet steering had the largest performance difference between 2D and 3D but comparable precision to hands in 2D. Lastly, head steering is the least mentally demanding, and all methods had comparable VR sickness.

As programming is typically a static activity in front of a screen, we perform an initial exploration around the capabilities of block-based programming in the immersive space using Virtual Reality (VR) to make an early charting on how programming could involve moving the programmer’s body. We created a block-based programming interface in a VR space called BlocklyVR based on the existing Blockly programming environment. To investigate programmer performance and experience in BlocklyVR, we conducted a controlled lab experiment (N = 20) with eight programming tasks that covered mathematical operations, if-statements, and function creation. Our initial exploration contributes by classifying movement types made by BlocklyVR programmers and reflecting on how these movements are related to the programming tasks. Additionally, our data suggests that participant performance in BlocklyVR was not affected compared to the 2D Blockly, even if participants were physically moving in VR space. We also found that the virtual reality sickness was marginal. Lastly, we identified four types of interaction that can potentially be employed by VR designers and developers aiming to convert a static task, like programming at a desk, into a “mobile” immersive experience.

Walk-in-Place is an established locomotion technique for walking in virtual environments, as it incorporates body motion similar to regular walking. Although there is extensive research on the performance and experience of walking in virtual reality spaces, it typically requires minimal-to-moderate physical movement, e.g., stepping forward and turning around, to explore virtual spaces. Therefore, the question we ask ourselves in this work is how user experience and performance are affected when the user is actively moving in place. In this paper, we explored three body-steering methods for jogging-in-place in virtual environments: (1) head-, (2) hand-, and (3) torso-based. To investigate the performance of the proposed body-steering methods for jogging in virtual reality, we conducted a controlled lab experiment (N = 12) to assess task completion time, number of steps, and VR sickness. We discovered that hand- and torso-based methods require fewer steps than the head-based method, and the torso-based is slower than the other two. Moreover, the number of collisions and virtual reality sickness were comparable among the methods.

Design of eco-feedback has primarily aimed at persuading individuals to change behaviours into more environmentally sustainable ones. However, it has been questioned how effective such feedback is in supporting long-term change. As an alternative focus for energy feedback, we present a case study of amateur energy management work in apartment buildings owned by housing cooperatives, and the design of an app that aims to stimulate and support cooperatives in taking energy actions that significantly reduce the cooperative's collective energy use. By linking energy data to energy actions, the users can see how actions taken in their own and other cooperatives affected the energy use, learn from each other's experiences and become motivated as energy amateurs. Based on our housing cooperative case, we reflect on design aspects to consider when designing for energy management in amateur settings.

The use of practices as a unit of analysis has been suggested in order to scale up efforts within sustainable HCI and to shift the focus from changing individual behaviours to supporting transitions at a societal level. In this paper, we take a practice approach to the case of sustainable transportation, and more specifically to car-free transportation. Car use is intertwined in many practices and managing life without a car is difficult, particularly for people in contexts where owning at least one car per family is the norm. We studied three families in Stockholm who replaced their cars with different combinations of light electric vehicles during one year. From the families' experiences, we identified a number of opportunities for designers of interactive technologies to support environmental pioneers in the particular case of car-free living, as well as to support transitions towards sustainable practices in general.

The trend of “open data” coupled with the recent advancement in web development technologies and the proliferation of JavaScript frameworks has helped popularize programming of interactive web applications. Still, some of the common features of today's web applications that access data from own data stores or from web services require a complex setup or a significant amount of programming knowledge, and thus make it hard for developers to quickly prototype applications and iterate on solutions. Therefore, we propose Endev, a declarative framework for prototyping applications that use cloud data storage or web service data. By not needing to write any JavaScript code or set up any servers, Endev provides a low learning threshold. We show that Endev is perceived useful and easy to use through a study with 15 developers.

Energy and design of energy-feedback are becoming increasingly important in the mobile HCI community. Our application area concerns electric vehicles, we thus depart from home and workplace appliances and address range and energy anxiety caused by short driving distance capabilities and long charging times in mobile settings. Meanwhile some research has been done on energy management of mobile devices, less has been done on mobility devices like electric vehicles. We explore this topic by letting conventional fuel car drivers reflect on their current driving habits through an exploration tool that we developed. Our results demonstrate three dimensions related to energy availability to consider for design of energy dependent mobility devices and provide explanations on how these dimensions could be utilize in our design through energy visualizations. With this we contributed not only by demonstrating aspects of energy availability and mobility, but also through opening up for new interesting possibilities and inquires in our and possibly other domains.

End users of software typically have to let someone else develop it and its user interface, or to learn to design and to program it themselves. Especially user interfaces developed by someone else may not fit well the given task. Designing and programming is hard and takes a lot of effort in general, and even more so for people not especially trained or experienced.