This would open up the underlying data model, and show people the power and simplicity of our data model. Our product feels more like a database that is purist, and utilitarian. Just like a file explorer.
Particles that are of container type (e.g. folder, stream, calendar, kanban) all have their own lenses by which they render children particles. They are, in effect, applications within themselves and read / write data for its primary purpose.
Explore in Balsamiq
Think about statuses and completion of a stream, or what "done" looks like for other containers like folder
Implement a path resolver and pattern for container type particles to be rendered
Show path like a file explorer in the view layer
Consider visibility of particles data and query patterns
This would open up the underlying data model, and show people the power and simplicity of our data model. Our product feels more like a database that is purist, and utilitarian. Just like a file explorer.
Particles that are of container type (e.g. folder, stream, calendar, kanban) all have their own lenses by which they render children particles. They are, in effect, applications within themselves and read / write data for its primary purpose.
- [x] Explore in Balsamiq
- [x] Think about statuses and completion of a stream, or what "done" looks like for other containers like folder
- [x] Implement a path resolver and pattern for container type particles to be rendered
- [x] Show path like a file explorer in the view layer
- [x] Consider visibility of particles data and query patterns
This approach is intriguing, flexible, and simple.
<img width="657" height="742" alt="Image" src="https://github.com/user-attachments/assets/da9def71-98cd-42c8-bdcd-04c644dd017e" />
This approach is intriguing, flexible, and simple.
A day later, after playing around with this structure, it feels as though applications are not meant to expose the "database". This is because as the application becomes more complex its job is to hide the complexity of the data, and display it in an object graph. Some apps like Linear show the inner workings of the data graph by exposing things like issue id, but still, they visualize the data in 100 different ways for different views.
While the path of the current particle is very helpful (especially when incorporating working memory, quests, paper, and file storage), this should be an internal concern. The application should focus on immersion instead of showing breadcrumbs everywhere.
A day later, after playing around with this structure, it feels as though applications are not meant to expose the "database". This is because as the application becomes more complex its job is to hide the complexity of the data, and display it in an object graph. Some apps like Linear show the inner workings of the data graph by exposing things like issue id, but still, they visualize the data in 100 different ways for different views.
While the path of the current particle is very helpful (especially when incorporating working memory, quests, paper, and file storage), this should be an internal concern. The application should focus on immersion instead of showing breadcrumbs everywhere.
<img width="605" height="610" alt="Image" src="https://github.com/user-attachments/assets/9652e532-2cde-4501-b1a4-da357caab461" />
<img width="605" height="610" alt="Image" src="https://github.com/user-attachments/assets/cf4e6eea-c560-460f-a1df-25645de04e72" />
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This would open up the underlying data model, and show people the power and simplicity of our data model. Our product feels more like a database that is purist, and utilitarian. Just like a file explorer.
Particles that are of container type (e.g. folder, stream, calendar, kanban) all have their own lenses by which they render children particles. They are, in effect, applications within themselves and read / write data for its primary purpose.
This approach is intriguing, flexible, and simple.
A day later, after playing around with this structure, it feels as though applications are not meant to expose the "database". This is because as the application becomes more complex its job is to hide the complexity of the data, and display it in an object graph. Some apps like Linear show the inner workings of the data graph by exposing things like issue id, but still, they visualize the data in 100 different ways for different views.
While the path of the current particle is very helpful (especially when incorporating working memory, quests, paper, and file storage), this should be an internal concern. The application should focus on immersion instead of showing breadcrumbs everywhere.