This is my notes on a future-retro computer in the style of a personal digital assistant.
Currently the page is a dump of related notes, and the flow is off.
I think computers are in general a good thing, but that multipurpose personal computers are less good. Any device that is essential simply by virtue of being a device leaves a bad taste in my mouth. After considering exactly what i wanted to use computers for, i started working on this design to be used only for those purposes. With that in mind, this computer should allow me to:
I want something small and low power that i can easily throw in a bag.
An a5 notebook seems to be about the right size. Other devices with this form factor include the pocket chip, the yarh.io and the blackberry passport.
The design should take inspiration from the thinkpad line of computers. I like the black boxy shape. I like exposed screws for easy internal access.
There is no need for colour or a backlit display. It also does not need to be particularly big. It should update fast enough for typing to have immediate feedback. I like the style of display found in scientific calculators. Here are some potential contenders:
The system should have an ortholinear keyboard of a 10x3 matrix, and six modifier keys.
Capital letters are inputted by pressing and holding a letter key.
I would also like to explore having chinese input totally embedded in the keyboard. A stroke based method such as wubi seems like it could support this use case.
Somehow a keyboard that isn’t uncomfortable despite the small size. Seems that a ten key wide ortholinear layout with kailh choc caps is the perfect size to fit snugly in the short edge of b5 paper.
The keyboard should be able to be comfortably usable with thumb typing.
Use a raspberry pi zero. Slow is good, raspberry pi zero isn’t slow, but software isn’t fast enough.
This computer doesn’t seem too far off design wise.
usb c charging with inset ports for less fragility. should work with a slow charging so low power. See this little charging module and this battery.
chinese input method, preferably stroke based rather than sound based. would be interesting to see if this could get implemented at the keyboard level
access “simple” internet, mostly for email and uploading website
In order to update my website and send and receive email, the computer must somehow connect to the internet. However, the internet stack is very complex.
One solution is to use another device as a sort of modem, and only deliver the simplest representation to the device itself. Seeing as i have resigned myself to having a phone, using that and transferring data over audio in a similar way to chibitronics could be one solution.
The system should run fast and be small.
The system should be rechargable via usb c. Depending on how long the power would last, aa batteries are also an option.
The system is designed to allow me to take notes and interact with email. There are two types of screen to this end: the document screen and the search screen.
The document screen is the main place i will interact with the system. It is made up of a few parts.
In the top left corner is an indicator to say whether the document matches its representation on disk. It is empty if the file is saved, and has an asterisk if it has changed.
The rest of the top line of the screen is the status bar. The status bar will display some information about the current file and about the device, such as battery life and whether it is sending or receiving data.
Along the left edge of the screen is a scroll bar. The system doesn’t have mouse support, so the scroll bar only serves as a visual indicator of the size of a document and where i am within it. The white section represents the part of the document currently shown on the screen. It changes size to be proportional to the content.
The rest of the screen is the document window. Text automatically wraps if lines are longer than the screen width. The font is proportional. Different sizes and weights of text are supported.
The search screen allows me to switch between different documents stored in the system. There is no hierarchical filesystem. All documents, including those created by me, those that make up the system, documentation, settings, and emails, are found in a single list.
In the top left corner is a house icon to represent the view is not a document.
The rest of the top line of the screen is the search bar. An empty search represents all files. Search is fulltext and some special attributes are supported, such as searching by tag and the not operator.
Along the left edge of the screen is a scroll bar.
The rest of the screen is the search window. All documents matching the current query are listed in reverse chronological order. The document highlighted in inverse colour is the selected document.
The first result in the search window is always a new document action.
i think spatial file management and tabs are two great user interface patterns, and i’m trying to work out the best way for them to work well together in harrison.
spatial file management is the skeumorphic design principle that most famously underlies the classic mac os finder, but also several other file managers including haiku’s tracker, amiga’s workbench, risc os’s filer, and gnome’s nautilus in the refreshing period around version 2.6. the theory is as follows:
it’s an extension of the classic desktop metaphor, and it worked great, especially as everyday people were getting used to using computers. they saw a file icon on the screen not as a representation of a file on disk, but as the file itself. this has benefits and drawbacks, of course, but it is a very intuitive way of experiencing an interface.
at some point tabs came along and ruined everything.
tabs have the advantage of not taking up much screen space and allowing easy access between multiple resources. however, they are program-centric, which means they are filetype-centric, when really they should be workspace-centric. you are much more likely to want to keep switching between different tabs, one for research, one for an essay, or one for documentation, one for source code or something, than multiple of the same file type.
browsers have lessened this problem for many people by consuming anything they possibly want to do. but this is not the best solution really.
it’s difficult to add tabs to a window spatially, as what exactly does the window represent at that point? in a browser, most pages you visit will be on different servers, and at that point there’s barely any use for spatial tabs and windows as each window (even for a whole domain, say) is likely to contain only one tab.
All settings are stored as key value pairs in a text file. Changing the text file immediately updates the respective setting.
I am certain that none of the ideas documented here are original. In this section i will discuss some of the other systems i have used, and the things i liked and disliked about them.
Classic Mac OS (System 6 and earlier)—i don’t think that this will surprise anyone, because graphically there are many clear similarities. I like the playful nature of the early Macintosh, and how personal it is, with the names of the programmers written in the programs.
Icons contribute greatly to the clarity and attractiveness of an application. The use of icons in addition to (or instead of) words can also make it easier to translate programs into other languages, except where the icons have different meanings in different cultures. An item is easier to remember when it’s represented by an icon with text than if it’s represented by either an icon alone or text alone. Wherever an explanation or label is needed, consider using an icon.
—the apple desktop interface (1987), p. 42
it’s understandable that apple wanted to push the gui aspect of the macintosh as much as possible, but sometimes this got in the way of clarity. though the idea was to use icons to complement text, often icons were displayed without text.
Canon Cat¹—there are things i like and don’t like about the Cat and the rest of Jef Raskin’s work, though i recommend his book The Humane Interface to everyone. Two things i particularly like about the Cat is the lack of context switches, and the way that disks work. I have tried to remove the idea of different programs that work in different ways from Celeste, though i’ve approached that in a different way to Jef. Celeste is similarly image-based, with a disk holding the state of the RAM.
Jef Raskin is a human-computer interaction expert and the originator of the original macintosh project at apple.
in his book the humane interface, he goes through many principles of how computer interfaces should behave to make them best fit human psychology. i’ve adopted many of those principles in the human interface guidelines.
the book is very good and i recommend it to anyone designing digital interfaces. but there are some parts which i consider questionable.
Jef is a big proponent of the zoomable user interface paradigm, where the display represents an infinite two-dimensional surface, and the user can zoom in or out to see more or less detail. the example he uses in the book is a project wall, which enables you to get a general overview by standing in the middle of the room, and can move closer to specific parts of the wall to read what is written there. two occurences of this in current applications are map interfaces, and android/ios folder representations, where you see tiny icons inside the folder, and can bring them up to the usual size by opening the folder.
it’s easy to see the appeal. with a zoomable interface, you can lose the file/folder abstraction and complications that come along with it. everything is part of a single workspace so documents can be added near to where they should logically be positioned, and zooming means that there is always more space to add something. because everything is on a single plane, there are no discrete applications with different keyboard shortcuts.
ever since discovering the zoomable paradigm, i’ve wondered about how this would apply to web browsers. the consistent thing would be that zooming in on a link opens that page, but of course this is a difficult transform to visually represent, as links are text not tiny windows onto new pages. furthermore, the web is very big (citation needed) so it’s not feasible for it to exist in entirity on the user’s workspace, and getting access to it is not generally initiated from an iconic portal. Jef’s vision of the workspace is of documents next to each other, so it could be that a web page, when requested, populates the workspace. but then, i am unsure how the next page the user clicks on would be shown. i was hoping Jef would provide clarity, but all he says is that it’s clear how such a browser would work. i don’t think it is.
Jef proposes getting rid of discrete applications, and indeed with the canon cat he does this. this works very well if all we are dealing with is textual content (numeric content being distinct from prose, but still ultimately textual content). a big part of the appeal of a personal computer, though, is its general-purpose nature. even on the early macs, applications were available for digital art and audio production. these different sorts of applications don’t seem to be a good fit for such a consistent interface, and if they are, Jef does not explain how. perhaps general-purpose computers weren’t a big part of his vision. that’s fine.
the modern mac operating system is not well designed.
there was a period early on where its design was acceptable, but apple have chipped away at this over the years to make a mess of a product.
fullscreen - the green traffic light button fullscreens a window. it doesn’t maximise it, it fullscreens it. this makes it go onto its own virtual desktop, stops switching windows with the keyboard from working, and sometimes (not always) hides persistent ui elements such as the menu bar. i have no idea why this was thought to be a good idea.
closing windows - the red traffic light button closes a window, not an application. this is a holdover from the classic mac os days, where only one application could be run at a time. then, it made sense that the application would stay open when the window was closed. (sense not from an interface perspective, rather from a constraints perspective). if a user had a text editor open, there was a chance they would want to edit another document after the first, so keeping the program loaded saves time for the user.
now, programs should load instantaneously (though this is often not the case). being able to switch between applications with the keyboard and have the only visual feedback be a change in the toolbar is frustrating and confusing—it looks like nothing has changed.
application switching, not window switching - related to the above, the default command+tab behaviour is to switch between applications, not visible windows. gnome has also opted to use this behaviour, and did not find that either became intuitive to me. frequently, i will want to switch between two browser windows and two document windows. for some reason, i need two keyboard shortcuts for this.
the toolbar at the top of the screen - once again, this is a holdover from the classic mac os days. fitts’ law says that buttons on the edge of the screen have a much bigger target area than buttons in the middle of a screen. this is true. but these days, three things have changed:
first, people often have more than one monitor. using mac os, these can not be stacked, because to do so would lose the fitts’ law advantage (your mouse shoots right through to the next screen).
second, more than one application can be open at once. this means that i cannot access menu items for an application without clicking on it first. say i have two visible windows: an active browser window and an inactive document window. if i want to access the menu for the document, i must first click on its window to activate it, then move to the menu bar. that may still be slower than attaching the menu bar to the window below the titlebar, as windows does, but if the menu bar was the uppermost element in a window, the would be no speed penalty for a maximised window, but also no speed penalty for two maximised windows.
third, modern appications rarely use the menu bar for their key interactions. whether this is a good thing or not is up for debate (i think it depends what they choose to do instead). regardless, this means that key screen real estate is being taken up by a useless interface element.
bad animations: apple’s workspace switching animation.
good animations: apple’s window movement animations: zoom open folders, zoom minimise windows (not the genie effect though)
Smalltalk—a family of languages with the isolation and exploration i like.
Plan 9—primarily the executable text.
Emacs—while i couldn’t give an explicit example of a feature i copied right now, Emacs is a piece of software that i use frequently, so i’m sure that some things must have crept in.
Kinopio²—a delightfully designed interface and self-contained world. This isn’t supposed to be a general-purpose environment like some of the things on this list, but the best way of solving its particular problem space has been very thoughtfully considered, and it shows.
The part of a system that a user knows is the part that they use, as the name suggests. Therefore, this user interface must act in such a way that the user can feel familiar with it. These are my guidelines on how to create interfaces that will let the user do what they want to do with the minimum of friction.
My intention is for these guidelines to be based on fact, not opinion. If you think anything veers into opinion, let me know and i will do my best to make alterations. If you follow them, it is my hope that anyone using your application could not tell me exactly how they went about using it, because it was so easy for them to do so that no pain points stuck out in their mind.
Do note that i am writing this with the Celeste system in mind, which may work differently to other common systems. Because of that, some of the principles given may not be directly transferable to other systems. I encourage you to consider carefully the underlying point of any advice given, and from that draw the right conclusion on how your application should work.
Principle of Physicality: people understand the physical world because we live in a physical world. It follows that where possible we should bring these affordances into the digital interfaces that we design. I see the main physical affordances as being reactivity, immediacy, and spatiality.
Every action causes a reaction. If i push something, it moves. If i press something, it clicks. Similarly, things don’t click without being pressed, and things don’t move without being pushed. Of course there are exceptions to this rule because the world is so big. The advantage of a computer system is that we can work at a manageable size where things really do only react to actions.
Whenever i perform an action, the reaction happens immediately. If i push something, the movement happens with the push, not a few seconds later. Within a computer system, anything that feels like it should happen at once should act like it has happened at once¹. Behind the scenes, things may take longer, but this is an implementation detail².
Every element on the screen has a presence. They cannot teleport or blink in and out of existence. Within computer systems, we can make use of animation to show hierarchy and position³. Windows can zoom out from their parents, and zoom back in when they are closed. Jumping to a section of a document can cause the window to scroll until it reaches it.
Note that animations should not be blocking. Take as long as you like to transition between two windows, as long as they user can start typing into the new window immediately after enacting the transition.
Humans are usually better at locating things based on where they are and what they look like than by name.
Principle of Forgiveness: in the physical world, often making a mistake means starting over. Here is somewhere that computers have a significant advantage, because undo is a powerful concept we can take advantage of⁴. There is no reason to limit the amount of undo history until the limits of the computer hardware are reached.
In many existing computer interfaces, modal popups are used before an action is taken rather than enabling undo afterwards. This is especially common with destructive actions such as deleting files and irreversible actions such as sending emails. The problem with this approach is that it causes the user to form the habit of clicking through any alert without reading it, which can have significant consequences⁵. Instead, put off irreversible actions for as long as possible. For deleting a file, this may mean setting a flag on the file that isn’t processed until the system is shut down. For sending an email, i suggest an airgap of about a minute⁶. Make sure to use your common sense here; if an instant messenger were to hold messages for thirty seconds it would become frustrating, because it would no longer be instant. The informality of the medium means that spelling mistakes and forgotten attachments are unlikely to cause the same embarrassment as they would with an email. Before the action is actually undertaken, the user should be able to reverse it.
The key takeaway from this principle is to ensure that the user feels in control and does not need to panic. Panic leads to more mistakes, resentment, and misery⁷.
Principle of Consistency: consistency is golden. The look of your application should not be unique⁸. Make the function stand out because of its function, not its form. Buttons and keypresses should always do the same thing.
Things that behave differently should also look different. people don’t mistakenly brush their hair with scissors, because the function is clear from the design. Don’t just change the colour of an element, change its shape too, because not everyone can distinguish between colours.
Things that are not related should be separate. Humans like to find patterns in everything, and they are good at it, even if there isn’t a pattern, even if a pattern is accidental⁹. Do your best to avoid accidental patterns, and to cultivate intentional patterns.
If you update your application to add a new feature, you face a dilemma: where do you add the new feature into the interface? You are inevitably going to have to move some interface elements around, which will frustrate your existing users, who are used to particular positions. You should try to find the best middle path here: don’t resist change too much, but avoid change for the sake of change. On the other hand, obsessive backwards compatibility is the bane of well-designed software. The people already using your application should be more valuable to you than people not using it. on the other hand, if someone is not using it and you think perhaps they should be, ensure that the reason they are not is because of any accessibility issues or other integral design decisions that you overlooked.
Principle of Modelessness: avoid modal systems, which add the unnecessary mental burden of remembering which mode is active.
Modes are systems of operation where the same input will result in a different output. A notorious example is the caps lock key.
If you think that a mode is necessary, see if it can be replaced with a quasimode. A quasimode is a mode which is enabled by a constant action from the user. The shift key is the quasimode parallel to the caps lock key. Control, alt, and the other keyboard modifier keys are also examples of quasimodes. Quasimodes have the accessibility advantage of being easily translated to modes, while the reverse is not always true. Microsoft’s stickykeys are an example of converting quasimodes into modes, to make the functionality more accessible to people with physical disabilities.
If not, try and design it out of your interface. Otherwise, ensure that it is very clear at the user’s focus which mode is enabled. The vi family of editors fails at this, with the only indication of mode being a label at the bottom of the screen. If the user is looking at the cursor, this is entirely redundant. Some graphical versions change the cursor from a block to a line to distinguish the two most common modes, which is a good start. Apple’s Mac OS has a help feature which changes the cursor into a question mark until anything an interface is clicked. This is a good example of a mode, because the user’s focus is on the cursor. Modeless operation tends to be tied to a noun/verb interaction order. That is, i select something and then act upon it. Modal software tends to encourage a verb-noun order, which can be useful for batch operations, but has two main problems: first, it breaks the principle of immediacy; second, it causes more error for the user, because upon making the noun selection the verb is immediately executed, with no room for making adjustments to that selection. Letting the user make the noun selection first means they can be totally satisfied that on executing the verb, they will immediately see the desired result of the intended action.
Principle of Choice: if you offer a choice to the user, ensure that the options are distinct. If all things are considered and a modal popup really is the right solution, do not provide more than two choices¹⁰. Highlight the option that is most likely to be the one that the user wants. Previously here i said highlight the least destructive option. If you follow the other principles listed here, any destruction should be reversible, so it is better to convenience the user if they obviously want to commit a destructive action. Do not use scary or patronising language in the dialogue, but make it clear what will happen.
If the modal is a warning about an action the user has requested one of the actions should confirm the action, and the other option should cancel the action. There is also a high chance you are ignoring the principle of forgiveness. Please try and design the modal out of your interface. The window’s close button should also cancel the action¹¹.
If you are following the principle of reactivity, there should never be any popups that weren’t the result of the user’s actions. But to make it explicit here: no popup should ever replace the cancel button with a remind me later button. The user should always be able to say no, and then the computer should back off.
Principle of Competency: do not patronise the user. Assume every user is a competent human, even if they don’t know how to use your software. Software isn’t natural and isn’t intuitive; we can try our best to make it so, but there will always be something that someone doesn’t understand, and they shouldn’t think that this is their fault. Something something the only intuitive interface is the nipple Disability isn’t incompetence. If a user can’t distinguish between colours or cannot use an input device, we should be making adjustments for that. Speaking a language that doesn’t use latin characters isn’t incompetence, and your software should support international scripts.
Don’t force tutorials or startup wizards on the user. Make use of the universal help features in the system. Have an extensive manual that is not necessary to consult, but is easy to consult when necessary, by considering every single thing someone might want to do with your software, and what they might call that.
For example, modifying the margin sizes might be described as making the margins bigger, shrinking the margins, or something else.
The computer should be a tool to make things easier for the user, not replace their cognitive ability. Consider the computer to be a bicycle for the mind. Know what humans are good at, and what computers are better at.
For example, computers are better at repeated tasks, tasks involving numbers, and remembering things.
Provide interfaces that let the user offload their weaknesses onto the computer.
Principle of Humility: humans make mistakes, so we the designers will make mistakes. we have a responsibility to carefully consider everything that could go wrong with our software, and come up with ways to inform the user about these issues, on their level. Only use jargon related to the domain of the application. Don’t tell the user there was a stack overflow if they’re using a word processor.
Only use relevant jargon, but don’t oversimplify. Remember the principle of competency.
when something goes wrong, don’t just tell the user things are broken. also tell the user what they can do next. tell them how to report the error to us. tell them how to restore their file, which should be in good shape.
Intuitive complex systems are made up of simple intuitive parts. A mechanical watch can be understood as a mechanical hierarchy which is ultimately just cogs turning cogs. Start out with the simplest possible design, and work from there. this is gall’s law¹². Note that simplest possible design refers to simplest possible for the user, not the programmer. it is the programmer and the system’s job to take on the burden of complexity for the user. Any solution will have a minimum amount of complexity, and it is your duty to take as much responsibility for that as possible¹³.
concept for a ui. the distinctive feature is the tabs being a part of the window manager. i came to value this a lot when i was heavily using chrome os; because most things are web pages, i found it frustrating when using linux applications, the os settings, and so on, as i could not interact with them in the same way as i could with the rest of the system.
the browser design inspiration is quite obvious. that empty bar between the navigation arrows and go button on every window is its url bar. redox os has the idea of everything being a url, not the worst idea ever
the change to this one was big, and for a long time i made only incremental changes to this design.
first of all, there’s now a top bar. there’s barely anything in it, but the happy button on the left would open a new empty window (equivalent to C-n in a browser).
it’s much more obvious which is the active window now (it’s the one on the left). there are a lot of drop shadows in the ui, which i like. at this point, i was assuming a screen size of about eight or nine inches, so i made most things a bit bigger so that usage would be more comfortable. i didn’t design the font, but i can’t remember which font it is.
notice the active tab now pops up, for extra clarity as to which it is.
each window has two resize nubs, at the top left and bottom right corner. this allows windows to be easily resized in any direction.
on the right side of the url bar there is a directory selector. this would probably open the file browser in the current tab (the file browser would simply be another url). i wanted to avoid a modal file browser, as that would make switching tabs whilst browsing files messier.
the scrollable part of the scrollbars are stippled now; the solid black in the previous design was too bright for me.
the close buttons for each tab look more buttony now. making buttons look like buttons was important to me as i don’t like the trend of making everything flat and uniform when it should be interactive.
the change here was not to have a different height for the active tab. i experimented with different visual distinctions, such as a heavier top border, removing the rounded corner, and as here putting the rounded corner on the opposite side.
i moved the global toolbar to the left. it still doesn’t have much use. also, the inactive scrollbar is no longer stippled, with the intent to make it look less active. that was probably unnecessary, as it’s not like the active window is subtle.
the toolbar is populated! global commands, such as copy, paste, and global help, are located here. copy and cut are greyed out because the user hasn’t selected anything for them to operate on.
the directory view in the window on the right can be toggled by the two left-most buttons below the url bar. there is a searchable list view, inspired by emacs’s tabulated-list-mode, and a spatial file view, not shown.
the window on the right is showing the settings directory. the “bun” format is short for bundle and each is a directory or file that can be run as a program. the idea is that there is nothing particularly special about the settings ui. all settings should be stored in settings.db, a database that any program can request access to keys and values from, so there should be no need to have to input eg. email server details for every email program. obviously, this could be abused (see: macos, android, dotfiles for a few examples) but that’s the idea at least.
windows now have titles, and an icon. the icon is a button that when clicked lets the user edit it. this icon would be shown in the window outline if it is iconified (see top right). i think i got the idea for iconifying windows like this from fvwm; regardless, i like it more than a taskbar.
the stipples for the active window don’t encroach on the tabs. i tried multiple things here, including horizontal lines (like early classic mac os), vertical lines, diagonal lines… every kind of lines to make it look less busy. this wasn’t a concrete decision.
i also added tab icons here, and went back to every tab having the same curved corner.
here the icon for the active window has been replaced with a button over the title. i wanted this idea to work, either icons or titles, but i wasn’t sure about either. it was suggested to me that i leave a default title and don’t let the user change it until it is iconified, which would work nicely with the rest of the ui but make the user have to think of a title as they minimise for fear of forgetting what the window held after they had iconified and wanted to get on with something else. for this reason, i didn’t continue that thread.
i find it interesting that i’d left the help button just below the copy/cut/paste buttons in the global toolbar. it would have made more sense for it to be at the other end, like it is in the windows, so it doesn’t move if other icons are added. then again, the idea is that icons aren’t added. in which case, that bar is mostly dead space. shrug
i got rid of the window titles again, and shrunk that bar back down. i’m not sure what my intention was here, perhaps i did take the advice i was given above. i’ve made the pointer a bit bigger now, this is a copy of the mac pointer
after this design, i left the mockups for a bit, and later tried to add colour to the design (see colour palettes). unfortunately i don’t have any of these attempts saved, but none were particularly good and i quickly decided that monochrome was a part of it now :)
this is a later version of the design, with a lower resolution screen and much simplified design:
the tabs are now sticking out of the window, as they do on haiku. i’m not totally convinced by this decision yet, but the reasoning is that it brings them closer to the top of the screen when a window is maximised. using kde after chrome os, i told my browser to use os window decorations which puts the familiar title bar across the top of the window. i wanted this for consistency, which i value highly. however, this was frustrating as i could no longer switch tabs by ramming the pointer upwards. instead i had to carefully position it so that i did not overshoot the target. see fitts’ law.
much of the 3d design has been removed. a lot of this was also to make implementing fitts’ law more intuitive. when there are shadows between a scrollbar and the screen edge, it looks like you cannot be touching the screen edge to use the scroll bar, for example. i want to make sure that every button still looks like a button though; they should all have borders.
there is no longer a url bar. i enjoy the spatial ui paradigm, and i think that a url bar is too confusing to use in conjunction with this. the back and forward buttons are removed because without a url bar they make less sense. i need to further explore how to integrate tabs into the spatial paradigm.
there is no longer a new tab button. this is also due to the spatial paradigm. the new tab button would open a particular file or launcher page, i hadn’t decided which yet. but i would rather the target is created and then opened via the file system. once again, this is a tentative concept.
the toolbar for each window is on the left. this is fitts’ law again. i can ram the pointer to the left to find the action i want.
the global toolbar is at the bottom. …fitts’ law :)
the scroll bars are always shown. i don’t like ui items appearing and disappearing. part of this is because of the realignment jump that happens if the content becomes bigger than the viewport and the scrollbar appears. part of this is so that the user doesn’t get in the bad habit of selecting text by ramming the pointer to the edge of the screen. note that this is not a bad habit in itself, but i consider it an issue if it sometimes works and sometimes doesn’t.
i’ve removed the searchable list view of files, instead having just a spatial icon view.
there is a single button in the top left of each window to iconify it and move it. i’m not sure how i feel about this yet, as it’s not particularly discoverable design.
the resize nubs have been replaced with a single resize square. this makes the window look less cluttered, and works better with the redesigned scrollbars, at the expense of some convenience; now you cannot resize a window in any direction, but only to the right and bottom side. the window must be moved from the top left to manipulate those positions. this is somewhat consistent with how other operating systems are most commonly used.
the far right global toolbar house button is supposed to represent showing the desktop. this icon must be changed as it does not make much sense in this metaphor to me.
i have added little curves to the corners of the screen. i think curved screen are cool.
the maximise window button is gone. windows can now only be maximised by dragging them to the top (or left or right for a half tile) of the screen. perhaps i will change this. one thing i know is that i am not keen on the idea of a special maximised state. that is, how many window managers will remove extra window chrome when in full screen. the window should always look the same, just differently sized.
currently there is a 1px bar of whitespace below the tab bar but above the window content. i like this, because it makes it clear that the tab is attached to that window. however i also think it looks a little strange. i will experiment with other ways to keep the functionality while improving the look.
didn’t take long. a new interface, without floating windows. this was heavily inspired by project oberon and plan 9’s acme.
you may notice that the help text refers to celeste. i think i like the name celeste more than harrison, so watch this space if these pages move back to celeste names.
the mascot can still be called harrison. you might not notice, because they don’t appear in any previous screenshot, but the ballon now has a planet ring around it, rather than, vertical lines.
now onto the interface. we have a bottom bar, which will be populated with global commands (currently it just has help). commands are no longer underlined, we’ll see if i stay with that but for now it’s what we’ve got.
the display is split into columns, which can be split into windows. the titlebar has the window name/type on the right, and relevant commands on the left. i’m not sure exactly what to call the window name, because i don’t necessarily want it to be unique. at the moment it describes the type of window.
the titlebar has two icons; the inverted triangle allows you to “collapse” a window so that only the titlebar is shown, to save space. the circle allows you to close a window. there isn’t a way to move windows around, which needs to be rectified. when a window is collapsed, the triangle will point to the right.
the top left window is a text view, which can also hold images. the bottom left window is a wave view. the idea is that another window will be able to make use of this content, which is exposed as a wave with the parameters defined (excuse my terrible drawing of a wave). this window is also predominantly text, which can be edited. the paramters can be modified in real time which will change what the visualisation looks like.
note that period and speed are defined using the above variables; period = 1/frequency, speed = wavelength/period = wavelength*frequency. changing one of the first variables will change the period or speed respectively. if you change period or speed, the others should update too, in whatever way makes the most sense. that is, changing the period should change the frequency, and changing the speed should change one of period, wavelength, and frequency. in the latter case, i’m uncertain which would be the most expected behaviour.
there should be a way to manipulate the numbers shown without having to type them. for example, by dragging on them. i haven’t worked out exactly how that will work yet.
the window on the top right is the document view. it has a query field in the title bar, where the user can have real time search. files are stored as hashes, the name is just metadata. there is no hierarchy, but potentially tags will be used to provide further organisation.
the bottom right window is a shell. i also need to expand my ideas for a learnable command line, and change the name from “shell” to something else. this is the default type of window, which appears when a new window is created. it will act similarly to a familiar shell, albeit more like a plan 9 shell, with no vt100 graphical hacks.
the next iteration on this newer design. i have brought back the whole bar across the top; this is almost exclusively aesthetic, because it looks better with the buttons int he corners. though it does also make the window a rectangle, which are easier to draw and make calculations about.
there are two buttons in the tab bar. the one on the left is to move the window around, and the one on the right is to iconify the window. though they look embedded within the window, clicks to the edge of the bar will activate them. whether the user picks up in this deserves further exploration.
the toolbar is moved across the top, rather than down the side. i would prefer for it to be on the side so as to make the click targets larger, but i wanted to make it text. this is part of my intention to remove tooltips from the interface. all clickable text is underlined, like a url.
i haven’t changed the file manager dialogue in this design, but i am planning to overhaul that. i will likely go back to a filterable file list as seen in earlier iterations.
the tabs no longer have drop shadows. it is clear enough which is active from the open bottom, which is more obvious now that the toolbar is horizontal.
the bottom left displays contextual help. i haven’t worked out how this will get cleared, or if any of it should have user interaction. it is inspired by emacs’s echo area, in particular the functionality that a graphical emacs has when display-tooltips is set to nil—that is, tooltip information is displayed here. this is a better solution than tooltips, because more information can be shown, and because each button is text, the tooltip can offer further explanation (such as “make the selected text bold”) rather than acting as a key for an obscure icon.
note that “new file” is a single button, despite having a space; because i want these buttons to be as transparent as possible, i want the user to be able to edit this bar. i’m not sure how this will work to distinguish “new file” from two buttons, “new” and “file”, except to hope that developers don’t name anything as ambiguously as “new”. but that is not a good thing to hope for. if this sounds familiar, i took the idea from acme. it was a feature in a much older version of celeste i worked on for a while, and actually started implementing (gasp), called alicia.
the drop shadows on windows have gone. for a while i’ve been intending for harrison to be focus-follows-mouse, which is impossible to show in a screenshot. but i realised that this meant that i didn’t need drop shadows, as the mouse makes that clear, and drop shadows provide unattractive flickering when moving across windows.
nothing is visible in this design, but i’m very tempted to move towards a more tiled window paradigm. i think there are some significant benefits to it, especially if you move away from the neccessity of being entirely keyboard controlled. so stay tuned for that i guess.
following feedback, i inverted the scrollbar colours. i think i prefer this considerably.
well, that redesign didn’t take long, and it didn’t last long. thinking long and hard about what i wanted out of celeste, i realised i’d been sort of neglecting fun. and floating windows are simply more fun.
also, the way i want a workflow to go, floating windows might actually work better than a tiling grid. i’m happy with this for the moment, we’ll see what happens.
obviously the revert to floating windows is a big change, but there is a lot more that’s changed too.
the windows don’t have curves in the corners. sad, but i like the clean square look for now.
the close button in the title bar is now a word. this is orthogonal with every other function being a word (except the scroll buttons; i could’t make that look good). the only option in the toolbar is currently close. i’m thinking about adding help, or minimise of some description.
notably there are no tabs, unlike every other iteration with floating windows. again, we’ll see about this because they were kind of one of the things which even made me start thinking about this.
there are slashes to separate commands in the tool bar. i think this is more legible, but i’m not certain on this. i’ve also brought back the underlines on function words.
i’ve made the scrollbars slightly wider. i did this before changing the close button, and actually what made me think oh that should be text was that the different widths looked kind of ugly. i kept them wider anyway. i also changed the dots on them to vertical lines, so that the scrubber was symmetrical whatever size the bar (i didn’t like the look of the dots touching the bottom line, or having an extra gap).
command words in the shell are underlined. clicking on them opens the definition inspector.
the inspection tools are new, i’ve put them on to partly highlight my thinking about the underlying system. obviously the idea is that it’s a virtual machine of some description, and smalltalk is a big inspiration. but i’m not so taken with the objecty nature of smalltalk, so i’m thinking about ways to make forth more introspective. this is the most obvious realisation of that, making word definitions viewable. the words screen is akin to smalltalk’s class browser. i’ve put “docstrings” next to word names, which are just comments in the definition.
note that the language is a forth-like, and inspired by forth, but doesn’t follow all of forth’s conventions. specifically here, defining words with colons has been replaced with words, because i like words more than symbols. there’s more to figure out here.
windows have a white border around the black outside border, because i thought it looked cleaner.
i’ve changed the mouse from the classic pointer arrow to a little pointing finger! the shape has been shamelessly stolen from the left editor for uxn.