3 ms·

I think GUI has evolved too far, what I want is devolution, not back to what came before, but back to other basics. We're in a terrible state, some odd and ugl

by dusted 4y ago

I think GUI has evolved too far, what I want is devolution, not back to what came before, but back to other basics. We're in a terrible state, some odd and ugly place between native and online, where even native apps are picking the worst from online and online is denied access from the best of native. I want an operating system GUI that dictates the available widgets to the program, and hands me control of their presentation, I don't want applications, online nor native to be able to dictate their own look, only for them to present their available functionality to the OS, and have the OS compose the screens for me, probably guided by my predefined preferences, sort of how HTML could have been if CSS hadn't ruined the day, sort of how native winforms programs used to be done. A concrete example is things that can save a file, I don't want the program to dictate the gui for this, I want it to keep the OS updated "I have these documents open which have been changed since last save" or "There are these things which can be printed", and have the OS dictate GUI for activating that functionality.. It used to LOOK that way, for a lot of things, you'd go to the file menubar, and there you would open/save/print your file, this was easy to learn and very consistent.. Currently, the most consistent interface experience on my computer is bash in xterm, in elinks, websites look pretty consistent, if they're well designed. But if I open firefox, chrome, gimp and kate, nothing looks or feels the same.. Then I open blender and a fifth kind of interface appears. No thanks. So I sort of agree with you that it'd be nice if we did away with the window metaphor to some degree.. But I was also no fan of the way Mac had the "god bar" at top (which I believe Ubuntu did too) terrible idea.. For now, the least crappy desktop experience for me is i3, but it does not change anything fundamental, it's still program windows, free to do whatever they want. But, for some things, the most futuristic version of the environment is the one that does not need a screen.. The tasks that are silently done for you without needing you to transfer any significant amount of information between you and the machine, or being able to do so on another level than a screen (brain machine interfaces and whatnot)

Y-bar 4y ago
I want to generally echo this sentiment, for a slightly different reason. I think the "dynamic-ism" of many interfaces has gone too far, therefore losing the predicability. Some interfaces try to guess what I am supposed to do next and it is correct maybe 60% of the cases. But even when it is correct it actually slows me down because I am constantly second-guessing the interface and double-checking that what I am about to press is the one I actually wanted. I wish I could rely much more on muscle memory and that things re-open where I left them. Like a window from a folder _always_ opening exactly where it was when I closed it previously. Or the homekit buttons on my home iOS pull-down screen not rearranging themselves randomly. Edit: Another irritating example of this "trying to anticipate but keeps hampering" behaviour is the Outlook mobile app. When moving an email into a folder it will suggest three recently used folders and after a while re-arrange them after 3-4-5-something mails have been moved in a row.
- dusted 4y ago
  I absolutely agree- I want there to be places for things, a fairly rigid system so I can depend on things being in their place, not having to constantly "try to understand what's happening now"
dusted 4y ago
Imagine if programs were more like plugins to the operating system, they'd register the stuff they could do, and the stuff they need to be done, and ultimately let the OS and user chose.. it could be that my text editor registers that it can edit text of ascii and utf-8 encoding.. it might register that it has plaintext files of that encoding available for printing, saving and viewing.. My browser can register that it can also display files of those encodings, and so I could effortlessly open a "viewer" in context of my text-editor, have it be my browser, and then when I edit the text-file, it is automatically shared (maybe even accessing same memory by pointer if I'm living dangerously) with the browser so I get live preview of my html. The preview functionality in this case is not something that's explicitely supported by the text-editor, nor the browser.. It's just that since my OS already knows that the editor provides a source of text, and that the browser can view a source of text, then I can chose to open a browser perspective into the editor-source.. It might be that the operating system provides a "save file to disk" source, that I can then use to save the file from any program that provides a source of data.. It'd work the same way, instead of opening a browser as a perspective into my editor-text, I'd open a file destination into it, or I could open a LZ77 compression destination into it, which then opens a file destination, and my file is automatically compressed and saved, no program needs anything but tell the os what it can read and write..
- majewsky 4y ago
  To a certain extent, you're describing the KParts framework from KDE 3/4 times (I don't know if it still exists today). Many people remember Konqueror as a file manager and web browser, but it was actually a generic URL navigator that would load the right KParts component for whatever thing was being displayed. For an HTML file, the web browser component. For a directory, the file browser component. For a video, the media player component. When I was developing Palapeli (a puzzle game that ships as part of KDE Games), I did a KParts version of it for fun in a few lines of code. That made it so that if you had a puzzle file stored in a folder, you could navigate to it in Konqueror and the game view would come up inside of Konqueror. Back in the day, I dreamed of a fully document-oriented computing experience. Sadly the world has settled on the service-oriented experience of today, largely controlled by a small number of gigantic fiefdoms.

by dusted 4y ago

Y-bar 4y ago

I want to generally echo this sentiment, for a slightly different reason. I think the "dynamic-ism" of many interfaces has gone too far, therefore losing the predicability. Some interfaces try to guess what I am supposed to do next and it is correct maybe 60% of the cases. But even when it is correct it actually slows me down because I am constantly second-guessing the interface and double-checking that what I am about to press is the one I actually wanted. I wish I could rely much more on muscle memory and that things re-open where I left them. Like a window from a folder _always_ opening exactly where it was when I closed it previously. Or the homekit buttons on my home iOS pull-down screen not rearranging themselves randomly. Edit: Another irritating example of this "trying to anticipate but keeps hampering" behaviour is the Outlook mobile app. When moving an email into a folder it will suggest three recently used folders and after a while re-arrange them after 3-4-5-something mails have been moved in a row.

dusted 4y ago
I absolutely agree- I want there to be places for things, a fairly rigid system so I can depend on things being in their place, not having to constantly "try to understand what's happening now"

dusted 4y ago

Imagine if programs were more like plugins to the operating system, they'd register the stuff they could do, and the stuff they need to be done, and ultimately let the OS and user chose.. it could be that my text editor registers that it can edit text of ascii and utf-8 encoding.. it might register that it has plaintext files of that encoding available for printing, saving and viewing.. My browser can register that it can also display files of those encodings, and so I could effortlessly open a "viewer" in context of my text-editor, have it be my browser, and then when I edit the text-file, it is automatically shared (maybe even accessing same memory by pointer if I'm living dangerously) with the browser so I get live preview of my html. The preview functionality in this case is not something that's explicitely supported by the text-editor, nor the browser.. It's just that since my OS already knows that the editor provides a source of text, and that the browser can view a source of text, then I can chose to open a browser perspective into the editor-source.. It might be that the operating system provides a "save file to disk" source, that I can then use to save the file from any program that provides a source of data.. It'd work the same way, instead of opening a browser as a perspective into my editor-text, I'd open a file destination into it, or I could open a LZ77 compression destination into it, which then opens a file destination, and my file is automatically compressed and saved, no program needs anything but tell the os what it can read and write..

majewsky 4y ago
To a certain extent, you're describing the KParts framework from KDE 3/4 times (I don't know if it still exists today). Many people remember Konqueror as a file manager and web browser, but it was actually a generic URL navigator that would load the right KParts component for whatever thing was being displayed. For an HTML file, the web browser component. For a directory, the file browser component. For a video, the media player component. When I was developing Palapeli (a puzzle game that ships as part of KDE Games), I did a KParts version of it for fun in a few lines of code. That made it so that if you had a puzzle file stored in a folder, you could navigate to it in Konqueror and the game view would come up inside of Konqueror. Back in the day, I dreamed of a fully document-oriented computing experience. Sadly the world has settled on the service-oriented experience of today, largely controlled by a small number of gigantic fiefdoms.