| ALEXA PAPER
I've become obsessed with domestic life and its structures. For some
time I have been in pursuit of perfect days. I hold a belief that
happiness can be made as a by-product of order: an organized home, a
robust routine, a fulfilment of basic physical needs. This belief has
been shaped out of need: a need to cope with parts of my life that
have me unhappy. My thinking is that I can repair what's broken from a
stable base of predictability. If enough of the errata of my day is
predetermined then I will be able to focus on fixing emotions,
relationships, and self-worth that is in disrepair.
Alexa Paper is an attempt to add a small morning informational ritual
into each day. In essence, it is something between a daily newspaper,
an itinerary, and an agenda. Or as my friend put it: "a roadmap to the
day with entertainment along the way." It is made of sticky shipping
labels printed out of a Zebra ZP 450 printer and a Python program that
typesets each label's contents. Each label is intended to contain a
structure of self-similar daily markers (think: date, weather,
appointments), as well as a concoction of timely or random widgets
(think: crossword, sudoku, trivia, news headlines). Everything gets
assembled and typeset each morning just before the label prints.
|
|
I currently have a working prototype of Alexa Paper. The software is a
rather uniquely programmed Python script that contains functions for
building the three currently supported components: a short-term
weather forecast, a datestamp, and a crossword. I struggled with
conceiving a smart way about the program's structure and design. I
avoided the OOP paradigm out of stubborness, instead landing in a
freakish functional paradigm that looks like it belongs to a LISP. To
further complicate my life, I thoroughly abused Python's available
functional features and data structures so I could avoid ever having
to modify an existing variable. Why? Because I have a knack for making
life complicated.
,----
| def make_forecast_zpl(attrs: PrintAttrs, forecast: Forecast, dimensions: Dimensions, origin: Origin) -> str:
| period_origin = Origin(x=0,
| y=0, units=Units.MM, reference=origin)
| temp_origin = Origin(x=0,
| y=1 + font_peri.dimensions.y, units=font_peri.dimensions.units, reference=origin)
| abbrev_origin = Origin(x=0,
| y=1 + temp_origin.y + font_temp.dimensions.y, units=temp_origin.units, reference=origin)
| return "%s\n%s\n%s" % (compositor.make_text_zpl(attrs,
| font_peri, period_origin, forecast.period),
| compositor.make_text_zpl(attrs,
| font_temp, temp_origin, forecast.temperature),
| compositor.zpl_wrap_origin(attrs,
| compositor.zpl_wrap_font(attrs,
| font_peri, compositor.zpl_field_block(attrs,
| dimensions, font_peri, forecast.abbreviated)),
| abbrev_origin))
`----
The printer is attached to a Raspberry Pi 5. A cronjob prints a label
every morning. After a week of running off my prototype paper, I
discovered flaws in my project. Largely, these have to do with the
prototype's informational components. For one, the weather forecast is
useless. It is much easier to check the weather using a phone app. For
two, the crossword is easy, way too easy. I usually finish the puzzle
in less than a minute. I was hoping the challenge would endure through
the day. Finally, the datestamp is nice but it's not really that
helpful. My watch has a date feature I'm already in the habit of
using.
I had dreams of adding more, better information to the paper. And
maybe more, better information would lead to it feeling more
consequential in my life. But I have struggled to come up with
components that interest me enough to implement. Like, I could add
trivia, sure. But is that something I would enjoy for more than a few
days or weeks? The success of this project is predicated on the value
of the information in the little format of a four-by-six sticky
label. That's not a lot of space! Whatever is on there could be just
as well shown on a phone, and I'm inclined to prefer that kind of
format anyway.
|
