Interfaces of the future - Printable Version
+- nixers (https://nixers.net)
+-- Forum: General (https://nixers.net/forumdisplay.php?fid=3)
+--- Forum: Psychology, Philosophy, and Licenses (https://nixers.net/forumdisplay.php?fid=28)
+--- Thread: Interfaces of the future (/showthread.php?tid=2233)
Interfaces of the future - z3bra - 30-11-2018
Context: I'm starting a new thread here to sum up (and continue) discussing what started as an innocent introductory thread, and ended up in an intense philosophical debate about computer interfaces, as in defined standards VS. obsolescence of these standards.
At the very beginning, computers where huge, slow and had scarce resources. The geniuses at that time came up with what's currently considered the base of computing: the Unix operating system.
This system used plain text as its unique input/output system, taking input from a keyboard, and printing output on paper sheets, one line at a time.
A lot of water flowed under the bridge since then, and even if peripherals greatly improved, this textual interface is still at the core of most the derivatives of Unix.
There are now two main ideas:
One is that this proves the good design of Unix, as its interface went through the years efficiently without needing any change:
(29-11-2018, 12:13 PM)z3bra Wrote: Text is still a good human-to-machine interface (IMO, better than sound for example, or pictograms), and POSIX defines its standards around this interface.
(29-11-2018, 04:34 PM)z3bra Wrote: I guess the CLI is better at letting people express what they want to the computer, rather than GUI. You have to learn how to "speak" your computer language, which is tedious, but in the end it is easier to bind your computer's will by explaining what you want to do, rather than miming it through the GUI
The other, is that the interface was defined in a restrictive environment, and should evolve to fit better today's technology:
(29-11-2018, 12:33 PM)jkl Wrote: POSIX follows a hardware standard that was outdated thirty years ago. "My" perfect interface would be a sane mixture between (a visually more appealing) Plan 9 and dwm, I guess. I learned to make my peace with the mouse. (However, the default Plan 9 lacks hotkeys, rio's missing ability to spawn a terminal without drawing a window manually can be annoying. I guess Windows has spoiled me.) Imagine an operating system that was built upon a graphical interface instead of wrapping the graphical interface around a text-based system. Many of the architectural problems of Windows "9x" came from the DOS base which couldn't just be replaced.
Of course, the answer to this topic is not black or white, so please share your opinion!
And please, don't start a flamewar (even though this topic would be a perfect fit for it!)
RE: Interfaces of the future - venam - 30-11-2018
My perfect interface of the future would mix parts from everything.
The ability on MacOS to search the top bar menus just by starting typing
The OS is made of interoperable component, this has been tried so many times but always involves complex things like object models and rpc, I'm not sure how this would unfold
Graphical interfaces should be used for configuration if we're interacting with "objects". This makes much sense when configuring units files (services) or when configuring the network (every port is an object) or firewall rules.
Other simple configurations, key/value pairs could be text.
We shouldn't miss the ability to script things up, and the pipelining. This could be something like plan9 does or it could not.
There should still be a cli, but I'm not sure if it would be the same as it is now. Maybe you could spawn a cli over a running program to interact with it on the fly, or spawn a normal cli system wide.
When running over the network I'm not sure of what would be best, should we rely on form filling (web-like apis) or should we use cli or should we use remote desktops.
Some of those could possibly be implemented on any Unix-like OS as it is now, some would need a bit of fixing.
Just some random ideas thrown around.
RE: Interfaces of the future - jkl - 30-11-2018
I find z3bra's signature fascinatingly fitting here. :-)
I know that established standards are helpful when trying to find a digital Esperanto. Whatever we'll find out here, we'll need to create "a standard", a 21st century POSIX replacement that covers mobile and desktop usage.
I wonder what is needed.
RE: Interfaces of the future - z3bra - 30-11-2018
When it comes to configuration, I think we need a mix of both CLI, and GUI.
Take an Exchange server for example: Everything is doable from the CLI, but it is tedious and noisy, especially for listing stuff, or searching objects.
That is where the GUI takes over, which lets you unfold the mailboxes, sort contacts or changes indivudual properties (and it is actually easier to do from the GUI, trust me!)
Now evereything in the GUI is bound to a command, which can be run in the CLI. The GUI gives you acces to predefined commands, so they complement each others pretty well!
From a desktop point of view, it is also easier to use a graphical interface rather than text only. The fact the TTY week is a difficult challenge is sufficient to prove it!
For a good experience, all GUI applications should be able to communicate with each others (hint: system clipboard!), to provide a slick and smooth interface.
To sum up my idea, we need both CLI and GUI, as they complement each other well, and both solve different cases.
When it comes to the IPC, I am confident that textual interface is a good way to go, over binary blobs. Parsing text is mastered today, so it's cheap to implement. It is also human readable, and less subject to data corruption.
RE: Interfaces of the future - twee - 30-11-2018
I mostly use computers for processing data - reading text files (which yes i did convert from pdf, i will explain more shortly), writing articles for my site (haha funny), essays for school (philosophy etc), programming. like it or not, our society is built around using text for these things.
My perfect interface would be a text display, which can display graphics etc inline. It should also allow interactive text components to link to other such windows. In short, something like traditional hypertext.
I think that Emacs does a very good job of implementing such a system. this is why i like emacs. Emacs also has the advantage of allowing mouse control or keyboard control, and having (easily) human readable configuration files (no xml) that can be edited as text or gui. it may have a bit of a learning curve, but it really does cater to all demographics (i think).
there is no space for a mouse in my personal interfate - this is not necessarily because i believe that a mouse is less efficient than a keyboard, as i have seen evidence that a mouse can be very efficient. it is just that i have found that it is a lot harder to buy a low quality keyboard than a low quality mouse - that is, cheap keyboards always work a lot better than cheap mice. this is important to me as i spend a lot of time using computers which are not mine, and i do not want to have to carry a mouse with me. learning to cope without a mouse is much easier.
one thing i definitely do not want to see is dropdown menu toolbars. i think that most of the time they are bad as items could go into several sub menus, or it is just hard to find and discover what you are looking for. they are a epitome of bad mouse ui design. they impose heirarchies where there are often not (although i know sometimes there are). i dont know, they are just not good. i think some kind of search system with tags would work better (rather like emacs with helm, which i do not actually use myself).
anyway, better a mouse than touchscreen. all the touchscreen designing is resulting in wasted space and superfluous animations. it is detrimental whatever you believe in.
by the way, jkl, i have seen that acme video, it does not change my views on the system compared to emacs, but I had forgotten the fundamental key chording thing. that is a very nice use of mouse.
RE: Interfaces of the future - twee - 30-11-2018
I also think a universal quake terminal type thing could be a good way of allowing access to the command lite version of a tool
assuming we are keeping gui as an interface to text commands as everyone here appears to be saying (correct me if i misunderstand)
RE: Interfaces of the future - jkl - 30-11-2018
(30-11-2018, 09:55 PM)twee Wrote: I mostly use computers for processing data - reading text files (which yes i did convert from pdf, i will explain more shortly), writing articles for my site (haha funny), essays for school (philosophy etc), programming.
And none of that would be made harder with a text editor that is built around a GUI instead of limiting you to the console. Even the GUI version of GNU Emacs has certain usability benefits. (I saw an "Acme plug-in" for Vim once, though, implementing parts of Acme's tagbar. Not quite convincing yet.)
(30-11-2018, 09:55 PM)twee Wrote: My perfect interface would be a text display, which can display graphics etc inline. It should also allow interactive text components to link to other such windows. In short, something like traditional hypertext.
(30-11-2018, 09:55 PM)twee Wrote: it is just that i have found that it is a lot harder to buy a low quality keyboard than a low quality mouse - that is, cheap keyboards always work a lot better than cheap mice.
And still you probably won't regret having spent a decent amount of money on either. :-)
(30-11-2018, 09:55 PM)twee Wrote: by the way, jkl, i have seen that acme video, it does not change my views on the system compared to emacs, but I had forgotten the fundamental key chording thing. that is a very nice use of mouse.
Indeed, it is. But I'm not here to convert anyone. I'm not even sure if what I use is always a good idea. ;-)
RE: Interfaces of the future - z3bra - 01-12-2018
Some kind of interface I would like to see more is a mix between arbitrary text buffers (say, like a text editor), and a command line interface that could display inline graphics.
What I mean by "arbitrary buffer" as already been implemented at least once (I think acme works similarly, albeit not sure). Any bunch of text can be a command, and it's not the system that will tell you (with an error!) wether what you entered is a command or not. You can run "any text" with a single, simple action, and YOU, as the user, decide what is a command , and what isn't.
The reason I don't use that editor is because it is hard to compile, and doesn't work well remotely (require X.org).
I'd definitely be happy if it was the norm though!
RE: Interfaces of the future - twee - 01-12-2018
Emacs works at least in part like this. C-x C-e will execute any lisp expression that you specify, wherever you are. also using org babel you can run code from any language, and pass the results to other code in tte buffer, even in a different language (iirc).
in this respect, emacs is really rather good. where it falls down is that it is still single threaded. when running emacs as wm (which i have attempted on occassion) doing anything which takes a while (eg transferring 14gb of mp3s to a usb drive) the whole interface stops.
beyond that, i was very happy with just emacs. i could call other x applications if i needed them (which i rarely did), and being able to fuzzy search for any buffer was very nice.
As a result oy this discussion i definitely want to try acme again. although, working mostly on a laptop in various places, i think navigation could be a bit difficult
jkl Wrote:And still you probably won't regret having spent a decent amount of money on either. :-)this is true. but at the moment i dont have enough money to warrant spending it on something i wont make regular use of until i have bought it, and may not even then, if that makes sense.
RE: Interfaces of the future - jkl - 01-12-2018
(01-12-2018, 03:08 AM)z3bra Wrote: What I mean by "arbitrary buffer" as already been implemented at least once (I think acme works similarly, albeit not sure). Any bunch of text can be a command, and it's not the system that will tell you (with an error!) wether what you entered is a command or not. You can run "any text" with a single, simple action, and YOU, as the user, decide what is a command , and what isn't.
Yes, that's exactly what acme does. :-)
(01-12-2018, 07:31 AM)twee Wrote: As a result oy this discussion i definitely want to try acme again. although, working mostly on a laptop in various places, i think navigation could be a bit difficult
You might be interested in acme2k, providing additional keybindings for your convenience. You can just build and install it over your existing plan9port.