stay wonderful.
see also: email / sr.ht / irc
home / cc by-nc-sa / webring

harrison

harrison is a vapourware computing environment and programming language that i am designing to be my ideal computing system. it is heavily inspired by {smalltalk} and the early mac operating systems. i call it "smalltalk for introverts", as it is a malleable graphical environment designed specifically with personal computing in mind; building large-scale software following "best practices" is not a goal.

§history

i've been interested in interface design for a long time, and even more so now. i am a gui apologist, and strongly believe that for any use case there can be a better gui implementation than an equivalent tui (which are for the most part inelegant hacks), even if one does not exist. this is not to say that a gui should eschew text; rather, it should take advantage of the flexibility and power of text, along with the flexibility and power of bitmapped displays, variable-width fonts, and so on.

i created an "operating system" in scratch (the block-based programming environment, not from scratch) called {celeste} a long long time ago. celeste went through several iterations, from a shallow clone of the windows aesthetic, a command line drawn with vector graphics, a buggy linux shell, and some more experimental features. i put it on hiatus for a long time, then while working on a programming environment inspired by microcomputers and basic for school started thinking more about what i actually wanted. around this time i played with squeak smalltalk some more, and gave celeste a hedgehog mascot (hedgehogs being like mice but cuter of course). my mum said harrison was a good name for a hedgehog (because of the french word for hedgehog), and i thought it would be a good opportunity for a new start name wise.

see {harrison interface history} for an evolution of mockups.

§design principles

i want to create a user environment that encourages them to build their own workflows at a high level, in the way that hypercard, excel, or pure data allow.

the system should be as easily learnable as possible, take advantage of physical metaphors where they are helpful, but not letting them get in the way of the advantages using a computer provides over these physical things.

consistent and simple for the user.

there should be as few moving parts as possible. early on i decided that this would mean that the only types of window were tabs and popups. now i believe there is definitely a place for modal dialogues (the command palette found in many editors is what turned me), but i think that they are abused and should be used as little as possible. there will be no file selection dialogue, for example, because every file should be created before it is opened, and there is already a file browser in the system. using mac os, i didn't appreciate the two different paradigms (i had finder set to be spatial, but the save dialogue was not) for what was essentially the same task. computers are advanced enough now that we can do things like background saves on close, so the user shouldn't have to bother clicking through modal error popups that could cause issue down the road (we never read them anyway).

make simple assumptions and leave difficult stuff to the host os (eg internet is provided via simple ethernet, don't support wifi). while this is a hosted system, we can get away with this.

§one: don't be clever

there are lots of ways to write clever software. don't. there are lots of ways to improve your perceived efficiency. why bother? take things slow, relax, and enjoy the journey. you can write code in notepad. that's pretty ascetic, but fine. why shave seconds off when you could greet them one by one?

§two: don't assume a legacy

this is hard to enforce or consider. what constitutes a legacy? what i mean here is that your code shouldn't only work when the font is monospaced. your editor shouldn't assume a monospaced font. keybindings shouldn't make intuitive sense only when the keyboard layout is qwerty. it's a stretch.

dream-oriented programming

mechanical inspirations of mine are smalltalk, self, classic macos, emacs. aesthetic inspirations are classic macos, haiku, chrome os.

§unsorted thoughts

there should not be a strong distinction between user data and code, but when there is, it should be exposed to the user. the system should not feel magical; a curious user should be able to think "i wonder what would happen if...", try it, and undo it with no repercussions.

it should have a cute animal mascot, usually portrayed holding a balloon on a string (the smalltalk balloon). i'm thinking a hedgehog, and i've put a quick sketch at the top of this page.

spatial file system, along with tabs? anything can only be open in one place at once. not sure how this would work with prototypes

§text

forth system, with two scopes: the line below the verb bar will automatically apply the first word (verb) to the window contents with the rest of the words on the line as arguments; the words in the verb bar will apply to the active region or whole window if no active region is defined

§further reading

see also