Softspace harnesses spatial computing to help thinkers and makers better see, understand, and develop the ideas that form the heart of their creative projects.
This is the second in a series of prototypes weβre releasing as a part of our open development process to build the augmented reality version of Softspace.
Help us invent a powerful new kind of tool for thought by π§π½βπ¬ trying these prototypes, π¦ following us on Twitter, and π―ββοΈ joining the Softspace Discord.
Prototype02 is all about writing.
Specifically, I wanted to prove that it's possible to write comfortably, productively, and enjoyably inside a passthrough augmented reality app.
Motivation
Writing might not seem like the highest-priority task for a spatial computing app. In fact, the idea of writing while wearing a headset might strike a lot of people as unnecessaryβor silly!
After all, spatial computingβs great appeal is in 3D content, right? All the cool stuff you see in the Oculus ads involve zooming through outer space or tearing zombies apart with your bare hands. Isnβt using this tech to work with text a huge waste of its unique potential?
Also, thereβs nothing terribly broken about existing ways of writing. Quite the contrary: a modern laptop running a well-designed text editor is a highly optimized writing machine. It epitomizes a near-universally-embraced paradigm. Why mess with success?
The thing is: the ability to work with text is critical for almost any serious productivity workflowβeven ones centered on 3D content. From object names, to short annotations, to entire paragraphs, text is everywhere. Natural written language still plays an irreplaceable role in representing many of the ideas that we need to work with, regardless of domain or medium.
I wanted to tackle writing head-on and de-risk it before prototyping other aspects of SoftspaceAR. This isnβt to say that the writing experience needs to be perfectly on par with that of your MacBook (although I made some interesting discoveries about the advantages of writing in a headset; more on that below). It just needs feel good, and not get in your way when you want to do it.
I decided on a fast and dirty metric of success: Could I write for one solid hour in the prototype?
I initially thought about setting additional qualifying criteria, like word count, or some vague notion of writing quality. But after trying the first few development builds, I realized that the one-hour criterion implicitly covers a lot. Itβs painful to write for that long if you feel like youβre going too slowly, or that youβre producing garbage.
Just to be clear: I donβt expect that people will really sit and write for hours on end in SoftspaceAR. Itβs more likely that you would write shorter bits of text, sporadically, while working with other content. But Iβm using βwrite for a solid hourβ as a close proxy for βgood for real writingβ.
Mechanics
To write, you need something to write with, and something to write on.
The input part was an easy decision: Iβve tried many, many virtual keyboards, and none are good enough for serious writing. SoftspaceAR will simply require a physical (wireless) keyboard.
As for the writing surface, my goal was to keep it familiar. A naive user coming from a desktop text-editor should be able to pick this up and go. So I went with a simple fixed-width text box that expands downward to accommodate new content, like weβve all seen a million times before.
I discovered how much weβve come to take certain textual interactions for granted. I never thought much about these, but it sucks when theyβre not available. Some examples: clicking on the text to position the caret (the flashing vertical line that tells you where youβre typing); click-dragging to select text; copy-paste; moving the caret around with the arrow keys.
Happily, most of these interactions are already beautifully implemented in the text-rendering package I use, TextMesh Pro for Unity:
Finally, the one βradicalβ design decision I made was to make the paragraph the object primitive (as opposed to the page). This is inspired by the way that paragraphs work in Notion and LogSeq, and I find this way of structuring documents much better aligned with how I think and work than one where documents are treated as bags of words with occasional line breaks. I wanted to test this out because I think this is how SoftspaceAR is going to treat text objects.
So in Prototype02, hitting the return key creates a whole new text box:
There are still some holes in the UI. For example, you can't use the arrow keys to navigate between paragraphs. I decided not to plug these because they don't prevent a user from achieving the stated goal of the prototype: letting you write comfortably, productively, and enjoyably for one hour.
How do I know?
Because the first draft of this piece was written in an hour in Prototype02:
Discoveries
Early builds had transparent backings for the text objects, because I assumed that it would be more comfortable being able to see things in the physical space around you even if they were behind a text box. In fact, I found it very hard to focus on writing when I could see through the text boxβI guess my brain was overloaded by the conflicting visual information.
Once I solve that issue by making the backings opaque, I was surprised to find how enjoyable it is to write in passthrough AR. I was expecting to have to force myself to switch from writing on the laptop to writing in the headset, but I actually found myself looking forward to settling down in front of a floating text box and just getting my thoughts out in front of me.
One of the biggest improvements in my ability to write well in Prototype02 didnβt come from the design or code at all. I canβt really touch-type, and on a laptop I look at the keyboard all the time. The resolution on the Quest 2βs passthrough is too low to easily make out the letters on the keys, which basically forced me to figure out which letters are under which fingers. The first few days were really painful because my typing was so slow and error-prone, but by the time I made the above time-lapse video I was typing away like a champ. Crappy passthrough =
bugfeature!
Takeaways
Prototype02 met my criterion for success. It took me just over an hour of writing in the headset to get the first draft of this piece (~850 words). It took me another two hours of editing in Notion to get the final draft (~1200 words + images).
It was really helpful to explicitly define the criterion for success of the Prototype before I set out to build it, because it helped me stay focused and know when to stop. For the next prototype, Iβll consider publishing the criterion for success even before building anything, as a way of βpre-registeringβ the experiment publicly.
It took four weeks between the releases of Prototype01 and Protoype02. My goal is to get this down to 2-3 weeks so I can cover lots more ground before starting to pull the various threads together into an MVP. Prototype01 took two months start-to-finish, and each prototype lays groundwork that speeds up the next one, so the general trend is encouraging π«.
Thanks so much for reading!
βYiliu