This is the first of a series of articles providing a glimpse into the implementation of our OOProtocol in preparation of the release ofOOTech's technical paper at a future date. This article focuses on the User Interface (UI) and the User Experience(UX) side of the protocol.
The Optimized Ownership Protocol (OOProtocol) defines the software and hardware architecture as well as the UI/UX implementations that are required to build scalable features with data ownership, privacy and security at the core. I've been working on democratizing data ownership & privacy for a few years now and this is some of what I've learned.
When you think of platform scalability, most will think of the ability to grow a platform infrastructure based on user demand. For example the entire infrastructure has to be able to scale seamlessly to handle workload from millions to billion of users. There is another side to scalability and that is feature scalability. How do you scale when the demand for features on your platform grows.
When I first set out to work on Optimizing Data Ownership & Privacy, I quickly learned that people weren't looking for privacy app, what they wanted was to be able to enjoy life enriching experience online without having to sacrifice data ownership, privacy and security. I learned that what I needed to build wasn't an app that helps users or companies manage data ownership & privacy but to build an ecosystem of apps that solves specific real world problems while ensuring data ownership, privacy & security by design. I learned that feature scalability needed to be a crucial part of the OOProtocol.
What happens when users demand more and more features? At some point any app that keeps adding features will become bloated and take too long to download. How do you scale features and still deliver an amazing experience?
Platform classification simply refers to the data objects that encapsulate the different parts of the platform and how they relate to each other. Everything revolves around a Feature that represent a goal the user wants to accomplish on the platform such as the ability to complete the sign-in process or to the ability to record an experience on OOLoop. Features are directly related to a specific free or paid Subscription on the platform. Features can be consumed on a specific set of Screens. A Screen is simply the user interface you see on the app at any given time. Each Screen is part of a specific Mini-App Module contained in a specific Min-App. The concept of a Mini-App is similar to the normal apps you download today that group a specific set of related features (ie. a chat app, media sharing app, productivity app). On OOLoop for example there is a Mini-App that groups together features related to Loopers, another Mini-App that groups together features that Builders want, another Mini-App for authentication, chat and so on. Mini-Apps are exactly what the names implies, they are small apps that groups together related modules, screens, features and subscriptions. At the top of the graph is the Brand that offers a selection of Mini-Apps that are grouped by Section in order to solve a specific problem at a local and global scale. OOLoop is OOTech's first brand and aims to provide data driven, privacy focused, unbiased insights to validate ideas and improve experiences.
The OOProtocol defines a unique approach at navigating each OOTech brand and takes full advantages of new technologies to provide a custom navigation based on the environment. On the smallest screen, OOLoop on watchOS focuses on quick interactions and displays the platform's features at launch. OOLoop on iOS uses a TabBar at the bottom to navigate the platform's sections but uses a SideBar on iPadOS's larger screen.
Adaptive State Restoration
I've talked about multi-window support & state restoration before as a way to improve user experience. Adaptive State Restoration takes that concept further. At the switch of a setting preference, users can enable on-device machine learning algorithms to understand how you use and navigate the platform to determine the Mini-Apps and Features you most likely need when you launch the app.
A platform can't improve if there is no way of capturing feedback to understand the features users love and hate. I'll go further and say that a feature shouldn't go into production until there is a demand or a need for it expressed by the people who currently use the platform. Feature Feedback helps OOTech focus our limited engineering resources building the features the majority of our users want. OOLoop implements another requirement of the OOProtocol by providing the progress and development stage of each feature ranging from considering, building or launched. This provides transparency into our release pipeline and enables users to be involved in the process of deciding which features OOTech should work on.