Snappy Widgets

Today, every time a developer develops an app, it is them who decide how the app should look and feel, not you, the user. However, if you look around, most apps pretty much share the same kind of widgets:

• all chat apps have conversations list, the input field for text, voice, emojis, files into a chosen conversation, and the view of the conversation itself.
• all CAD design apps have the object 3D views, tool selectors, and the object/operation trees.
• all the mail apps have folders and message title lists.

The examples can continue, but the point is, that these widgets repeat across different applications.

The creators of the first operating systems graphical user interface, such as Windows, came up with the paradigm, where developers create a window, and a world within that "window". They had not envisaged that the user interface lowest common denominator should be a "widget", and the user would compose widgets into what they need. So, let's re-imagine a life of a user with "Widgets OS" rather than "Windows OS".

• Upon starting the snappy widgets environment, a user could instantiate new empty docking nodes to which to dock new components, and start placing widgets into them from a library of possible widgets.
• Each node with an arrangement of widgets could be saved as an "app".
• Having such an arrangement, a user could configure the widgets, by looking up APIs available as backends to them, as the sources for these widgets would be configurable, based on the data protocol defined by each widget.
  • For example, if it is a chat entry field widget, perhaps there are many apps with a public API that snaps to this widget.
  • A user would choose, which backends to make available for the specific widget within the docking node of choice.
    • For example, to emulate Trillian chat integrator, a user could choose all supported backend apps for chat entry field, which should auto-toggle based on the active chat window.

Having such a widgets system, front-end developers would not have to repeat their work: new widgets would need to be created only if there is no needed widget in existence. The development and publishing of each widget would have to be a bit like specifying a protocol of data, because the sub-types that the widget supports would be specific. Popular widgets would have many backends providers, and someone who wants to create a new app would not have to create front-end, because the front-end would be composed by user, not the developer.

What's more, we can imagine, that under such system, widgets could be dragged-and-dropped from one docking node to another. It would feel like dragging-and-dropping widgets from one app window to another app window.

The greatest benefit would probably be in the ability to quickly create new apps just by writing appropriate APIs, and without any front-end coding at all, meaning, more developer work would be available for systems engineering and data management, rather than front-end work.

Finally, when it comes to real implementation of this idea, these days there are many widget libraries written for developers (only in web development: Material, Bootstrap, Ant Design, BalmUI, Buefy, Chakra UI, Element, Framevuerk, Oruga, Tachyons, Tailwind CSS, Windi CSS, Vant, Vuesax, etc.), so lots of people are working on them. It would be quite straightforward to take some of the good ones, and make them snappy like legos to a docking point, via introducing a specialized browser extension, an Electron application, and an Android/iOS application, that packages such app-making environment.

However, the web-technologies based UIs tend to be slow, and the non-native apps in general seem to be slower, the next step could be to develop a completely native implementations by desktop environment developers, or perhaps integrated ("Write once. Deploy everywhere.") framework creators, like beeware.org. Let's see.

Inspired by Structured Internet Client.