Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
The embarrassing drunkard uncle of invention.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.



Text Terminal, splitscreend with Tabbed HTML pages

psudo dumb "text+html5" terminal
  [vote for,

Basically I seen various efforts at a more richer console interface, like termkit. But I think that blending the "rich html" output with the standard console interface may not be a good/practical design decision (even if it is prettier from a user UI standpoint).

My main contention for this belief, is that console users, are often of the more technical kinds, and thus treats console from a more utilitarian pov (much like soldiers vs gun enthusiast. ). In that they have preference for reliability over presentation richness.

Thus, they tend to be more on the conservative side in terms of newer technologies, sticking to "tried and tested". To convince them, and others, an incremental approach may be needed.

So instead of combining what is essentially two kind of interfaces together. We would keep them separate, with the html interface as being an addon window instead. (To picture it. Think of a console window, side by side with a html browser. But where the html DOM is just as accessible to the server as the text console.)

So to reiterate. In addition to the console, a tabbed html window is placed side by side (with a stripped down html engine).

Tab name is "<progname> (: optional text)", so you always know which program is calling what.

Much like a real dumb terminal, the server can read/write the content of the html/terminal at anytime (e.g. if a link is clicked or not).

(Not sure if javascript should even be supported, but if it is, it would increase responsiveness of interface).

That's not to say that a true inline rich interface console shouldn't be done. But this could be a stepping stone towards such system.


What is it like in practice?:

* You could have a file browser on the side at all times, so clicking on a particular branch would do an auto "cd" and "ls" commands.

* Could display image if it is a dataurl

* Could show up a man page as a html/markdown formatted page or something more visually pleasing.

* Could have a tab that acts as the console equivalent of the "start menu", letting you browse though all the console programs.


Benefits from console dev standpoint:

* Preserves existing interfaces. Which means such system can still be used by standard text only terminals.

* Separation of text console from the side html browser. Can still keep original and reliable text console code. Since the "html browser" is a bolted on addon, rather than merged with the text console.

* Can transparently use existing web technologies. E.g. caeching.

* Most screens are rectangular rather than square, so split screen (or even triple split, if one tab is thin like a file browser), would not be a productivity issue.


Other consideration:

* Could add handlers, to auto detect stdout as being of a particular format (e.g. png, plain html, markdown). Those would be displayed by clearing and rewriting the "output" tab. Can reopen tab via a "reopen" tag next to that particular line from the console (or maybe a history section). [This is eqv to the ANS in matlab]. The handlers could be supplied by server, or by client. Maybe the handler are javascript codes?

* Instead of tabs for various html pages sent to html output... could arrange it as a timeline synced to console line number?

mofosyne, Jul 16 2015

What I mean by "ANS" in last paragraph http://stackoverflo...020/get-last-answer
[mofosyne, Jul 16 2015]

Fish Shell http://fishshell.com/
[mofosyne, Jul 16 2015]

termkit blog article http://acko.net/blog/on-termkit/
[mofosyne, Jul 16 2015]




back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle