Conversation

One recent way this helped me: I think we can make inboxes (email, tasks, tabs, reading lists) less burdensome by replacing high-stakes mechanics (“close tab”) w/ low-stakes ones (“not right now”, decay). The insight comes from understanding these as queueing systems! (cont)
Quote Tweet
In cogsci, Marr suggests 3 levels at which a system (eg vision) can be analyzed: computational (the fundamental problem being solved), algorithmic (how it’s solved, abstractly), and implementation (hardware details). It’s an interesting taxonomy for analyzing tools for thought!
Show this thread
6
7
87
Inboxes only “work” if you trust how they’re drained. From a queue-processing perspective: the departure rate must be below some threshold. Inbox Zero “works” by aggressively increasing that rate (via defer, delegate, drop)—blunt, but ensures that departure rate > arrival rate.
2
14
This tactic requires you to make a decision about every item in the inbox. Maybe fine when queue is small, but explicitly deferring a task imposes an emotional cost, possibly unnecessarily: “inbox zero” is only necessary if the arrival rate *always* exceeds the departure rate.
Replying to
If the arrival rate is variable and sometimes sits below the departure rate, you can still handle everything in a reasonable timeframe. A more ideal mechanism would ensure that wait times remain tolerable without insisting on a 1-day cycle time.
1
3
But what I’m saying here is that thinking about this design problem as a queueing theory problem is much more generative than just brainstorming up a cool UI mechanism, because it gives you a way to *reason* about the space of mechanisms, e.g. in terms of average wait time.
3
25
Replying to
I want to make an inbox system, where each new address has to be green-lit into a category or not. Then it would auto sort into category, and only new addresses would require much thought. Would be initial effort but worth it I think