@@ -1,32 +1,20 @@
5−preview: In 2017, we're ready to start making the damn thing useful.
1+--- date: ~2017.1.30 type: post title: Urbit in 2017 preview: In 2017, we're ready to start making the damn thing useful. author: Curtis Yarvin + Galen Wolfe-Pauly layout: urbit,post navmode: navbar navdpad: false navselect: blog navpath: / navhome: / navclass: urbit --- <br /><br />
6−author: Curtis Yarvin + Galen Wolfe-Pauly
17− > TLDR: A nontrivially useful Urbit demands nontrivial work in two areas: systems maturity and user experience. We've actually done quite a bit of this work already, so we're pretty excited.
3+ > TLDR: a real Urbit is a Urbit that does real work. This means nontrivial progress in two areas: systems maturity and user experience. In 2H 2016 we cleaned out most of the worst holes in Arvo and vere, and totally reconceived the user experience. The new Urbit feels like an MVP and we can't wait to ship it.
19−In 2013 Urbit was intriguing. By 2015 it had become interesting. In 2016 it was actually exciting (if not always in a good way!). In 2017, we're ready to start making the damn thing useful. Or, at the very least, fun.
5+In 2013 Urbit was intriguing. By 2015 it had become interesting. In 2016 it was actually exciting (if not always in a good way!). In 2017, we're actually planning to make the darn thing useful. (For certain values of the word "useful.")
21−Our `cc-release` stability upgrade is code-complete and in testing. This infrastructure upgrade makes it possible for us to finally think seriously about the user experience of Urbit. Our all-new UX is both a social network and aggregator, powered by the world's cutest command line. It isn't built yet, but we're finally confident that it can be built and remain stable.
7+Our `cc-release` stability upgrade (mainly affecting the OS layer `arvo` and the interpreter `vere`) is roughly code-complete and being tested into existence. Once it exists and is stable, it can actually be documented -- often, for the first time.
23−System software is boring (at least when done right). So we’ll start with the UI. (Or UX?) Urbit is certainly an *experience*, and can't help but be *designed*.
9+And `cc-release` is our first release really designed so that neither your ship, nor the whole network, can actually sink. The Urbit network had zero unplanned, and one planned, breach (network flag day) in 2H 2016. The last planned breach, the `cc-release` update, is planned for 1H 2017.
25−Galen will cover the design, and Curtis will show up later to talk about infrastructure.
11+With the infrastructure converging, we can finally think seriously about the user experience of Urbit. What we're imagining is a small-scale social network and command-line API aggregator. It's just screenshots right now, but we're confident that we can build it and make it work.
27−## Design
13+System software is boring (at least when done right). So let's start with the user experience.
15+## Design: the product user experience
29−Galen is the person around here who thinks about design, ‘product’ and things like that. Galen went to architecture school. He talks like it. We’ll be getting more specific about what this product will look like in future posts. For now, we recorded Galen secretly and came away with these notes:
17+Galen Wolfe-Pauly is Tlon's CEO and Urbit's interaction designer. Galen went to architecture school. He talks like it. We recorded him secretly and came away with these notes:
31<img src="https://media.urbit.org/site/sketch-1.png" class="full-width inline" />
19<img src="https://media.urbit.org/site/sketch-1.png" class="full-width inline" />
@@ -36,63 +24,59 @@ Galen is the person around here who thinks about design, ‘product’ and thing
37<img src="https://media.urbit.org/site/sketch-2.png" class="full-width inline" />
25<img src="https://media.urbit.org/site/sketch-2.png" class="full-width inline" />
39−- Urbit has to be just as usable as any widely used app in 2017. For a personal server, the usability bar can't be Unix. A Unix server is an industrial tool. An industrial tool isn’t a consumer product. You can attach a blade to the end of a drill and use it as a blender, but it’s not quite as nice as the Vitamix.
27+- Urbit has to be just as usable as any widely used app in 2017. For a personal server, the usability bar can't be Unix. A Unix server is an industrial tool. An industrial tool can't be a consumer product. You can attach a blade to the end of a drill and use it as a blender, but it's not a Vitamix.
41- What is an app, anyway? It's *shared computing*. Everyone's data is one data structure, in one program, on one server, owned by one corporation. With *one* UI for everyone to do *one* thing.
29- What is an app, anyway? It's *shared computing*. Everyone's data is one data structure, in one program, on one server, owned by one corporation. With *one* UI for everyone to do *one* thing.
43−- There isn't one big corporation that writes *all* the code, so everyone's lives are spread across a bunch of different apps. In turn, you have to track all these silly little accounts, suffer through separate ‘experience’-es and figure out how to move your data around.
31+- But there isn't one big corporation that writes *all* the code. Everyone's lives are spread across a bunch of different apps. Every app solves the ownership problem separately.
45−- And there’s no alternative. The cloud computing services we depend on aren’t accessible through some other means.
47−- The phrase ‘general-purpose computing’ sounds scary, but it shouldn’t be. ‘Computing’ doesn’t necessarily mean writing code. As far as I’m concerned we’re computing while we’re browsing Facebook. Or talking to Alexa.
49−- We use computers to talk to people, store data, send money, share and collaborate on documents, and so on. Not what you would have used your Apple II for, but computing nonetheless.
33+- So the whole user experience of using Web apps involves tracking all these silly little accounts, learning each and every user experience, and glaring impotently at each little piece of data trapped in a different silo.
51−- So what’s a general-purpose computer today? The closest thing e can point to is WeChat. It’s like a bad copy of a mature Urbit: it’s a general-purpose personal server that’s really simple to use.
35+- Even your Google account doesn't feel like one thing. Whatever your Google Docs are, it's not a bunch of document files on your Google Drive. All the resources of Google can't make their Borg backend feel like one computer which belongs to you.
37+- The phrase 'general-purpose computing' sounds scary, but it shouldn't be. 'Computing' doesn't mean writing code. We're computing when we browse Facebook or talk to Alexa.
39+- Your personal server will be solving the same problems today's whole ecosystem of network apps solves, just all in one place that belongs to you.
53−- Everyone has probably heard of WeChat, but if you don’t know much about it you should really watch [this NYT video](https://www.nytimes.com/video/technology/100000004574648/china-internet-wechat.html).
41+- The closest thing to a general-purpose personal server today is probably the Chinese service WeChat. If you don't know much about WeChat, you should really watch [this NYT video](https://www.nytimes.com/video/technology/100000004574648/china-internet-wechat.html).
55−- From a distance WeChat is great. Everyone in China loves the one-app, one-identity, all-my-own-stuff user experience. It’s clearly better than being forced to switch apps constantly.
43+- From a distance WeChat is great. Everyone in China loves the one-app, one-identity, all-my-own-stuff user experience. It's clearly better than being forced to switch apps constantly.
57−- But WeChat is just another giant shared-computing service. It's made out of the usual 2010s server stack mess. The visual and interaction design looks pretty dated. And the infrastructure is just the normal 2010s server stack mess. We can learn a lot from the idea of WeChat, but not from the implementation.
45+- But WeChat is just another giant shared-computing service. It's made out of the usual 2010s server stack mess. The visual and interaction design looks pretty dated. WeChat tells us that users want one experience, but not much more than that.
59<img src="https://media.urbit.org/site/sketch-3.png" class="full-width inline" />
47<img src="https://media.urbit.org/site/sketch-3.png" class="full-width inline" />
61−- Shared computing may have its problems, but at least it has an ethos. Almost anyone can copy and paste their way to an app on the app store.
49+- To paraphrase Walter Sobchak: say what you want about the tenets of shared computing, but at least it's an ethos. We know how to build very good special-purpose user experiences. What's the conventional UI for a general-purpose personal server? It doesn't exist.
63−- Urbit isn’t an app though: it’s a personal server. What's the standard UI for a personal server? It doesn’t exist.
65−- Like a web app, your urbit runs in a data center. You log into it with your browser. Other than that, where do you even start? A `bash` prompt isn’t what we’re looking for.
67−- But wait, is the idea of a command line bad UI? Or is the Unix command line just bad UI? We now know ordinary people can use command lines: they use chatbots.
51+- For most users, your urbit runs in a data center (like a web app). You log into it with your browser (like a web app). Other than that, where do you even start? A `bash` prompt isn't what we're looking for.
69−- The apps that we use all do quite a lot to abstract away the complexity of the command line. Instead of a CLI we have something like a 'profile'.
53+- But wait, is the idea of a command line bad UI? Or is the Unix command line just bad UI? We know ordinary people can use command lines. They use chatbots. Long ago, they used MS-DOS.
71−- Your Urbit is a real computer. It would be a waste to abstract this reality away. But, if we can't succeed in making that reality simple enough for an ordinary person to manage — we have failed. iOS is almost a real computer. WeChat is almost a real computer.
55+- Today's computing user experiences, the PC and its mobile cousin, rejected the command line. This made computing easy enough, at the cost of hiding much of its creative power.
57+- The power of a general-purpose server which can command not only local applications, but also network services, is at a whole new level. We don't think any visual metaphor or 2D control panel can do it justice.
73−- We have to get all the way there: design a complete system that an ordinary person can control on their own.
59+- We need to bring the full power of the machine to the user, without breaking their trust that the machine is on their side. We can't let the user get lost or break the system. It has to feel safe and simple to explore its furthest reaches.
75−- Perhaps it's an antiquated view, but we do still believe that computers have the potential to be powerful creative tools.
77−- The most important bottleneck in achieving this goal is winning the trust of the user. The user can't get lost or break the system, nor can they be prevented from exploring its furthest reaches.
79<img src="https://media.urbit.org/site/sketch-4.png" class="full-width inline" />
61<img src="https://media.urbit.org/site/sketch-4.png" class="full-width inline" />
81- As Neal Stephenson [tells us](http://cristal.inria.fr/~weis/info/commandline.html), the command line is the natural UI for any computer. It's especially the natural UI for a *network* computer, like a personal server. A command line scales way better than a GUI to a large selection of actions. And a network computer can do almost infinitely many things.
63- As Neal Stephenson [tells us](http://cristal.inria.fr/~weis/info/commandline.html), the command line is the natural UI for any computer. It's especially the natural UI for a *network* computer, like a personal server. A command line scales way better than a GUI to a large selection of actions. And a network computer can do almost infinitely many things.
83−- We tried to put a simplified "for dummies" GUI on top of our real OS, and it was awful. It's like a bad Linux desktop GUI. You feel instantly that you've got a choice between something limited and lame, and something mysterious and scary. So we threw those designs out, in search of something better.
65+- When we've tried to put a simplified "for dummies" GUI on top of Urbit, it's just awful. It's like a bad Linux desktop GUI. You feel instantly that you've got a choice between something limited and lame, and something mysterious and scary. So we threw those designs out, in search of something better.
85- The true command line is generally thought of as something mysterious and scary. Somewhere that you can do things to irreparably damage your computer. It's powerful, but also dangerous.
67- The true command line is generally thought of as something mysterious and scary. Somewhere that you can do things to irreparably damage your computer. It's powerful, but also dangerous.
87−- This tradeoff — between control and safety — seems wrong. Perhaps the command line is actually just another artifact of 70s computing. The core idea is good, but the design needs to be updated dramatically.
69+- This tradeoff — between control and safety — is false. The unfriendly command line is actually just another artifact of 70s computing, when nobody worked on UX.
89−- `bash` is a bad UX because there's no easy way to control its power. It's also quite difficult to learn how to use. At the other end of the spectrum is the Chatbot. Chatbots are weak because they don't scale well to any problem that isn't trivial.
71+- `bash` is a bad UX because there's no easy way to control its power, or learn all the things it can do, or separate its power to do dangerous things from its power to do safe ones.
73+- At the other end of the spectrum is the chatbot, which is a bad UX because it's hard to make it much more than a toy. Like so many innovations, chatbots happened by accident. It's just a way to connect an input string to network services. But the natural-language metaphor of "chat" is confining. It doesn't scale well to any problem that isn't trivial.
91−- So what does a great command line look like? It's syntactic, not free-form. It can't be a constant test of your ability to memorize the phonebook. It's also not tethered to a piece of industrial equipment.
75+- What does a great command line look like? It should have a strict syntax, not try to guess what you mean. But it can't be a constant test of your ability to memorize the phonebook.
93<img src="https://media.urbit.org/site/sketch-6.png" class="full-width inline" />
77<img src="https://media.urbit.org/site/sketch-6.png" class="full-width inline" />
95−- Urbit already has the beginnings of a great command line. We parse your input with an actual grammar and correct errors (or erase them, at least) as you type.
79+- Urbit already has the beginnings of a great command line. We parse your input with an actual grammar and correct errors as you type. You can't even press return on an invalid command.
97- What's missing is help. A great command line needs to reach out and hug you in every way it can. It needs to assume you don't know anything at all about the system. It's there for you to solve your problems, but also to help you explore.
81- What's missing is help. A great command line needs to reach out and hug you in every way it can. It needs to assume you don't know anything at all about the system. It's there for you to solve your problems, but also to help you explore.
@@ -100,19 +84,17 @@ Galen is the person around here who thinks about design, ‘product’ and thing
101- It's a lot easier for Urbit because we're designing the system from scratch. From a technical standpoint, all we have to do is add contextual help to our existing parser framework. An extended rule can parse a string, or tell the user what it wants to parse. In simple terms: we have to make the `:dojo` (our shell) much friendlier.
85- It's a lot easier for Urbit because we're designing the system from scratch. From a technical standpoint, all we have to do is add contextual help to our existing parser framework. An extended rule can parse a string, or tell the user what it wants to parse. In simple terms: we have to make the `:dojo` (our shell) much friendlier.
103−- The `:dojo` is quite powerful, and exposes a lot of surface area for people to build small modules and programs. And, since we have a global revision-controlled filesystem, it’s pretty easy to share that code. The problem is, it’s just way too difficult to figure out how this system works.
105−- It’s important to note that we’re not talking about ‘developers’ trying to tackle well known engineering problems. Urbit is meant to make building things on the web *fun* again. Welding a giant single-purpose app on top would me a mistake primarily because it’s inevitably kind of narrow and boring.
107−<img src="https://media.urbit.org/site/sketch-5.png" class="full-width inline" />
109- The `:dojo` shell is built around the concept of a *generator*, a program that builds a noun. The idea is that how you build the noun is orthogonal to what you do with it. You could print it, send it as a command, etc. There are several kinds of generators -- simple scripts, prompting dialogs, HTTP scrapers, etc.
87- The `:dojo` shell is built around the concept of a *generator*, a program that builds a noun. The idea is that how you build the noun is orthogonal to what you do with it. You could print it, send it as a command, etc. There are several kinds of generators -- simple scripts, prompting dialogs, HTTP scrapers, etc.
111- A generator is initialized with command-line arguments and options, in the classic Unix style (except typed). In the classic Unix style, Urbit at present provides no help at all in constructing a command line. You just have to know.
89- A generator is initialized with command-line arguments and options, in the classic Unix style (except typed). In the classic Unix style, Urbit at present provides no help at all in constructing a command line. You just have to know.
113−- The new `:dojo` will let the user build a command line with a helpful prompting dialog. Call it a meta-generator, a generator for a generator command. If you know the command, you can just type it. If not, you step through a simple form to build the command. The `:dojo` shows you all your options, explains them and helps you complete them.
91+- How should it actually work? Let's say you're trying to put Urbit in control of your Twitter feed. That means you're creating a Twitter gateway on Urbit, which you can control with a `|twitter` command.
93+- Before you type a character, Urbit offers you `|` (any command with side effects). (You could also add a `!` prefix, which is like `sudo` -- it lets you do something dangerous.) Once you type `|`, you can page through a list of commands. Once you type `|t`, that list is much shorter. Once it can tab complete to `|twitter`, it prompts you with that.
95+- And once you get to `|twitter`, you're in a "meta-generator" that's helping you build the correct command line. At least in a browser, you'll be stepping through a form with rich entry. But the command line will show you the text of the command you're building, so next time you can just type it.
115−- Building a command is just a case of data entry. In a command-line world, data entry is always serial. You answer questions serially, one at a time.
97+- Building a command is just a case of data entry. In a command-line world, data entry is always serial. You answer questions serially, one at a time. The only navigation is forward and back.
117- A great Urbit console also has to be accessible both from a browser and a Unix terminal. That means a prompt needs to tell the console if it could be a radio button, even though a terminal can't have a radio button. We'll improve the interactivity of our terminal a little, but we're not rewriting Lynx.
99- A great Urbit console also has to be accessible both from a browser and a Unix terminal. That means a prompt needs to tell the console if it could be a radio button, even though a terminal can't have a radio button. We'll improve the interactivity of our terminal a little, but we're not rewriting Lynx.
@@ -122,11 +104,13 @@ Galen is the person around here who thinks about design, ‘product’ and thing
123- A great command line alone is not all that Urbit needs. But it feels like the right central paradigm for interacting with your Urbit. We'll get into the specifics in a future post.
105- A great command line alone is not all that Urbit needs. But it feels like the right central paradigm for interacting with your Urbit. We'll get into the specifics in a future post.
125−## Stability, maturity, performance and documentation
107+<img src="https://media.urbit.org/site/sketch-5.png" class="full-width inline" />
127−Okay, here's Curtis:
109+## Infrastructure: stability, maturity, performance, documentation:
111+We dragged Curtis, whose hide has turned completely white like a cave fish, from his coding hole to stammer out this update:
129−We're actually doing pretty well on this. Despite there being all kinds of unacceptably broken things about Urbit 2016, the network has actually stayed up since August, and we haven't had an unintentional continuity breach since June.
113+We're actually doing pretty well on the infar. Despite there being all kinds of unacceptably broken things about Urbit 2016, the network has actually stayed up since August, and we haven't had an unintentional continuity breach since June.
131Of course, it helps that we don't ask anyone to *use* Urbit in earnest. And ships still do sink. Since an urbit is an identity, sinking your planet is a horrendous experience. You'll never bond with your second planet the way you did with your first -- never mind any *data* you may have lost.
115Of course, it helps that we don't ask anyone to *use* Urbit in earnest. And ships still do sink. Since an urbit is an identity, sinking your planet is a horrendous experience. You'll never bond with your second planet the way you did with your first -- never mind any *data* you may have lost.
@@ -142,7 +126,7 @@ The console and the dojo need some work to make our user experience real. One w
143There's also a bunch of Unix-level work to do, mainly in converting the old "single-player mode" console-bound Urbit into a real system service. Urbit works better as a daemon which runs one or more worker processes, and talks to client consoles over a Unix socket. A real architecture actually makes it practical for star owners to host the planets they issue, for example.
127There's also a bunch of Unix-level work to do, mainly in converting the old "single-player mode" console-bound Urbit into a real system service. Urbit works better as a daemon which runs one or more worker processes, and talks to client consoles over a Unix socket. A real architecture actually makes it practical for star owners to host the planets they issue, for example.
145−Finally, because we never forget the wisdom of the sages, our last act before asking people to use Urbit will be the long awaited performance [war]. The new event system now at least releases outgoing events before the input queue is clear! You never know what optimization will achieve before you make a serious effort, but I expect great things from the [war].
129+Finally, because we never forget the wisdom of the sages, our last act before asking people to use Urbit will be the long awaited performance crusade. The new event system now at least releases outgoing events before the input queue is clear! You never know what optimization will achieve before you make a serious effort, but I don't see any reason we can't carve out a new empire of speed in the savage, uncharted east.
147We haven't touched the documentation since the first half of 2016. As always, maturity has to come before documentation. Premature documentation is almost as dangerous as premature optimization.
131We haven't touched the documentation since the first half of 2016. As always, maturity has to come before documentation. Premature documentation is almost as dangerous as premature optimization.
@@ -158,12 +142,18 @@ Anyone who contributes at this point deserves extreme praise for the ability to
159## Next crowdsale
143## Next crowdsale
161−We'll do another crowdsale in the spring. We understand that the last sale left a lot of people unable to participate — and our first priority is making sure those who are excited about Urbit can own some real estate. We’ll announce our plans on how this might happen soon. If you’re interested, make sure you’re on our [mailing list]().
145+We'll do another crowdsale in the spring. We understand that the last sale left a lot of people unable to participate — and our first priority is making sure those who are excited about Urbit can own some real estate. We'll announce our plans on how this might happen soon. If you're interested, make sure you're on our [mailing list]().
147+## Contribution prizes
149+We're still thinking about the right way to award Urbit real estate to outside contributors. Especially after the crowdsale, it really has to feel 100% fair. But it can't be in any way, whether legally or emotionally, a form of compensation. We can't afford to kill the fun.
151+It doesn't feel right to do this at all when the documentation is completely inadequate, because it's not fair to people who don't have the time to reverse engineer. But we're thinking hard about this issue. Ideally others will think as well, and we can work it out in a big conversation.
163## Future updates
153## Future updates
165−We’re going to change up the way we write these updates a bit. Obviously, we slipped a few months in getting this one out. Longer updates can be great, but we need to spend as much time as possible building stuff and writing code.
155+We know you love these opinionated, literary state-of-the-urbit updates. We love writing them. But we obsess over them too long and they take too long to write. Urbit's ultimate success depends almost entirely on the code.
167−Going forward we’re going to switch to commit-message style updates on a monthly basis, with longer updates arriving sporadically. Maker DAO does a great job of these shorter updates ([here](https://blog.makerdao.com/2016/12/14/maker-update-925/) is an example).
157+Going forward we're going to switch to commit-message style updates on a monthly basis, with longer updates arriving sporadically. Maker DAO does a great job of these shorter updates ([here](https://blog.makerdao.com/2016/12/14/maker-update-925/) is an example).
169If you're ever curious to check in or hear what's going on, don't hesitate to get in touch. You can always chat with us on [urbit.org/stream](https://urbit.org/stream), or by booting your own Urbit. [Twitter](https://twitter.com/urbit_) or email ([urbit@urbit.org](mailto:urbit@urbit.org)) are also perfectly fine.
159If you're ever curious to check in or hear what's going on, don't hesitate to get in touch. You can always chat with us on [urbit.org/stream](https://urbit.org/stream), or by booting your own Urbit. [Twitter](https://twitter.com/urbit_) or email ([urbit@urbit.org](mailto:urbit@urbit.org)) are also perfectly fine.