For GUI to Be Free for Non-Developers

 All Posts Tagged: Free GUI  

(Non-Developers AND Developers)

There is no great way to get UX right in a concise way. (It is possible to do better yes) Also very relevant is that really good UX requires too much specific attention, and then it gets locked in every time you think you have it just perfect. 

• Good UX is expensive and difficult in the short term and confining in the longterm.
• Good UX typically requires strange means of gathering user data
• After the fact, there're too few or too many biased deciders to go through for UX changes.
• improvements are not objective. Too many people that will be heartbroken, even if the UX wasn't well thought out in the first place. Misguided familiarity even with flaws. Results in group choice paralysis
• disconnected purposes of software influence what constitutes good design without examination

Thus, if you want to get a single, concise UX, you will be handicapping Linux.

UX for Linux does not only bare the typical problem of pleasing all people, all the time. It caries an additional challenge of there being more options of what to do on Linux, given its very many purposes and user types, and a desired propensity towards freedom and options. Thus, if you want to get a single, concise UX, you are effectively handicapping Linux.

The solution is for there to be at least one or two options (For a DE, and compatible Toolkit) that are about being more-or-less Windows replacements, but then to have a new advanced toolkit for a DE and application ecosystem that is built on the idea of applications that share a common method for making customizations to the UX, small and large. (Obviously still compatible with old application ecosystems.)

Such a UX toolkit is not GTK or QT. It needs to be thought out enough to be used by subsequent desktops that use GTK, QT, whatever. The toolkit is based on what the user can do at varying levels of skill. GUI | simple text syntax | semi-technical text syntax | development.

For Linux to be technically liberating, it has to be able to brake typical rules of UX. This has to mean making the UX be able to change focus on the features that the user can personalize themselves. The UX can lock and unlock with the right permissions. The configuration and customization can be transferred offline, or with files than can be stored on a server.

In an indirect way, making a UX that can be customized and locked will still allow creating simplistic UXs as a subset of its capabilities.

And that means always being able to allow users to add new options that can be found and then placed in the UX.

This is more complex than customizing Firefox with bookmarks and plugins, and it is easier than customizing Waybar, although it can get as complicated as you want to make it.

And that means developers have to be able to create those tools to be compatible with the UX. (this would sometimes be compiling a script that accommodates the right flexibility in a set of application environment variables like various kinds of disk references etc. in the case of the Gnome Disks application)

And that means creating a UX infrastructure that can handle custom options being selected from a larger group of options. (This is out of the hands of just a few cooperating developers.)

A future Linux UX must be a user-customizable GUI sandbox, with effectively infinite abilities afforded by compiled scripts, while having one or two dumb Windows alternatives. The model of demanding ergonomics out the gate in the simplest and most immediate form cannot fulfill Linux's capability and liberty. It's somewhat of a trap of trying to play the same game for the wrong reason.

Giving the application the ability to run compiled scripts as individual tools is not braking modularity. It is enhancing modularity, and single purpose items that plug into a larger application with a single purpose - to run these scripts, and provide some GUI representation of sufficient widgets like disk partitions or whatever the specific case is.

In the case of a Gnome Disks equivalent, the application would consist of a GUI representation of the disk partitions that can interact with scripts via environment variables. Writing tools the the application requires knowing the format of those variables, and then translating your script to operate on those variables. Use a preferred language, or use another language. Compile the script.

Success is highly contingent on having a process of elevating decent scripts to be uploaded and shared and curated as to make the application options very robust - sometimes duplicated, but in slightly different forms - as to effectively provide the right sets of options for individuals.

To place tools in the application, be able to unlock the GUI of the Disks application (with the right permissions) and place options in the UX of the Disks application to use the script where it makes sense to the user. Like placing bookmarks in the taskbar on your browser (but a little more involved).

This would require a low-to-semi-technical knowledgebase that could easily start out simple, and allow users to become more familiar with. It can also bring about exactly the change you are talking about - where an individual developer is not going through as much trouble to do a whole plugin per se. There is a script compilation environment pre-made, with the ability to venture outside it if desired.