Initial commit

1 files changed, 108 insertions, 0 deletions

diff --git a/lang.org b/lang.org
new file mode 100644
index 0000000..96c174e
--- /dev/null
+++ b/lang.org
@@ -0,0 +1,108 @@
+#+TITLE: Lang: smalltalk for introverts
+#+DATE: 2024-05-01
+
+Lang is a vapourware [[https://en.wikipedia.org/wiki/Retrofuturism][future-retro]] computing environment and my research vessel for exploring interface and system design.  It is a [[https://malleable.systems/][malleable]] graphical environment designed with personal computing in mind; i describe it as a *[[https://cuis.st/][smalltalk]] for introverts*.
+
+[[file:wp-content/lang-screenshot-cropped.jpg]]
+
+* History
+
+It should be clear that half the fun is careful consideration, and actual implementation comes second.  This is not a huge issue, as the act of designing is in itself a hobby, and one which a working environment would not be able to replace.  There is no time limit on the project.
+
+** A brief timeline
+
+I've been playing around with ideas for operating systems and computer interfaces for over a decade now, and some of the opinions i developed in that time are still visible in the current concept.
+
+The current monochrome, [[https://en.wikipedia.org/wiki/Classic_Mac_OS][classic mac os]]-inspired interface design first started to take shape in the summer of 2022.
+
+* Window system
+
+See [[https://hack.org/mc/texts/gosling-wsd.pdf][Gosling on window system design]] and [[https://9p.io/magic/man2html/1/rio][Plan 9's rio]].
+
+Window and programs should be considered separate, with the windowing system serving two purposes: first, allowing programs to draw pixels to a buffer; second, drawing this buffer to the screen if it's necessary.  Programs are not responsible for their decorations, and also should be written with the window system in mind, which can be responsible for tabbing.  Having tabs managed by a window manager is a feature i first discovered in [[https://www.haiku-os.org/][haiku]], and then enjoyed in [[http://fluxbox.org/][fluxbox]].  However the best tabbing implementation i have seen is that in [[https://www.google.com/intl/en_uk/chromebook/chrome-os/][chromeos]], which doesn't work quite as universally, but by moving as much as possible into the browser comes quite close to the desired behaviour.  This style of tabbing was replicated in [[https://nakst.gitlab.io/essence][essence os]].
+
+Because windows are just an area that belongs to a program, every window must have a program running in it.  In this system, that default program is the shell.  This should not be confused with a [[https://en.wikipedia.org/wiki/Unix_shell][unix shell]], as although the system shell is text-oriented, it is not text-limited.  The shell is described in more detail in its own section.
+
+* Shell
+
+See:
+
+- [[https://acko.net/blog/on-termkit/)][termkit]]
+- [[https://github.com/withoutboats/notty)][notty]]
+- [[https://www.destroyallsoftware.com/talks/a-whole-new-world][a whole new world]]
+- [[https://tilde.town/~dzwdz/blog/tui.html)][on tuis]]
+
+* Brain speed
+
+Human perception gives us three time limits to work with when designing interaction feedback: anything that is faster than 0.1 seconds will be perceived as an immediate reaction from the system; anything less than 1 second will not feel like a direct interaction, but will not interrupt the user's train of thought; and anything less than ten seconds will feel slow, but will be fast enough that they will be willing to wait for the action to complete.  we suggest that two different kinds of acknowledgement from the system are necessary for these different lengths: the cursor should show it is "busy" up to one second; for tasks that would take longer, progress dialgoue should be shown.  the progress dialogue should have a progress bar, and text which explains what is currently being done.  for actions should not need to care about waiting for, the system should as far as possible try and act as if the action is instantaneous.  for example, moving a large directory.
+
+** Faster isn't better
+
+eris on the issues of faster hardware, from the perspective of the end user: https://side-effects.neocities.org/anticapitalism/hardware.html
+
+** A timeline-oriented undo system
+
+2023-06-13
+
+there are two kinds of undo system in common use. both have problems.
+
+the first and most frequently used is the stack-based undo, where changes are pushed to a stack and undoing pops the last change from the stack. making a new change after undoing discards all popped items and adds to the stack from where the user had undone to. this is usually fine until it isn't, and then it's really frustrating.
+
+imagine a user undoes some changes, starts making new edits and then regrets the decision. they can't revert to the state past the undo.
+
+imagine a user is undoing and then accidentally makes a change. they've unintentionally lost access to the forward part of their undo history.
+
+web browser history is the same principle. it's common to search something and then look in and out of web pages. it's also common to then be frustrated that you cannot see the actual path you took through results, because every time you back out to the results and click a new link, the page you backed out from is removed and you have to head to the browser history page, which is inevitably (though not necessarily) terribly designed.
+
+this because both undo and browser history are really trees, not stacks, which has been noticed by various people and implemented in various programs, usually those designed for "advanced users".
+
+that leads us to the issue with the tree: especially in the case of undo, it's usually clumsy to navigate. especially when you factor in the fact that advanced users like keyboard shortcuts, suddenly there a bunch more that are necessary.
+
+there are also questions that arise: where to go when a user tries to redo at a final node when there were more changes further down the line in a different branch? surely there must be a good way to corroborate the changes (or maybe not).
+
+both of these solutions violate the harrison human interface guidelines, either by not treating user input and discarding it without explicit consent (which is also something that should be avoided), or by being too complicated.
+
+my proposed solution is a riff on the emacs way. emacs treats the act of undoing as a reversible editor action just like anything else which manipulates buffer text. so to redo, you actually undo the undo. this is powerful but unintuitive, which is why janky tree view solutions have been built on top of it.
+
+actually emacs has the right idea, but like a lot of emacs the exposed interface is terrible.
+
+i propose that instead, we keep the linear system, but make it time-oriented. here's how it works:
+
+1. the user is always at the end of the timeline after manipulating a buffer.
+2. to undo, they move backwards along the timeline, change by change. this is identical to how standard undo works.
+3. from any point on the timeline, they can move forward again, as redo would allow.
+4. if they manipulate a buffer, that must become the end of the timeline. instead of discarding anything further along, every change between the current point and the end is duplicated, its order reversed, and the new manipulation added.
+
+time is linear, so keep the history linear. that's a guiding principle i just came up with. if we're calling it an undo history, a browser history, it should respect time first and foremost.
+
+but won't clicking undo will get tiresome if my history keeps getting duplicated like that? probably. i discovered recently that the mechanical keyboard community were getting quite into rotary encoders (that's twisty knobs in everyday language). that article mentioned scrolling as one use case. i thought that was pretty cool actually, and since i want documents in celeste to only be scrollable in one dimension (up and down) seemed like a good use case. most documents are quite flexible in that regard. well, how amazing would it be to be able to scroll through space as well as time? extremely cool i thought.
+
+(note: i just noticed that "history scrubbing" is listed on that page already. guess i need to improve my reading comprehension).
+
+seeing as this proposal is probably not going to get picked up in the mainstream, i may as well propose an alterate reality (celeste) where things were different. one of those things is that scrolling through time with a handy knob is established functionality.
+
+
+* Development tools
+
+- [[https://www.youtube.com/watch?v=72y2EC5fkcE][Tomorrow corporation tech demo]]
+
+** Applications for creating and consuming
+
+2023-10-08
+
+I would like to see more applications that let me easily switch between creating and consuming.  That is, the same application can be used to easily view some media, and to modify it.
+
+Ironically, the best examples of this tend to be on mobile platforms.  For example, the gallery app usually allows me to view images and videos, and also to annotate and modify them.
+
+This doesn't have to entail complex creation mechanics, for which more heavyweight tools are often required, and will make the act of opening a file to view it take too long.  Although perhaps this is a problem with the current state of computers rather than the concept itself.  While i am not keen on the way Mac OS distinguishes between windows and running programs, you can much more pleasantly use a full graphic manipulation program as an image viewer when it is always running in the background.
+
+When i use Windows, i always set images to open in Paint by default.  It loads fast, and lets me annotate the images i am looking at.
+
+There are a large number of markdown editors available that show the source and the content in two panes.  I would like to further expand this concept and be able to write html in the browser itself.  The mainstream browsers all have two methods of viewing the source code of a page: the inspector, and the *view source* button.  Neither of these does what i want: the inspector doesn't make modification as easy as it could be, as it is more for inspecting than modifying; the *view source* button provides me with an entirely static page.
+
+If we continue to have distinct applications for creating and consuming, as i think we probably will, i would like to see two buttons in file managers.  One to edit, and one to view.  As far as i can remember, every file manager i have used has a default application to use for opening any particular file.  But i always have the trouble of often wanting to open for example a html page first in a browser, and then in an editor.  These two distinct tasks share a button, leading to an experience where i am frequently surprised by which application the file opens in.
+
+* Philosophy
+
+See Norma's [[https://normadesign.it/en/log/designing-in-black-and-white/][black and white]].
+