Skip to content

UI for a local-first operating system #1212

@joepio

Description

@joepio

We're in a consortium called ELFA: Encrypted Local Fist Apps. We're working on a unified UI for various apps. How would a modern UI look for a piece of software that contains most of your personal data, on your own device?

  • Where you run apps and open files like pictures, table, documents, pictures, todo lists, social feeds...
  • Where you manage your personal data, see what's stored where
  • Where you manage who has access to your data
  • Where you manage the apps and what the apps have access to
  • Where you discover new apps that you can install
  • That works inside your browser but also as a native app
  • That integrates with other apps too, as a storage provider

I think we can draw a lot of inspiration and lessons from existing OS's and other apps. Some thoughts:

  • OSs make apps things that run inside something else. The OS abstracts a lot of complexity away, so that the app can focus on providing a good user experience. It gets its own piece of IO, maybe some other hardware resources, and it can render whatever it wants in the screen real estate that the user gives it.
  • Desktop OSs rely heavily on managing windows where apps can do what they want, optionally using a desktop-provided set of UI components. Then there is some level of "chrome" like a system bar at the top of the screen, maybe some gestures to open notifications. And then there are system-level apps, which are not that different from other apps (settings app, file manager). Desktop OSs emphasize files more than apps, although that is changing/
  • Mobile OSs do some things differently. They tend to constrain more how apps are listed on the home screen, and they have stricter rules about getting access to data and OS features. They also de-emphasize window management, and typically constrain which apps can and cannot be installed. They also de-emphasize files and file management.
  • Virtual OSs (citrix) feel just like a regular desktop OS, but they are actually not. They just show that it is actually possible to run something inside something else that feels and behaves like a complete OS.
  • Browsers typically show some chrome (either in the top bar or in the sidebar) to let users switch between sites (apps). They manage and constrain space usage, compute usage, network usage...
  • SAAS tools like Notion, Airtable and Figma have a lot of plugins that you can add. In figma, for example, plugins are loaded in iframes for security reasons, but then they can basically render ANY UI that they want and make any changes to the document you load them in.

My intuition on how it should work:

  • If the parent app (or OS or shell or however we should call it) is used: A sidebar (notion / arc style) browser chrome, not dissimilar to how AtomicServer has been designed. It works on mobile, it works on desktop, it can easily be hidden. It works for hierarchical data as well as flat structures. I think this is just a great place to start.
  • If an app is "full screen" or has its own runtime (e.g. launched from the OS itself, or in a separate process or browser tab) then we should have som re-usable UI components that deal with some complexity that app developers shouldn’t have to deal with:
    • Sharing things
    • Switchting user profiles
    • History / versionin
    • Data view / power user tools
    • Network / sync / storage settings

Some big questions:

  • To what extent are we going for app-first or data-first navigation? AtomicServer / AtomicBrowser is quite data-first, where the view of the selected resource switches depending on the class type of the selected resource. But you can also imagine a user may just want to see their photos even if these are scattered across different folders.
  • To what extent should we give freedom in how apps are designed? Constraining too much can lead to a lack of innovation and sub-optimal app design. But too much freedom can make apps inconsistent, confusing and chaotic.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions