Basically I seen various efforts at a more richer console
interface, like termkit.
But I think that blending the "rich html" output with the
interface may not be a good/practical design decision
(even if it is
prettier from a user UI
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
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
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
Much like a real dumb terminal, the server can
the content of the html/terminal at anytime (e.g. if a
is clicked or not).
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,
clicking on a particular branch would do an auto "cd" and
* 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.
* 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
* 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
* Instead of tabs for various html pages sent to html
output... could arrange it as a timeline synced to console