Beagle
What is this?
One of the biggest problems with user interfaces for desktops, tablets, and phones is that they are inconsistently designed, which is not great for user experience. Beagle is an attempt to rectify the problem, taking inspiration from some of the best existing interfaces and remixing them into something that just works.
Darwin is the free, open source operating system upon which the various Apple systems are based. Unlike the various distributions of Linux and Unix which are free and open source, Darwin lacks a solid user interface that it can call its own. Most importantly, however, is that the name Beagle makes no sense unless coupled with Darwin.
Beagle
Features
Beagle has both a frontend, the part of the interface the user can see, and a backend, the part of the interface that makes everything work.
Frontend
Beagle has some notable features and refinements that make it stand out from other graphical user interfaces:
- Sidebars: Every app has a sidebar on the left which contains a search field and tabs below it. Tabs can be both static — controlled by the app — and dynamic — controlled by the user. For apps that require it, there would be an additional sidebar on the right that can contain tools.
- Titlebars: Every app has a titlebar at the top which contains the name of the current view and can optionally include share and settings buttons for the view. The titlebar sits above a gradient to ensure readability when content appears below it. Gradients are not visible in the mockups.
- No scrollbars: Apps do not use scrollbars to determine if a sidebar or view can be scrolled. Instead, gradients are used to obscure content which provide a visual indication that it can be scrolled. Gradients are not visible in the mockups.
- Responsive interface: All apps and shell components extend to use the available screen space, showing more content. When on a touchscreen device, particularly phones, the sidebars retract out of view. Swiping from the edge of the screen extends the sidebar into view.
- Customisability: While all apps must adhere to the defined layout, there is some level of customisability. All colours and fonts would be changeable by the user, as well as background imagery, icons, and other app-specific things like map tiles and weather animations.
- Stores: Most apps would have a store where users can buy and sell content specific to the app. For information and entertainment apps, the content would be for consumption. For productivity apps, the content would be templates. For other apps, the content would be to customise the app, such as map tiles and weather animations.
Backend
Beagle has been designed with a decentralised and distributed network in mind to avoid single points of failure. Some technologies that would aid in accomplishing this goal include:
- Peer-to-peer data storage: Rather than using cloud services, which is a single-point of failure, all data would be stored locally and copies of that data would be stored remotely with something like IPFS. As this is a peer-to-peer storage solution, it would be more difficult for bad actors to compromise. All data would need to be encrypted and broken up into blocks, ensuring no single person would have the entire file on their system. This form of data storage would be optional, as local storage would be the default, however local only would limit what users could access in the stores as they would not be able to generate tokens to purchase things.
- Cryptocurrency: To incentivise users to enable peer-to-peer data storage, a cryptocurrency would be created to generate tokens to pay users who permit other Beagle users to use their local storage devices to store data blocks. This cryptocurrency would be exclusive to Beagle and not exchangeable with other currencies, ensuring it cannot be manipulated externally. It would be used for the purchase of content on any of the stores in apps, as well as the store for third-party apps. The idea behind this cryptocurrency is to build a parallel economy that is not controlled by central banks or government policy, both of which are single points of failure.
- Blockchain: All user accounts would be on a blockchain. Doing this avoids using centralised servers, a single point of failure. Users would be able add devices to their account. Peer-to-peer data storage, cryptocurrency tokens, and purchases would also be linked to a user account. When a user makes a purchase, this would unlock the restriction on having all blocks of content or app on the same device, enabling its download. As it is on the blockchain, users cannot lose access to their purchase if the original seller withdraws the content or app from sale. This also means that a second-hand market can exist where users would be able to sell content or apps they have purchased to other users, at which point they would lose access to the content or app once the exchange has completed.