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)
https://twitter.com/andy_matuschak/status/1367577034407354368
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.
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.
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.
The system should also consider the number of decisions to be made: I’d rather make fewer decisions but tolerate a longer average wait time. One way to implement that might be exponentially increasing deferral actions: notes.andymatuschak.org/Spaced_repetit…
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.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
