I've spend quite some time playing around with the usability issues of the console interface, both in windows and linux and embarked on a journey to see what could I improve.
So far the results of my experiments are nice, a simple command line 'readline' in python capable of basic editing like text selection, copy / paste without the mouse, select word, next / prev, etc etc
Thing is, done with a MVC pattern was easy peasy and got done in no time, even adapting it for a windowing environment would be rather trivial but the parsing thing lead me to implement an EBNF reader in python which indeed took a bit of an effort.
The ebnf reader was done with a non-recursive algorithm for performance and limitations related to python for recursive calls (it does support recursive calls but then they're limited and has some issues), in short the core parser is a one-function non-recursive state machine in the order of 200+ lines of python code.
I may release it if there's interest, it's usage is simple: you feed a ebnf text and returns a grammar, you call parse passing a string and returns an AST (abstract syntax tree) so there's no intermediate steps like traditional yacc / lex / bison and so.
Still, on the usability front, played with few ideas, the one i'm currently after is implementing autocomplete and 'in place' editor, what's the in place editor?
Imagine you're typing something, say:
mycommand.py "my string arg is \"1\""
The oddity here is to have to escape the string, i've been wondering about having some sort of 'enter editor mode' key that would let me write the string normally and will escape it for me. for example once the cursor is inside the quotes I could press say ctrl+enter or so and the line switches to something like:
mycommand.py "my string arg is "1""
then just ctrl+enter to exit the 'string edit mode' or just leave the section moving with cursors or shortcuts so as to have it escaped for me.
The idea is simple, while not terribly usable but explores the idea of 'in place specialized editor' that can be used for other things besides auto escaped strings
So next things next, need to plug the ebnf with the autocomplete and do a proof of concept of the in-place subeditor, surely it will take some iterations to get it easily usable.
Then who knows, i'll be poking around with the ebnf and user inputs, maybe something iteresting arises out of it.
-Mat
Sunday, May 4, 2014
Thursday, April 10, 2014
Bashing the bash, usability sucks
Oh, not really, I don't meant to rant about Bash but about usability in general.
It has been quite some days that I started thinking about usability from the bottom up, if I would have to start an operating system from scratch, what would I do different, what would I change?
By operating system, I mean the user interface, be it command line or windowed environment, while operating systems had advanced a great deal in terms of handling the new hardware, task scheduling, memory management and all that low level stuff It feels like the user has been abandoned in many ways.
Let's start ranting :)
The command line sucks big time, there is no denying that it is extremely powerful, you can accomplish incredible things that are near impossible in a windowed environment, however, in any linux or windows distribution nowadays can you actually do something as simple as copy paste WITHOUT using the mouse? I'm no linux expert but I wasn't able to find a way to do it, yes you can ctrl + shift + c but how do you actually select text without the mouse?
Even if there is a way or a special console or terminal it is entirely up to you to find, install and configure it, face it, both windows command line and linux console / terminal did a poor job in modernizing some stuff.
Windows console is by any means extremely primitive, not even worth ranting at it so let's not even talk about it, what about linux?
Well, we start with a terminal (not the same as the console, however usability wise they're not that far apart), the terminals starts with an emulator of an old VT100, old? according to wikipedia "It was introduced in August 1978" oh my god... while most terminal emulators starts from there isn't it time to 'upgrade' from 1978?
Does it gets the job done? yes, can we do better for the end user? sure! please! at least a way to select text without using the mouse!
So here is some 'idea' (and i'm being sarcastic here...) why don't we do so that we can select text by pressing shift and the arrow keys? following up that line, lets also make use of the backspace key in a sane way (console and terminal hackers know what I mean), home, end and all the other basic things, while we're at it, copy paste would be appreciated (Thanks Larry Tesler, who's credited as the inventor of it somewhere between 1973-1976), or is it so that "real men don't copy/paste, they make holes in cards"?
With this thoughts I embarked on a new adventure and started coding some experiments that go further than that, only to open a can of worms... linux configuration files for the editors and terminals...
Before continuing, my disclaimer: "I am not an advanced linux user, I poked around a bit and am in the process of learning more"
So here's what I found out: it sucks, vi has it's keyboard bindings, emacs it's own way, the terminal another one, and while we're at it, the console is another story.
Oh my... here's another 'idea', a central configuration for the user preferences, for example:
ACTION_SELECT_LINE: KEY_CONTROL + KEY_L (for example)
Ideally nano, vi /vim, emacs and the usual suspects could use system provided default action bindings while allowing local customizations for maximum flexibility. (there is some attempt in some config files for termscaps and so, but is far from working). When I think about the students getting themselves for the first time with these tools I cant help but feel sorry for having to deal with such usability mess.
You know, I don't deny the power of emacs or vi, but come on... the power wont go away by being friendly towards me...
Where did my observations lead me? well I started a small experiment, while I'm not sure where I'm heading it is surely illustrative and entertaining to a degree, this is what I'm up to:
A system level text input mechanism
Must support pluggable parsers with cascade capabilities (nesting languages)
Must provide letter, word, paragraph and document 'pluggable services'
Must use global configuration for key bindings to actions with possibility of local override configuration
Must work in windowed, console environments (web pages is a plus)
Things I'd like to achieve:
enter a command in the command line, strings are escaped for me (parser integrated into the text input, or think of it as a subeditor you can easily enter / exit 'in place')
autosuggest / text completion 'bash style' everywhere (as long as you set the right parser for the input)
context dictionary suggestions
nearly ready for use in code editors, given of course the parser and lexers necessary for it
somehow standard way of a program to exhibit it's command line parameters for autocomplete in the command line, to some degree bash does this (I think it has a database of programs with their parameters, need to dig deeper into how it does it)
Why? just because!
-Mat
It has been quite some days that I started thinking about usability from the bottom up, if I would have to start an operating system from scratch, what would I do different, what would I change?
By operating system, I mean the user interface, be it command line or windowed environment, while operating systems had advanced a great deal in terms of handling the new hardware, task scheduling, memory management and all that low level stuff It feels like the user has been abandoned in many ways.
Let's start ranting :)
The command line sucks big time, there is no denying that it is extremely powerful, you can accomplish incredible things that are near impossible in a windowed environment, however, in any linux or windows distribution nowadays can you actually do something as simple as copy paste WITHOUT using the mouse? I'm no linux expert but I wasn't able to find a way to do it, yes you can ctrl + shift + c but how do you actually select text without the mouse?
Even if there is a way or a special console or terminal it is entirely up to you to find, install and configure it, face it, both windows command line and linux console / terminal did a poor job in modernizing some stuff.
Windows console is by any means extremely primitive, not even worth ranting at it so let's not even talk about it, what about linux?
Well, we start with a terminal (not the same as the console, however usability wise they're not that far apart), the terminals starts with an emulator of an old VT100, old? according to wikipedia "It was introduced in August 1978" oh my god... while most terminal emulators starts from there isn't it time to 'upgrade' from 1978?
Does it gets the job done? yes, can we do better for the end user? sure! please! at least a way to select text without using the mouse!
So here is some 'idea' (and i'm being sarcastic here...) why don't we do so that we can select text by pressing shift and the arrow keys? following up that line, lets also make use of the backspace key in a sane way (console and terminal hackers know what I mean), home, end and all the other basic things, while we're at it, copy paste would be appreciated (Thanks Larry Tesler, who's credited as the inventor of it somewhere between 1973-1976), or is it so that "real men don't copy/paste, they make holes in cards"?
With this thoughts I embarked on a new adventure and started coding some experiments that go further than that, only to open a can of worms... linux configuration files for the editors and terminals...
Before continuing, my disclaimer: "I am not an advanced linux user, I poked around a bit and am in the process of learning more"
So here's what I found out: it sucks, vi has it's keyboard bindings, emacs it's own way, the terminal another one, and while we're at it, the console is another story.
Oh my... here's another 'idea', a central configuration for the user preferences, for example:
ACTION_SELECT_LINE: KEY_CONTROL + KEY_L (for example)
Ideally nano, vi /vim, emacs and the usual suspects could use system provided default action bindings while allowing local customizations for maximum flexibility. (there is some attempt in some config files for termscaps and so, but is far from working). When I think about the students getting themselves for the first time with these tools I cant help but feel sorry for having to deal with such usability mess.
You know, I don't deny the power of emacs or vi, but come on... the power wont go away by being friendly towards me...
Where did my observations lead me? well I started a small experiment, while I'm not sure where I'm heading it is surely illustrative and entertaining to a degree, this is what I'm up to:
A system level text input mechanism
Must support pluggable parsers with cascade capabilities (nesting languages)
Must provide letter, word, paragraph and document 'pluggable services'
Must use global configuration for key bindings to actions with possibility of local override configuration
Must work in windowed, console environments (web pages is a plus)
Things I'd like to achieve:
enter a command in the command line, strings are escaped for me (parser integrated into the text input, or think of it as a subeditor you can easily enter / exit 'in place')
autosuggest / text completion 'bash style' everywhere (as long as you set the right parser for the input)
context dictionary suggestions
nearly ready for use in code editors, given of course the parser and lexers necessary for it
somehow standard way of a program to exhibit it's command line parameters for autocomplete in the command line, to some degree bash does this (I think it has a database of programs with their parameters, need to dig deeper into how it does it)
Why? just because!
-Mat
Subscribe to:
Posts (Atom)