Subscribe to theo
Subscribe to theo
<100 subscribers
<100 subscribers
Back in October 2018 I started a note with the title "The Web is Dead" while being part of the startup studio called eFounders. I was working on what is now Multis (crypto stuff) and also spending time surrounded by other startups building products on the web. Serendipity was ubiquitous. Especially when I'd go for a coffee walk around the 9th arrondissement with my wordsmith friend Jonathan. I probably started the note after an intense debate about Intercom (more on that later).
This article comes after 10+ years of working for the world wide web, from web1 to web2.0 to web3. It took me 3 years to connect the dots, after building decentralized applications and also, surprisingly, chatbots. I hope you find something interesting in it (or actually not, because contrarian is better).
(tl;dr)
How many times have you opened a tab and performed the exact same steps you performed one minute, one hour or one day ago? Your honest answer: all the time. You just went to Airbnb and entered the same city, the same dates as you did yesterday... or that Google search that you do again and again... or this floor price on OpenSea you keep checking... This surely feels sub-optimal.
But how much more frustrating is it having to learn to navigate every new website you visit. You'll say that's the beauty of the diversity of the web. But the reality is that it creates lots of inefficiencies. The proof, you ask? Websites keep copying each other in an ironical attempt at being “intuitive”.
There are too many things on a page, too many buttons, links and most of all too much real estate: the surface is extremely large for a poor little cursor or eyeball. Adding on top that the sequence of the actions matters: “first this, then that and -oh- a submenu appears”.
Users come with intents, they want to do something. The way to collect these intents is with the “form primitive”: that meta-category encompassing elements like inputs, buttons, checkboxes, links which allow users to send data to a web application runtime in order to change the state of the world (ex: save a record in database, navigate to a new page).
Now, I put it to you that since the web was created, nothing has changed. We still create forms, and we put them on the real estate of a web page.
As a software engineer, I started my career with vanilla JavaScript, then jQuery, then Angular, then React and now with re-frame (ClojureScript). Don’t get me wrong, it’s SO much better now. But I feel we reached a local maxima. Tools have improved, not the outcome. We’re still in the tar pit.
And I’m not even mentioning this bloody CSS which I give the honour of being the worst technology of our era (after bluetooth of course). While game developers are still laughing at us poor web people, we learned that the best way to write CSS is not to write CSS.
Anyhow. Why does it feel like a local maxima? I see two reasons:
Forms are dynamic (ie: type, submit, load, reset, repeat actions) but they live on static web pages. That creates a dissonance, the same way ensemble probability reasoning is not applicable to time probability. In other words, we’re trying to put square pegs in round holes.
There are no incentives to change the status quo. Blame the experts.
Ask any startups around you. Ask them if they ever had to reduce the number of software developers in their team. My guess is that unless they were dying, they hadn't. Actually, even if they’d been dying they would probably still try to keep the developers in the hope to get acqui-hired. Or, vice versa, ask if they are not always hiring for them.
The explanation is straightforward: developers create technical debt, which can be only reduced by more developers. Or to put it differently: every new line of code is a liability not an asset.
Developers usually dislike decisions to cut corners or to ship an half-baked feature for the business. But deep down, consciously or not, they know they're creating more future demand for their skills.
It's an absolute seller market. Non-developer people are getting very aware of that, joining bootcamps or training themselves to land one of these so-called tech job paying way better money. This concerns mostly remote-friendly tech companies. Which means all tech companies in 2021.
And the more developers, the more technical debt is created, the more companies want developers. Amusingly, these developers are attributed a very particular status of "tyrannical slave": usually at the bottom of the chain, but with immense power.
On top of that, users have become more demanding as we are in "the decade of design". It's no longer enough to have a MVP (minimum viable product) you need a MLP (minimum lovable product). And love is never cheap.
So companies sprinkle designers on top. Refining web pages, conducting user research making sure users can find the right form on the right screen at the right moment. And, of course tweaking the CSS ad nauseam.
The reality is that most companies can’t afford to hire these web engineers, and designers, and mobile developers, and product designers and art directors (and the infamous devops managing the ever increasing AWS complexity debt)...
What do they do? They use Intercom (or similar services — they are legion).
Your first encounter with Intercom (or similar) was probably with one of these annoying chat bubbles appearing at the bottom right of a website. Getting in the way of what you were trying to achieve.
Why businesses resort to these services? They have a problem: their website is not evolving or adapting fast enough, and users are getting lost, ending up not buying their product or being frustrated. Since these companies don't have the means to fix that with more developers and designers, they "patch" it with one of these chat assistant. The rationale being: we can fix whatever problems our users are having by holding their hand while they navigate our poorly-designed website.
People familiar with regular expressions will recognize the famous fallacy:
Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.
Businesses still have a malfunctioning website AND now they have to maintain and pay for this expensive new tool. A tool which is, by the way, not much more than a glorified, VC-funded version of Microsoft Word’s Clippy!
Intercom set out to make internet business more personal. But they stopped halfway. What they truly achieved is to make their business successful, and create a cult around their product vision: back in 2018, being against Intercom was almost as contrarian as being pro crypto.
No results found for “intercom is overrated”.— Google Search, circa 2018
Let's not be too harsh on them though, they put me on the right path when I asked myself: why not having an empty page with a full screen intercom? I thought this would be at least less confusing for the user.
That’ll lead us to the main idea of this article, but before going there let's take a detour through crypto land.
There are many similarities between crypto and the early days of the web. Take the Ethereum blockchain for instance, developers can come and deploy any application on it, which will be represented as a set of what we call smart contracts. The same way anyone can publish a website on the world wide web.
But what's interesting with crypto is that everything goes faster — probably because money is a better incentive than information. And crypto already reached this local maxima that we mentioned earlier for the web. The systems, the platforms have to evolve. And they are evolving.
We have now all these layer 2 protocols. Basically offering developers a way to build on higher level abstractions, avoiding the hurdles of basic layers: high transaction fees and slow transaction times for instance. Suddenly it's another paradigm shift, unlocking entirely novel usage. Let’s take the obvious example of buying and selling GodsUnchained NFT cards for very low amounts (true micro transactions) without any fee or delay.
In general we want robust abstractions on top of each other — that's how we go from the transistors on a chip to streaming videos on a screen. Unfortunately for the web we've been stuck with leaky abstractions. And, no, the plethora of new no-code apps are not abstractions: they are better tools, but the outcome is the same, targeting this dissonant web format that we want to avoid.
Well, truth be told, we almost had layer 2 for web2.0 applications... but they lived inside the walled-gardens of vendor lock-ins.
Chatbots were all the rage a few years ago, some even predicting they would replace all the apps in some segment like e-commerce. It didn't happen. Chatbots were often annoying and probably tried to do too much (and in the end did nothing). I made this mistake, but this was not entirely at a loss.
In 2017 I built a Slack bot to help coworkers know each other better in a playful manner (it managed to get a lot of users and made me reach the front page of Hacker News for the first time in my life). In 2018 I built a bot for Facebook messenger to let users create their digital movie libraries (no fame for this one unfortunately). Both times building came with challenges since not so many people were building real products for these platforms. But with my different collaborators at the time we acknowledged the new and powerful capabilities brought by this chatbot format:
A login system is already in place
You can monitor the activity accurately
You can talk to users for real
You’re cross platform
You have a notification system available
You get to provide the best on-boarding experience possible
And overall you’re more productive as a developer because of the constraints of the conversation
It’s not all rosy though. Vendor lock-in sucks. You end up stuck and limited by Facebook, Salesforce or Amazon. Good luck adding crypto payments in your system within these walled gardens. So we don't want that… We want the benefits of the chatbots on the web… Or the web in a conversational format.
It's time to unveil the main idea. Going back to the intercom fallacy: what if a website is a full page conversation, but with web components inside messages? Or let's look at this image explaining the "inversion".
The components usually spreading over the real estate of a traditional website, are now moved inside a conversation. This conversation represents the entire history of the interaction with the user: components can be duplicated and in different states. Only scrolling up is required to resume interacting with them.
This inversion makes building a web application effectively at the component level. Components in isolation, a key practice already well understood by players like Storybook or even more recently Next.js and their url imports (thanks Mike!).
But make no mistake, we are not using Intercom, or any closed-source vendors. We keep the open web, and simply turn the interactions into an (almost) invisible conversation with the runtime of an application.
This probably doesn't make sense just yet. But please don't give up, a case study is coming!
I just need to touch on support before that.
Support is always an afterthought. Companies build and release applications to later realize users are not doing what they are supposed to do. How come, with all that user research they conducted?!
So much energy and resources are wasted on support. Companies resort to using tracking tools like FullStory to actually see what users are doing. And still, when debugging a specific situation for a user, it's almost impossible to get the full context after the fact. The never ending list of debug tools or log systems are just INDIRECTIONS to the real application.
Support has to be built-in, omnipresent, not an afterthought. And if the user is interacting through a conversation with the application, support is just about adding a support agent in that conversation. Both sides would have access to the same information and the exact history of interactions with the components. No asymmetry!
This "support everywhere" came as a side effect, but it's the thing that got me excited the most, especially after being so frustrated with existing support tools which end up running in parallel.
We will see that support can even get better within this conversational format for the web.
I wanted to try this main idea on a minimal but real use case. Because I can never wander too far away from web3, I picked the "simplest crypto wallet" idea: the product is called WAWA and lets you send, receive and check your crypto balance.
https://wawa.teawaterwire.dev/
The design is rough, as my full-stack capabilities stop at the "make it pretty" step of the UI... but here's a screencast showing the features of WAWA, and also the aforementioned built-in support system.
https://www.loom.com/embed/7aa975361a6a4e5b92df88fae31ca751?display=iframe
Password-less signup
Native onboarding
Checking balance of the wallet
Getting address of the wallet, and funding it from a MetaMask
Chatting with support
Support sending text and a component directly
Sending ETH to a counterparty
Stopping chat with support
Checking updated balance from first component in the history
The send, receive and balance components are React components, that are supposed to be built in isolation (a la Storybook).
The global state is handled with re-frame (ClojureScript), but components can have local state as well, if deemed not important enough to be saved globally.
The chat system is based on the Matrix protocol: it is a key component of our conversation-first architecture. (You could have guessed it from the screencast with the support agent using the Element Matrix client).
Communicating with the server means sending a message that will be interpreted by the "user account" of the application present in the conversation (that can also be joined by the support agent)
There is free text input, necessary for support, but also for notes to self. The vision is to have something like Mac Spotlight, where you type and the actions appear depending of context (tools like CommandBar are providing this experience, but they're unfortunately following the Intercom fallacy).
Most of the web now is in 2d: top, right, bottom, left. I'll accept that we have some 3d as well: x, y, z. We interact with these interfaces with our intents and our touchscreens or pointers. The arrow of time is casually showing up when we order our actions, or when we use the infamous Ctrl+Z action: rewinding time locally or more as a debug-only mode for trying things out without keeping them.
What if time became a new dimension, letting us navigating it as easily as we can move our pointers left or right?
This idea is already well in place in the database world. We have what is called "temporal databases" which you can query against time. Or more excitingly we even have "bi-temporal databases" like XTDB, which you can query against two axis of time: transaction time and valid time.
Unfortunately I couldn't go with this very cool word "bi-temporal" here, as it doesn't really apply... but I could indeed keep the satisfying "temporal" part.
So please welcome the stage our new friend.... THE TEMPORAL WEB... Taking time as a new dimension, the fourth dimension... how convenient... let's define it again:
web4ᵗʰ aka "the temporal web": user interactions across screen space and time of an immutable conversation
The temporal web with conversation-first interfaces, leveraging decentralized communication protocols.
Forcing developers to really think at the isolated-component level, while reducing the surface of worry (remember mobile-first, constraints are a blessing).
Making their life simpler (even though they don't want it because… money, you know)
And most importantly making users' lives simpler: catering better for their intents and adding outstanding build-in support
Art is fine though. You can keep building landing page or product pages, this is art. Art doesn't have to be efficient.
Writing on Mirror is fine. it's about "passively" consuming, not actively interacting.
A game stays a game, I don't want to play Gods Unchained in a conversation, because I want to be fully immersed. It's not really the web anyway…
I’ll agree with you, this is still a rough idea but I believe the foundations are here.
I'd be very curious to build a real big web application with this paradigm. Ping me if you are a pioneer.
Webo Webini Lupus.
Back in October 2018 I started a note with the title "The Web is Dead" while being part of the startup studio called eFounders. I was working on what is now Multis (crypto stuff) and also spending time surrounded by other startups building products on the web. Serendipity was ubiquitous. Especially when I'd go for a coffee walk around the 9th arrondissement with my wordsmith friend Jonathan. I probably started the note after an intense debate about Intercom (more on that later).
This article comes after 10+ years of working for the world wide web, from web1 to web2.0 to web3. It took me 3 years to connect the dots, after building decentralized applications and also, surprisingly, chatbots. I hope you find something interesting in it (or actually not, because contrarian is better).
(tl;dr)
How many times have you opened a tab and performed the exact same steps you performed one minute, one hour or one day ago? Your honest answer: all the time. You just went to Airbnb and entered the same city, the same dates as you did yesterday... or that Google search that you do again and again... or this floor price on OpenSea you keep checking... This surely feels sub-optimal.
But how much more frustrating is it having to learn to navigate every new website you visit. You'll say that's the beauty of the diversity of the web. But the reality is that it creates lots of inefficiencies. The proof, you ask? Websites keep copying each other in an ironical attempt at being “intuitive”.
There are too many things on a page, too many buttons, links and most of all too much real estate: the surface is extremely large for a poor little cursor or eyeball. Adding on top that the sequence of the actions matters: “first this, then that and -oh- a submenu appears”.
Users come with intents, they want to do something. The way to collect these intents is with the “form primitive”: that meta-category encompassing elements like inputs, buttons, checkboxes, links which allow users to send data to a web application runtime in order to change the state of the world (ex: save a record in database, navigate to a new page).
Now, I put it to you that since the web was created, nothing has changed. We still create forms, and we put them on the real estate of a web page.
As a software engineer, I started my career with vanilla JavaScript, then jQuery, then Angular, then React and now with re-frame (ClojureScript). Don’t get me wrong, it’s SO much better now. But I feel we reached a local maxima. Tools have improved, not the outcome. We’re still in the tar pit.
And I’m not even mentioning this bloody CSS which I give the honour of being the worst technology of our era (after bluetooth of course). While game developers are still laughing at us poor web people, we learned that the best way to write CSS is not to write CSS.
Anyhow. Why does it feel like a local maxima? I see two reasons:
Forms are dynamic (ie: type, submit, load, reset, repeat actions) but they live on static web pages. That creates a dissonance, the same way ensemble probability reasoning is not applicable to time probability. In other words, we’re trying to put square pegs in round holes.
There are no incentives to change the status quo. Blame the experts.
Ask any startups around you. Ask them if they ever had to reduce the number of software developers in their team. My guess is that unless they were dying, they hadn't. Actually, even if they’d been dying they would probably still try to keep the developers in the hope to get acqui-hired. Or, vice versa, ask if they are not always hiring for them.
The explanation is straightforward: developers create technical debt, which can be only reduced by more developers. Or to put it differently: every new line of code is a liability not an asset.
Developers usually dislike decisions to cut corners or to ship an half-baked feature for the business. But deep down, consciously or not, they know they're creating more future demand for their skills.
It's an absolute seller market. Non-developer people are getting very aware of that, joining bootcamps or training themselves to land one of these so-called tech job paying way better money. This concerns mostly remote-friendly tech companies. Which means all tech companies in 2021.
And the more developers, the more technical debt is created, the more companies want developers. Amusingly, these developers are attributed a very particular status of "tyrannical slave": usually at the bottom of the chain, but with immense power.
On top of that, users have become more demanding as we are in "the decade of design". It's no longer enough to have a MVP (minimum viable product) you need a MLP (minimum lovable product). And love is never cheap.
So companies sprinkle designers on top. Refining web pages, conducting user research making sure users can find the right form on the right screen at the right moment. And, of course tweaking the CSS ad nauseam.
The reality is that most companies can’t afford to hire these web engineers, and designers, and mobile developers, and product designers and art directors (and the infamous devops managing the ever increasing AWS complexity debt)...
What do they do? They use Intercom (or similar services — they are legion).
Your first encounter with Intercom (or similar) was probably with one of these annoying chat bubbles appearing at the bottom right of a website. Getting in the way of what you were trying to achieve.
Why businesses resort to these services? They have a problem: their website is not evolving or adapting fast enough, and users are getting lost, ending up not buying their product or being frustrated. Since these companies don't have the means to fix that with more developers and designers, they "patch" it with one of these chat assistant. The rationale being: we can fix whatever problems our users are having by holding their hand while they navigate our poorly-designed website.
People familiar with regular expressions will recognize the famous fallacy:
Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.
Businesses still have a malfunctioning website AND now they have to maintain and pay for this expensive new tool. A tool which is, by the way, not much more than a glorified, VC-funded version of Microsoft Word’s Clippy!
Intercom set out to make internet business more personal. But they stopped halfway. What they truly achieved is to make their business successful, and create a cult around their product vision: back in 2018, being against Intercom was almost as contrarian as being pro crypto.
No results found for “intercom is overrated”.— Google Search, circa 2018
Let's not be too harsh on them though, they put me on the right path when I asked myself: why not having an empty page with a full screen intercom? I thought this would be at least less confusing for the user.
That’ll lead us to the main idea of this article, but before going there let's take a detour through crypto land.
There are many similarities between crypto and the early days of the web. Take the Ethereum blockchain for instance, developers can come and deploy any application on it, which will be represented as a set of what we call smart contracts. The same way anyone can publish a website on the world wide web.
But what's interesting with crypto is that everything goes faster — probably because money is a better incentive than information. And crypto already reached this local maxima that we mentioned earlier for the web. The systems, the platforms have to evolve. And they are evolving.
We have now all these layer 2 protocols. Basically offering developers a way to build on higher level abstractions, avoiding the hurdles of basic layers: high transaction fees and slow transaction times for instance. Suddenly it's another paradigm shift, unlocking entirely novel usage. Let’s take the obvious example of buying and selling GodsUnchained NFT cards for very low amounts (true micro transactions) without any fee or delay.
In general we want robust abstractions on top of each other — that's how we go from the transistors on a chip to streaming videos on a screen. Unfortunately for the web we've been stuck with leaky abstractions. And, no, the plethora of new no-code apps are not abstractions: they are better tools, but the outcome is the same, targeting this dissonant web format that we want to avoid.
Well, truth be told, we almost had layer 2 for web2.0 applications... but they lived inside the walled-gardens of vendor lock-ins.
Chatbots were all the rage a few years ago, some even predicting they would replace all the apps in some segment like e-commerce. It didn't happen. Chatbots were often annoying and probably tried to do too much (and in the end did nothing). I made this mistake, but this was not entirely at a loss.
In 2017 I built a Slack bot to help coworkers know each other better in a playful manner (it managed to get a lot of users and made me reach the front page of Hacker News for the first time in my life). In 2018 I built a bot for Facebook messenger to let users create their digital movie libraries (no fame for this one unfortunately). Both times building came with challenges since not so many people were building real products for these platforms. But with my different collaborators at the time we acknowledged the new and powerful capabilities brought by this chatbot format:
A login system is already in place
You can monitor the activity accurately
You can talk to users for real
You’re cross platform
You have a notification system available
You get to provide the best on-boarding experience possible
And overall you’re more productive as a developer because of the constraints of the conversation
It’s not all rosy though. Vendor lock-in sucks. You end up stuck and limited by Facebook, Salesforce or Amazon. Good luck adding crypto payments in your system within these walled gardens. So we don't want that… We want the benefits of the chatbots on the web… Or the web in a conversational format.
It's time to unveil the main idea. Going back to the intercom fallacy: what if a website is a full page conversation, but with web components inside messages? Or let's look at this image explaining the "inversion".
The components usually spreading over the real estate of a traditional website, are now moved inside a conversation. This conversation represents the entire history of the interaction with the user: components can be duplicated and in different states. Only scrolling up is required to resume interacting with them.
This inversion makes building a web application effectively at the component level. Components in isolation, a key practice already well understood by players like Storybook or even more recently Next.js and their url imports (thanks Mike!).
But make no mistake, we are not using Intercom, or any closed-source vendors. We keep the open web, and simply turn the interactions into an (almost) invisible conversation with the runtime of an application.
This probably doesn't make sense just yet. But please don't give up, a case study is coming!
I just need to touch on support before that.
Support is always an afterthought. Companies build and release applications to later realize users are not doing what they are supposed to do. How come, with all that user research they conducted?!
So much energy and resources are wasted on support. Companies resort to using tracking tools like FullStory to actually see what users are doing. And still, when debugging a specific situation for a user, it's almost impossible to get the full context after the fact. The never ending list of debug tools or log systems are just INDIRECTIONS to the real application.
Support has to be built-in, omnipresent, not an afterthought. And if the user is interacting through a conversation with the application, support is just about adding a support agent in that conversation. Both sides would have access to the same information and the exact history of interactions with the components. No asymmetry!
This "support everywhere" came as a side effect, but it's the thing that got me excited the most, especially after being so frustrated with existing support tools which end up running in parallel.
We will see that support can even get better within this conversational format for the web.
I wanted to try this main idea on a minimal but real use case. Because I can never wander too far away from web3, I picked the "simplest crypto wallet" idea: the product is called WAWA and lets you send, receive and check your crypto balance.
https://wawa.teawaterwire.dev/
The design is rough, as my full-stack capabilities stop at the "make it pretty" step of the UI... but here's a screencast showing the features of WAWA, and also the aforementioned built-in support system.
https://www.loom.com/embed/7aa975361a6a4e5b92df88fae31ca751?display=iframe
Password-less signup
Native onboarding
Checking balance of the wallet
Getting address of the wallet, and funding it from a MetaMask
Chatting with support
Support sending text and a component directly
Sending ETH to a counterparty
Stopping chat with support
Checking updated balance from first component in the history
The send, receive and balance components are React components, that are supposed to be built in isolation (a la Storybook).
The global state is handled with re-frame (ClojureScript), but components can have local state as well, if deemed not important enough to be saved globally.
The chat system is based on the Matrix protocol: it is a key component of our conversation-first architecture. (You could have guessed it from the screencast with the support agent using the Element Matrix client).
Communicating with the server means sending a message that will be interpreted by the "user account" of the application present in the conversation (that can also be joined by the support agent)
There is free text input, necessary for support, but also for notes to self. The vision is to have something like Mac Spotlight, where you type and the actions appear depending of context (tools like CommandBar are providing this experience, but they're unfortunately following the Intercom fallacy).
Most of the web now is in 2d: top, right, bottom, left. I'll accept that we have some 3d as well: x, y, z. We interact with these interfaces with our intents and our touchscreens or pointers. The arrow of time is casually showing up when we order our actions, or when we use the infamous Ctrl+Z action: rewinding time locally or more as a debug-only mode for trying things out without keeping them.
What if time became a new dimension, letting us navigating it as easily as we can move our pointers left or right?
This idea is already well in place in the database world. We have what is called "temporal databases" which you can query against time. Or more excitingly we even have "bi-temporal databases" like XTDB, which you can query against two axis of time: transaction time and valid time.
Unfortunately I couldn't go with this very cool word "bi-temporal" here, as it doesn't really apply... but I could indeed keep the satisfying "temporal" part.
So please welcome the stage our new friend.... THE TEMPORAL WEB... Taking time as a new dimension, the fourth dimension... how convenient... let's define it again:
web4ᵗʰ aka "the temporal web": user interactions across screen space and time of an immutable conversation
The temporal web with conversation-first interfaces, leveraging decentralized communication protocols.
Forcing developers to really think at the isolated-component level, while reducing the surface of worry (remember mobile-first, constraints are a blessing).
Making their life simpler (even though they don't want it because… money, you know)
And most importantly making users' lives simpler: catering better for their intents and adding outstanding build-in support
Art is fine though. You can keep building landing page or product pages, this is art. Art doesn't have to be efficient.
Writing on Mirror is fine. it's about "passively" consuming, not actively interacting.
A game stays a game, I don't want to play Gods Unchained in a conversation, because I want to be fully immersed. It's not really the web anyway…
I’ll agree with you, this is still a rough idea but I believe the foundations are here.
I'd be very curious to build a real big web application with this paradigm. Ping me if you are a pioneer.
Webo Webini Lupus.
Share Dialog
Share Dialog
No comments yet