I'm a full-stack developer for Crutchfield Corp. I strongly
believe in writing beautiful code, developing accessible
solutions, and giving back to the coding world. The easiest
way to reach me is
@m4c9416
on Twitter.
Jumping out of the dark and shouting "BOO!" at a friend
is fun. Why? Because they start, maybe scream, generally act
scared. Then of course, they realize that instead of a
menacing ghost it's a good friend, and you both enjoy a
good laugh.
Humans jump to conclusions, and they do it quickly.
If you're a fan of evolutionary biology, you might
believe the tendency to jump to conclusions
emerged out of a higher survival rate for those who did.
If your brain says "I think I see a bear," its time is
better spent calculating escape routes than
contemplating, "Well what if it's just a funny-looking
tree?"
If you believe god(s) made the human mind pretty much
the way it is, it's reasonable to suspect
she/he/it/they designed the brain to think fast and
therefore live longer and more happily.
As web user experience designers, we tend to think
of "experiences" as activities such as "switching tabs"
or "clicking the play button."
But some experiences are moments rather than
activities. Your mind sees an image and, by nature,
must draw a conclusion.
If the image presented by a user interface is likely to
be interpreted in a negative way ("This interface is
ugly/confusing/irritating."), it doesn't matter if 500
milliseconds later everything looks great. Your
interface yelled "BOO!", your user is scared, and the
rest of the experience is contaminated by that negative
feeling.
In some later post I'll argue that progressive JPEGs
(images that initially load low-quality but then
improve) are perceived with more negative emotions than
baseline JPEGs (images that load top-to-bottom) because
of the conclusions to which the user jumps in the first
few milliseconds of the loading process.
For now I'll simply assert: user experience must be
designed with an eye toward moments
(even ones that last mere milliseconds) because of
the human need to jump to conclusions.
Keryx is an offline package manager for Debian-based
operating systems.
On my previous blog, I wrote "Reviving Keryx" announcing
my intention to refactor and bring the project back to
life.
But then life happened. I haven't pulled up the Keryx
source code in a long time.
Keryx provided a huge service for the Linux community,
impacting people around the world. I wish I were
in a position to continue development.
If you've landed on this page and need something like
Keryx in your life, please hit me up @m4c9416
on Twitter and let me know. If there's enough continued
interest, I might carve out enough time to update the
code base.
I installed an FTP client and text editor on my phone.
Writing HTML is a bit unwieldy with the mobile keyboard,
but it works.
Once I'm back to my keyboard, I'll attempt to make individual
"pages" out of my blog posts, using the history API.
I'm thinking all requests will have to be served index.html via
server-side rewrites and particular posts shown according to the
URL by JavaScript. I'm still not sure how to handle 404 errors.
Update: I'm back at my desktop and wouldn't want to
develop from a mobile device for extended periods of time.
I like Chrome's Lighthouse tool. So much so that I set up a
service worker for this site, just so I could earn 100
scores across the board.
I used a boilerplate
service worker. But didn't really know how it works.
So now the worker is caching index.html, and I'm not sure
how to bust the cache. I incremended the precache version,
but no dice.
Oh well, I'm learning.
Update: the boilerplate has a runtime cache which
caches everything. Busting the precache won't update
index.html. So I removed the runtime cache logic, and now
the page updates when I increment the precache version.
I got an email today that my site had malware. It was a Wordpress
site that I didn't really maintain, so I guess I shouldn't be
surprised.
So I said "forget this" and deleted my blog.
I've been meaning to rewrite it for a long time. But each time
I started, I'd think "I should really version control this. And
then automatically deploy on a commit. But to a staging
environment first, then to production. Should the staging
environment be behind a login? Also I'll need to bundle styles
and scripts and minify everything and serve it from a CDN."
I'm exhausted just from typing it. So I'm writing up this page
in gedit, and I'll upload it as index.html in FileZilla. Why?
Because those tools are the ones I have handy. Maybe this site
will some day be more complex. But for now? It's easy.
Area 404 - nothing to see here
Terribly sorry, but if there's anything here, we're
unwilling to acknowledge its existence.