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?