Snappy Widgets

+3  

Widgets that snap into apps.

YAML 想法

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.



(別通知) (可選) 請,登錄

insert into widgets (type, name) values ("dropdown menu", "countries") I'd like to be able to define what widgets are available separately from their positioning on the screen. Positioning widgets is harder than deciding what widgets are available. We should separate these functions to make snappy widgets a reality.



    : Mindey
    :  -- 
    :  -- 
    

chronological,

[按時間順序],我同意,我們需要像一堆小部件或一個庫,並且這些小部件必須在全球範圍內可用,因此它就像是一個瀏覽器插件,使這些小部件得以存在,並且,我想可以通過類似的方式進行訪問在新的空白瀏覽器選項卡中右鍵單擊鼠標可從https://vueuikit.com之類的庫中刪除新的小部件。

實際上,死的小部件捕捉已經在適用於設計人員的應用程序原型設計工具中實現,例如proto.io,uxpin.com等。

但是,這些不是實時的窗口小部件,也不適合最終用戶使用:

-過於精細(最終用戶通常沒有時間從頭開始構建菜單,或者從頭開始構建聊天窗口等) -不是協議定義的(複雜的窗口小部件通常定義了複合數據類型,甚至是交互協議本身,例如,像this這樣的glTF小部件定義了可以提供給它的數據類型同樣,聊天窗口小部件可能具有自己的輸入驗證器和輸出驗證器,但是,諸如聊天窗口之類的那些大而複雜的窗口小部件會在各種應用程序之間重複-電報,whatsapp,線路,whatsapp等- -所有用戶都有非常相似的聊天窗口,並創建了一個協議定義的聊天窗口小部件,開發人員會考慮使用聊天應用來顯示事物的所有可能需求,以便拖放該小部件的非程序員用戶可以擁有很多兼容的數據源,而無需進行任何編程。

[chronological], I agree, we need like a pallete of widgets, or a library, and these widgets must be available globally, so it could be like a browser plugin that brings those widgets into existence, and, I suppose accessible via something like right-clicking of mouse in a new empty browser tab to drop a new widget from a library like https://vueuikit.com.

In fact, dead widget snapping is already realized within app prototyping tools for designers, like proto.io, uxpin.com, etc.

However, those are not live widgets, and not for end users:

  • too granular (end users generally won't have time to build a menu from scratch, or a chat window from scratch, etc.)
  • not protocol-defining (a complex widget usually defines a composite data type or even interaction protocol itself, for example, a glTF widget like this defines the data type that can be provided to it for it to work properly. Similarly, a chat widget may have its own input validator, and an output validator. However, those big and complex widgets like chat window, repeats across apps -- telegram, whatsapp, line, whatsapp, etc. -- all have very similar chat windows, and creating a protocol-defining chat window widget, the developers would think about all possible needs of chat apps to display things, so that the non-programmer user who drags and drops this widget can have lots of compatible data sources without having to program anything.

Visual Basic在此方面處於業界領先地位,並且功能非常強大。雖然我從未學過如何編程大多數小部件。只是桌子。

Visual Basic was ahead of the industry on this account and was very powerful. I never learned how to program most widgets though. Just tables.


// Visual Basic [...]

這是給程序員的,而不是給最終用戶的。這個想法是關於面向最終用戶的工具,淘汰了應用程序用戶界面,因此將來的應用程序不需要自己的用戶界面。

// Visual Basic [...]

It was for programmers, not for end users. What this idea is about, is a tool for end users, obsoleting app UIs, so in the future apps don't need their own UIs.


讓我們在 oo 上實現這個

Let's implement this on oo



    :  -- 
    : Mindey
    :  -- 
    

Ruta,

在我的附加 GUI 概念中,我將 GUI 視爲數據流系統。

在電子郵件客戶端中,您有一個文件夾列表。單擊文件夾會將該文件夾的電子郵件發送到電子郵件列表。單擊列表中的電子郵件,該電子郵件將進入電子郵件預覽。

也許小部件可以通過彼此之間的關係以及它們在彼此之間流動的數據來描述。

In my additive GUIs concept I treat the GUI as a data flow system.

In an email client you have a list of folders. Clicking a folder flows emails of that folder to a email list. Clicking an email in the list flows the email into an email preview.

Perhaps widgets can be described by the relationships towards eachother and the data they flow between one another.


chronological,

語言