Browse files

## Big long day of BV deep dive

Still making my way through Learnable Programming, making sure to read all of the footnotes and refernces, as well as fully articulate all of the relevant other thoughts I have while I read. This is probably too much writing, I'm beginning to realizing, but I am indeed almost done! With this one essay. Then there is much to do read and re-watch before heading out to Dynamicland.

I also got my first Tufte book, the Visual Display, and would love to get partway into that at least as well.
  • Loading branch information...
stevekrouse committed Jan 9, 2018
1 parent 4334f2a commit 3c1e836b2690ad0777cedaa50121b3c09cfc16b2

Large diffs are not rendered by default.

Oops, something went wrong.
@@ -1,8 +1,8 @@
title: Customer Support
title: Customer service
# Customer Support
# Customer service
## How important is interface design
@@ -53,4 +53,25 @@ We all know that the internal customer support interface has many of these actio
## Not chat bot
Many have thought that the future of customer support is a chat bot, possibly with AI. However, text is a poor interface. Otherwise would be a chat bot experience. The only reason we think the future of customer support is a chat bot is because we think that we need another human to press buttons on some internal interface for us.
Many have thought that the future of customer support is a chat bot, possibly with AI. However, text is a poor interface. Otherwise would be a chat bot experience. The only reason we think the future of customer support is a chat bot is because we think that we need another human to press buttons on some internal interface for us.
## Restaurants, waiters, and menus
Earlier this week, I was reflecting on the thoughts in this essay while at a favorite restaurant. We were waiting for a waiter to take our order. We kept looking around for him, but didn't see him. It took 5-10 minutes for him to come over. Then I watched him run over to the restaurant comptuer, punch in our order, and then approach the next table.
### Ideal menu
Whenever I'm at a new restaurant, I want to know "what's popular here?" as well as "what do people with my tastes order here?" You may recognize these questions as the sorts of things that Amazon routinely answers for you before you even ask the question with their interfaces that rank popular and well reviewed products, as well as their "people who bought this also bought" section. If we had a better interfaces at restaurants (as well as a system where a person's orders could follow them between restaurants -- which would also integrate with payment, splitting the bill, and of course your health apps, which, of course, would prevent you from placing any order that would exceed your chosen health goals or would at least make you aware of the attempted discretion), we could without much effort compute much of this information and display it intuitively for users.
## Human-to-human-to-comptuer
It struck me that this sittuation is strikingly similar to the customer support sittuation. What's the similarity? You have a customer interfacing with a agent of a businesss interfacing with a comptuer on behalf of the customer. It's a human-to-human-to-computer interface. Once I was able to articulate this abstraction it lead me to see the commonality of many different sittuations I find problematic:
* accountants
* lawyers
* software developers
* designers
Each of these professionals listen to a customer, ask relevant questions, propose relevant options, type stuff into a computer, show the results to the customer, and repeat this proccess until the desired result on the computer is achieved. It's a big waste of time, money, and source of great fustration. Most of all, in the medium-is-the-message sense, it leads people to feel less empowered than they would if they had a proper comptuer interface for they, themselves to get to directly interface with the problem domain.
One example of a human-to-human interface without a computer at the other end would be a pschologist. Clearly I'm not talking about solving this interface with a computer. Although there are some interesting moves in this direction, even with a simple quiz interface such as can be found at
@@ -0,0 +1,41 @@
title: Regex for humans
# Regex for humans
This reminds me of my idea to build a more human-readable regex. Yet this again harks back to the question of whether regex is so powerful because of the very same concise abstractness which makes it impossible without a reference manual handy and the ability to test it out immediately. And someone, who literally thanks Bret Victor for being the inspiration, already [wrote this up]( Of course, this also reminds me of [Legible Mathmatics]( Another relevant project:
I really love this Regex UCR project! I'd lead towards a thicker layer of abstraction ontop of regex, by which I mean removing the backslash and other special characters. I'd replace them with a graphic or a more descriptive name. If we go the descriptive name route, we may end up having to stack these matching instructions vertically as [VerbalExpressions]( does.
The fact that this is a problem, a solution is relatively clear, and yet nobody is doing anything, is a bit puzzling. It begs the question? Is this a problem that's worthwhile for me to solve? apparently gets [1.3M]( mothly visits. Other competitors get 10s of thousands of visits per month. While this is not directly monitizable, I imagine it pays decent dividends in respect, inbound leads, etc.
It's the sort of project that could generate the right kind of inbound opportunities, if I were indeed looking for a job in interface design.
And it'd be fun!
But even as scoped as it seems, it's really a bear of a project. Even just building a barely useful version that only implements the basics of regex would take hours and hours. And then what? The slog of filling out the implementation would then begin, and I'd be like Olli of Regex UCR, holding the reins of a half-finished open source project without anyone to help me.
Potentially this project would be easier if I simply built of their work? Or maybe not, as it [seems like they don't have much built](, although this rawgit view might be deceptively simplistic.
I think the way I'd try to tackle this by implementing a UI-based interface on top of [VerbalExpressions]( Which then, given how uniform this library is, and how many different langauges it compiles to, we could then compile it to various sub-languages pretty easily. This is abstraction at its finest! I'd be building on top of an abstraction of an abstraction!
However, I'd really want to think through if this would make this library easier to use, given that it seems pretty easy to use in the first place.
In conclusion, while this project seems like a neat way to show off my Bret Victor inspiration, I'm not sure who has what problem, and if this semi-proposed solution would solve it.
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
ga('create', 'UA-103157758-1', 'auto');
ga('send', 'pageview');
<script repoPath="stevekrouse/" type="text/javascript" src="/unbreakable-links/index.js"></script>
Oops, something went wrong.

0 comments on commit 3c1e836

Please sign in to comment.