ref: 8f0e673b7d5677a1b29a4fdd045c7a88d2008994
dir: /touchuichal.txt/
[[[ms .FP lucidasans . \" no header .ds CH " . .HTML "Designing for Touch: Bringing the Plan 9 User Experience to Modern Devices" .TL Designing for Touch: Bringing the Plan 9 User Experience to Modern Devices .AU Joel Fridolin Meyer joel@sirjofri.de .AI .AB The Plan 9 operating system has a specific idea for user interaction and user interfaces. In general, many aspects are well thought out and provide a mostly consistent look and feel throughout the whole operating system. However, all user interaction components are designed for a standard computer system: A computer screen paired with keyboard and mouse for interaction. In this paper we will explore different challenges we encounter when designing a specialized touch user interface for Plan 9 systems. .AE ]]] # Why do we need a touch user interface? The world is changing. Especially in the last decades computer systems changed from expensive pieces of hardware to much smaller systems that embed everything into one device. While most computing expensive tasks are moved to the cloud, a full computer system is often not bigger than what can comfortable fit in your hand. [[[ms .\" quote of some dude stating that, if I can find it. ]]] While older computer systems are designed with specific devices for human interaction—for example computer screen, keyboard and mouse—modern computer systems often embed many of those devices into one—a single touchscreen. Going from that to a `single device for everything' is not a big step, especially when combined with cloud computing. This trend comes with a cost: Most operating systems were—and often still are—designed for a computer system with dedicated screen, keyboard and mouse. Plan 9 is not different, although it allows for various combinations of hardware due to its strong networked nature. Due to the increasing amount of touch devices—especially on the mobile market— and increasing hardware support¹ of Plan 9 it's important that we think about touch user interfaces. [[[ms .FS ¹ Ports of the Plan 9 distribution `9front' to mobile devices like the PinePhone are being worked on. .FE ]]] # Why do we need a Plan 9-specific user interface? When reading this far, the first thought might be: ``Let's just use what we have and put it on a touch device''. While this is the most obvious thought, it's also a naïve thought. Even big and expensive operating systems like Microsoft Windows tried that, and failed. A much more important point is that the best touch user interfaces are designed for touch from the ground up, most notably Apple's iOS and Google's Android. Both systems are widespread and their handling of touch interfaces is often seen as the `de facto' standard. This `de facto' standard doesn't fit the Plan 9 operating system too well though. Plan 9 has its own, very specific idea of important aspects of user interfaces. For example, it has its own mechanism for inter-process communication, it's own view of resources and has a unique user interface, which leads to a very distinct user experience. Let's assume that we try to achieve this same user experience using the commonly known standard of touch user interfaces. Many interactions probably wouldn't `feel' right. Sending some data to another program? Sure, on Plan 9 we'd probably use the plumber. On modern mobile operating systems we often find a system that's quite similar. But what if we want to copy and paste some text? Sure, just LMB-sweep, MMB-click, RMB-click to snarf, then LMB-click and RMB-click to paste… which is mouse driven, but feels natural to a Plan 9 user. Now try to achieve this `feel' with a pure touch screen interaction. This natural Plan 9 user experience is very hard to achieve using current standards. That's why we believe that we need a specific touch user interface for Plan 9 systems. # Challenges Since the scope of a paper is way too small, and the scope of designing and implementing user interfaces are way too big, this paper will focus on design challenges only. To do that properly we'll have to take a look at what Plan 9 users experience when interacting with the operating system. To gather more insight, a survey was done to ask users about their habits and how important various features of Plan 9 are². [Meyer] [[[ms .FS ² The survey received around 20 responses, so it can't be counted as fully representative. However, it gives some insight on how users use the system. .FE ]]] But before we do that, we'll quickly remind ourselves about general challenges of touch interfaces. [[[ms .\" refer to survey! ]]] ## Well-known touch user interface challenges Many challenges arise when designing touch user interfaces in general. Most of them are very well known today and big development houses like Apple and Google found good solutions to those problems. The first big challenge that comes to mind is a large variety of different devices. Big devices like tablets or multimedia screens as well as very small devices like smartphones or even smart watches provide touch hardware interfaces, which demands for a solution for varying screen sizes. If we compare the size of a smart watch screen with the size of a smartphone, we immediately see the big difference. While we can fit a few paragraphs of text on the smartphone and still have enough space to add a few buttons, it is impossible to do that on a smart watch. If we move over to a tablet device, we can often fit a whole DIN A4 page on it, plus a few buttons for interaction. Speaking of buttons, this reminds us of the next common challenge: The button size. With a standard mouse and keyboard computer setup we can often live with very small buttons for interaction. Most common touch screens have no mouse for interaction, but the hand of the user. Therefore we must consider the size of their fingers, since that's what they use to interact, so we basically have two options: (1) We provide a stylus for smaller buttons. This method is well established, but often has other implications. For example, the user usually only has one stylus, which can also be lost easily. Many people use a stylus or any other form of pen to interact with their computer devices, but usually just on (at least) tablet sized devices. Smaller devices like smartphones or smart watches usually aren't used with a stylus. (2) We make the buttons bigger. This is the most common method for handheld devices such as smartphones and smart watches. Due to familiarity, most tablet devices also come with bigger buttons (for example, compare the iPhone with the iPad). Even some laptops have some kind of touch screen mode with bigger buttons, like Windows 8. In addition to those challenges we also get more options when thinking about touch screen devices. Most notable, capacitive touch screens often allow multiple fingers to interact at the same time. This multitouch feature gives us many new possibilities to overcome the mentioned and also other challenges, but are also a challenge in itself: How would the user interface react to multitouch input? Most modern touch systems tried to master this challenge and they also established some `de facto' standard; most users learned to interact with that. It is almost common knowledge that you can zoom in and out of images using two fingers, for example. This paper should not discuss these and many more challenges and possible solutions. I believe that many people already did that with varying focus on specific topics. ## Three pillars of user interfaces on Plan 9 Plan 9 provides a few important aspects of user interfaces. Unlike its predecessor UNIX it tries to find a perfect mix of text interfaces, graphics as well as input devices like mice. This paper describes these three `pillars' in more detail. We'll also take a smaller look at the results from the survey. [Meyer] ### Text interface The text interface in this context means any type of text-based shell-like user interaction. In this regards, Plan 9 is very much like UNIX: It provides a text-based shell interpreter and lots of interaction with the system is supposed to be done using this shell. However, Plan 9 not only provides the shell itself, but also another graphical shell called `rio'. This `rectangle multiplexor' gives the user the option to open multiple shells inside windows, which provides some type of multi tasking for the user. In addition to that, rio provides extensions to this text-based shell experience. For example, the user is able to interact with the text inside the shell windows. Changing the output or previous commands is possible, as well as sending it to the prompt for execution. Furthermore, it is possible to access the text inside rio shell windows. This way, applications can extend the text shell even further. [[[ms .\" Using rio windows to handle graphical applications will be discussed in the next pillar. ]]] The survey shows that users consider the text interfaces as a very important part of Plan 9. The feature scored more than 4.5 out of 5 points. ### Graphics As mentioned before, rio is a graphical application that also allows to run other graphical applications inside its windows. It is worth mentioning that Plan 9 ships with both rio and a bigger set of graphical applications. Plan 9 also comes with a few different libraries for developing graphical applications, though some of them are more often used than others. The survey shows that the GUI is important for Plan 9 systems, however there are users who only use the text-based input methods. The feature scored 3.3 out of 5 points. ### Mouse interaction Standard computer systems usually come with a mouse and keyboard setup, which is often needed for interaction with graphical systems. Usage of the keyboard is often very simple if you forget about special keys and shortcuts. The mouse however often faces `philosophical input behavior'. While the `standard' behavior describes a single mouse button to behave as a simple click-pointer, mice often have more than one button and it's up to the system to decide how these extra buttons should be used. Plan 9 has a very unique style of using these extra buttons: Clicking with any button shows a different behavior depending on the context and the button used. While this is very common among different operating systems, modern operating systems mostly agreed on a single standard, which Plan 9 slightly deviates from, but that's not too different to discuss in more detail in this paper. What Plan 9 does completely different is mouse chording: By clicking multiple buttons at the same time the user can describe another input behavior the system uses to control other forms of interaction. While it first seems weird to do that, it quickly becomes a natural behavior. It is very important to mention that mouse chording is very consistent across the whole system. Using chording, the user can copy and paste text from text editors to browsers or to rio shell windows. Some applications extend this behavior even further. For example, in acme it is possible to execute commands using the middle mouse button. Mouse interaction on Plan 9 scored 2.9 out of 5 points in the survey. It is noticeable that some users clearly don't like to use the mouse or to chord. A few users pointed out that nowadays true three-button-mice are rare. ## Integrated system components ### Plumber - How plumber is important for Plan 9 UI - It should be natively integrated and feel natural to use it. ### Namespaces - How to visualize and manage namespaces on Plan 9, using touch UI. - Dynamic, per-process namespaces are an integral part of Plan 9. # References [[[ms .LP [Meyer] J. Meyer, ``Survey: Plan 9 and Touch User Interfaces'', 2023 .br ]]]