ref: 915ce21128ac8cbfb97910810bd5a93ca2a31fb2
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 In addition to the obvious user interface components we discussed earlier, there are other system components that are important for a Plan 9 system. Although they can't really be counted as `user interfaces', they still have an enormous impact on the user experience. These components are usually invisible, but users tend to interact with them using dedicated user interfaces, like the shell or menus. ### Plumber The plumber is Plan 9's integrated component for inter-process communication. It is possible to do various things using the plumber, all configurable using a simple configuration file. The general functionality of the plumber can also be found in other operating systems, also mobile systems. Android, for example, has the concept of ``intents'', which is very similar in a few aspects [AndroidIntents]. However, the biggest difference is that the plumber can be configured in much more detail by the user. The plumber is also meant to be used within applications that don't know what can actually be plumbed. For example, hyperlink-like texts (URLs) can often only be used in applications that understand the general structure of the URL. On Plan 9, the application doesn't need to know the structure of the URL. Even the plumber itself doesn't need to know about this structure, but the configuration tells the plumber what to do with it. There's also no limitation to what can be plumbed. From simple text strings, to binary data like images, to full documents or other plumb messages: Nearly everything is `plumbable'. The survey shows that some users don't use it much directly, others don't know if it's useful in other applications than what's already using it. One user admitted that the plumber is ``integral'' to their workflow. In total, the plumber scored 3.7 out of 5 points in the survey. [[[ms .\" - How plumber is important for Plan 9 UI .\" - It should be natively integrated and feel natural to use it. ]]] ### Namespaces For many people, namespaces in Plan 9 are the reason to use Plan 9 instead of other systems. While it is an original Plan 9 feature, Linux nowadays has a way to at least build a dynamic namespace, however, this is still far away from namespaces in Plan 9. Although namespaces are a very important feature of Plan 9, a few users pointed out that it's mostly useful on a server. This detail is important to know, because most touch screen devices are also end user devices, not servers. However, namespaces are one of the core features of Plan 9, and it's very important to think about them. On touch screen devices, developers will have to decide how to integrate them. Most of the time, namespaces are set up before starting an application. This means that a touch user interface needs to provide a way to adjust namespaces in a shell³ before starting the application. [[[ms .FS ³ ``Shell'' in this context does not necessarily refer to text based shells. .FE ]]] In the survey, namespaces scored more than 4.1 points out of 5. [[[ms .\" - How to visualize and manage namespaces on Plan 9, using touch UI. .\" - Dynamic, per-process namespaces are an integral part of Plan 9. ]]] ## Other features worth mentioning During the survey, users added a few other important features that should be mentioned in the context of this paper. This also means that they are not covered by the survey. Note that the users mentioned even more aspects, but those were not related to user interface aspects, so they're not covered in this paper. Please refer to [Meyer] to learn more about them. ### Filesystems Plan 9 has a concept of resource abstraction using filesystems. Those filesystems can be an abstraction of basically anything, it's not restricted to files on a disk; and all interaction with files in those filesystems happens using the same protocol without any restrictions. Unlike other systems, there's no concept of ``virtual'' files. This is also an invitation to developers to provide interfaces to their software using filesystems. On Plan 9, this is done with many applications and system components. From low-level system features and drivers (e. g. /dev) to high-level components (e. g. webfs) and applications (e. g. acme), the general feature allows for much flexibility and simple access to how the software works. Everything else about this features is already handled in the section about namespaces. ### Factotum While most filesystems are used by other applications, there's one big exception. Factotum is the authentication manager of Plan 9. Most modern operating systems have password managers, Plan 9's factotum goes beyond that by providing way more security features than just a plain password store. However, going into more details is not needed, there are papers already, as well as the man pages [Security]. Many applications in Plan 9 use factotum, and it make sense to continue using it on devices with touch screens also. However, this means that some things must change. Most importantly, users need a way to manage their keys. For adding keys there is a graphical way already: Fgui. However, deletion and editing is not easily possible using end user tools, besides using the text-based shell and an editor. It is also important to rethink the source of the keys. Secstore is simple enough to be used, however managing the keys is somewhat different on touch devices. Using an editor is simple enough, but also not very convenient on a smaller touch device such as a smartphone. # Future work In this paper we took a deeper look into various challenges that encounter when designing user interfaces for touch devices while keeping in mind the unique nature of Plan 9. While it is possible to find very different solutions for those challenges, there probably can't be a single one. In the software world, there's often more than one way to do it, and that's a good thing. Developers should get into discussions to find innovative solutions and build incredible software. While we still have a lack of general support of touch screen devices, I really hope that this issue will be solved soon enough and we can see Plan 9 on touch devices, with a wave of new user-friendly applications. # References [[[ms .LP [Meyer] J. Meyer, ``Survey: Plan 9 and Touch User Interfaces'', 2023. .br [AndroidIntents] Android Developers, ``Intents and intent filters'', https://developer.android.com/guide/components/intent-filters, 2024. .br [Security] R. Cox, E. Grosse, R. Pike, D. Presotto, S. Quinlan, ``Security in Plan 9'', 2002. .br ]]]