Saturn 2025 July (Galileo)
I've been exploring yet another variation on my "Saturn" concept, which is my lofty spreadsheets-of-the-future project. In this version, I've been focused on an outside-inwards approach: I started with a design mock and now am in the progress of building the UI and UX of read only documents.
TL;DR: here's where you can find this variation hosted here:
- Saturn 2025 July (Galileo) - pinned to the latest version at the time of writing
- Saturn 2025 July (Galileo) - most up to date
Because I've often found myself losing focus in favor of other projects or due to unrelated life events, I'm trying to make quick and targeted progress. As mentioned, I'm focusing on an outside-inwards approach. That is, I'm prioritizing getting something visible and viewable instead of letting myself get lost in the weeds of programming language theory or other facets of Saturn-as-a-whole that are significantly more complex.
At the moment, I've built a solid foundation of what features would look like, while only implementing a handful of actually interactable elements.
Organization
The app is organized so the user would open a specific Notebook, which itself has a name and a deck of Cards. One analogy would be to consider these cards in a notebook as being similar to files on a computer's storage drive: they are able to be used, but aren't at the moment. This deck is viewable in the left sidebar of the app (though it is not at the time of writing).
There is one Desk by default, but more can be created. Each Desk is a particular way of laying out a set of cards. A given card can be on more than one Desk at a time. Cards on desks are not instances of cards, they are instead a window of a card.
On each desk, there is a vertically scrollable list of Shelves. Each Shelf has a name and is itself a horizontally scrollable list of Stacks. Each Stack is a non-scrollable, growing-vertical list of Cards. I'm exploring this particular UX pattern as a way of balancing the completely free-form multi-window layouts of typical window managers (floating or tiled) with the affordances that can be offered by more the more strict layouts of typical apps.
Take a look at the annotated screenshot below for a visual of where the list of desks and the list of cards available in the deck will be built (gray), as well as a reference of the Desk/Shelf/Stack/Card hierarchy.
Cards
All cards have a name and some kind of content. When placed on a desk, cards look reminiscent of windows – this provides some UX affordances to remind the user that they can interact with cards in a similar way as a more familiar floating window manager:
- cards can be moved by dragging, much like windows on a desktop UI (though these should slot into stacks within shelves)
- cards can be removed from the desk with a red "x" button in the corner, similar to closing a window
- cards can be folded on the desk, which is cognitively close to minimizing though it is a bit different
- cards can be focused, akin to maximizing or making a window full screen
In the current version, the card controls (close, fold, focus) are grayscale until hovered so the color does not attract the user's attention away from the content. At the time of writing, only the fold control is interactable: you can see an already-folded card in the first stack of the Documents shelf. The content of the card is hidden so only the titlebar of the card can be seen.
Cards come in a few varieties (and more can be added to expand the kinds of work that Saturn can achieve). Currently, I've implemented the design and view of 3 kinds: Notes, Datatables, and Code. 3 additional kinds I want to include are Summaries, Forms, and Graphs.
Notes have a markdown document as their content and when opened on a Desk, they are rendered to HTML.
Datatables are conceptually close to SQL tables – each column has a name and a type, and there are any number of rows which MUST fit the types of the columns.
Code cards provide a playground-like interface for a declarative code language. I'm intentionally deferring implementation of this programming language until far later, because I know I'll fall down a rabbit hole and won't build the rest of the application. On the left of the Code card is the source, which will be editable. On the right is the resulting value of a given expression. Each code card's variables are added to a global scope and are able to be referenced from other cards. Similarly, code can reference data from datatables.
Summaries will require a single expression in the Saturn language, then the value is displayed in large text. I expect this to be useful as a "final answer" for calculations.
Forms will allow the user to provide inputs which each have a name and type, which can be referenced in code. These will feel very close to a transposed datatable with a single row.
Graphs will give a way to visualize data in a line graph, bar chart, pie chart, etc. These can use information from datatables or from code.
Final Thoughts
Thanks for taking the time to check this out! Play around with the linked web app and let me know if you have any suggestions or specific questions I can answer in my next post on the topic. I'm excited to finally see a tangible (though still fairly static) implementation of my years-old Saturn concept – I'm planning to ride this excitement forward to continue building out this implementation to a usable state. Stay tuned!