572 lines
25 KiB
Org Mode
572 lines
25 KiB
Org Mode
#+HUGO_BASE_DIR: ./
|
||
#+HUGO_SECTION: posts
|
||
#+HUGO_AUTO_SET_LASTMOD: t
|
||
|
||
* Meta :@Meta:
|
||
* Technology :@Technology:
|
||
** TODO A perfect email setup (for me)
|
||
:PROPERTIES:
|
||
:EXPORT_FILE_NAME: a-perfect-email-setup-for-me
|
||
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
|
||
:END:
|
||
|
||
I've never been satisfied with any of the email clients most people use.
|
||
I've tried [[https://www.thunderbird.net/en-GB/][Thunderbird]], [[https://wiki.gnome.org/Apps/Evolution][Evolution]], [[https://getmailspring.com/][Mailspring]], [[https://support.apple.com/mail][Mail.app]], [[https://roundcube.net/][Roundcube]],
|
||
[[https://sogo.nu/][SOGo]], [[https://wiki.gnome.org/Apps/Geary][Geary]], and /many/ more. /None/ of them handle multiple accounts
|
||
particularly well because all of the emails associated with that account
|
||
are bound within it. Sure, you can make a new folder somewhere called
|
||
~TODO~ and move all of your actionable emails to that folder but, when you
|
||
go to move actionable emails from /another/ account into that folder,
|
||
you'll likely find that the client simply doesn't let you. If it does,
|
||
when you reply, it will likely be sent from the wrong account. This is a
|
||
limitation of the IMAP protocol; everything is /managed/ locally but
|
||
changes are pushed to the remote server and mixing things the way I want
|
||
leads to broken setups.
|
||
|
||
Before I go any further, these are a few characteristics of my ideal
|
||
email tool.
|
||
|
||
- Support for multiple accounts (obviously)
|
||
- /Native desktop application/ (*not* [[https://github.com/electron/electron][Electron]])
|
||
- Has stellar keyboard shortcuts
|
||
- Doesn't require internet connectivity (other than downloading and
|
||
sending of course)
|
||
- Organisation can be done with tags
|
||
|
||
*** Why tags?
|
||
Because they're better. Hierarchies are useful for prose and code but
|
||
not for files, emails, notes, or anything where an item may fit within
|
||
multiple categories. Imagine you get an email from your Computer Science
|
||
professor that includes test dates, homework, and information about
|
||
another assignment. In that same email, he asks every student to reply
|
||
with something they learned from the previous class as a form of
|
||
attendance. In a hierarchy, the best place for this might just be a ~TODO~
|
||
folder /even though/ it would also fit under ~School~, ~CS~, ~Dates~, ~To read~,
|
||
and ~Homework~. Maybe you have a few minutes and want to clear out some
|
||
emails that don't require any interaction. In a tag-based workflow, this
|
||
would be a good time to open ~To read~, get that email out of the way, and
|
||
remove the ~To read~ tag. It would still show up under the other tags so
|
||
you can find it later and take the time to fully answer the professor's
|
||
question, add those dates to your calendar, and add the homework
|
||
assignments to your ~TODO~ list. Hierarchies can be quite cumbersome to
|
||
work with, especially when one folder ends up getting all the data. Tags
|
||
ensure that you only see what you want when you want it. Tags are more
|
||
efficient and they will remain my organisation system of choice.
|
||
|
||
*** The tools
|
||
In short, the tools we will be using are...
|
||
+ [[https://www.offlineimap.org/][OfflineIMAP]] to download our emails
|
||
+ [[https://notmuchmail.org/][~notmuch~]], the primary way emails will be organised
|
||
+ [[https://afew.readthedocs.io/en/latest/][~afew~]] to apply initial ~notmuch~ tags based on subject, sender, recipient, etc.
|
||
+ [[https://neomutt.org/][NeoMutt]] to interact with those emails, reply, compose, add/remove
|
||
tags, etc.
|
||
+ [[https://marlam.de/msmtp/][~msmtp~]] for relaying our replies and compositions to our mail provider
|
||
|
||
Yes, it's a lot. Yes, it's time-consuming to set up. Yes, it's worth it
|
||
(in my opinion).
|
||
|
||
*** OfflineIMAP
|
||
As I said above, IMAP is limiting; we need to use some other method of
|
||
downloading our emails. There's an awesome piece of software called
|
||
[[https://www.offlineimap.org/][OfflineIMAP]] which is built for exactly this purpose. Its configuration
|
||
can be rather daunting if you have as many accounts as I do (17) but
|
||
it's not /terrible/.
|
||
|
||
**** General
|
||
#+BEGIN_SRC text
|
||
[general]
|
||
metadata = ~/.offlineimap
|
||
accounts = use_exa
|
||
maxsyncaccounts = 1
|
||
ui = basic
|
||
ignore-readonly = no
|
||
pythonfile = ~/.offlineimap.py
|
||
socktimeout = 60
|
||
fsync = true
|
||
#+END_SRC
|
||
|
||
The first big option is ~accounts~; it tells OfflineIMAP what to actually
|
||
sync. What to put there will be defined further down but ~use_exa~ is just
|
||
filler text. The example account is ~user@example.com~ and I shortened
|
||
that to ~use_exa~. ~maxsyncaccounts~ is also fairly important as it tells
|
||
OfflineIMAP to only pull emails from one account at a time. This is
|
||
certainly slower than multiple but it's also safer because we'll be
|
||
running this in the background and don't want many OfflineIMAP processes
|
||
executing concurrently and interfering with each other. ~pythonfile~ will
|
||
be discussed later.
|
||
|
||
**** Account
|
||
#+BEGIN_SRC text
|
||
[Account use_exa]
|
||
localrepository = use_exa-local
|
||
remoterepository = use_exa-remote
|
||
quick = 10
|
||
utf8foldernames = yes
|
||
postsynchook = notmuch new
|
||
#+END_SRC
|
||
|
||
In the first block, ~localrepository~ and ~remoterepository~ tell OfflineIMAP where
|
||
to look for your emails. ~use_exa-local~ is an arbitrary naming scheme I use to
|
||
differentiate between the various local and remote accounts. It can easily be
|
||
swapped with something else.
|
||
|
||
**** Repository
|
||
#+BEGIN_SRC text
|
||
[Repository use_exa-local]
|
||
type = Maildir
|
||
localfolders = ~/mail/use_exa
|
||
sync_deletes = yes
|
||
|
||
[Repository use_exa-remote]
|
||
type = IMAP
|
||
remotehost = imap.example.com
|
||
starttls = yes
|
||
ssl = no
|
||
remoteport = 143
|
||
remoteuser = user@example.com
|
||
remotepasseval = get_pass("use_exa")
|
||
auth_mechanisms = GSSAPI, XOAUTH2, CRAM-MD5, PLAIN, LOGIN
|
||
maxconnections = 1
|
||
createfolders = True
|
||
sync_deletes = yes
|
||
#+END_SRC
|
||
|
||
The repository sections describe how the emails are stored or retrieved.
|
||
In the ~local~ block, you'll notice that the type is ~Maildir~. In this
|
||
format, each email is given a unique filename and stored in a hierarchy
|
||
of folders within your account. This is often how your emails are stored
|
||
on your provider's mail server.
|
||
~pythonfile~ is used here to authenticate with the remote server. This can
|
||
be complicated and depends /entirely/ on how you manage your passwords. I
|
||
use [[https://keepassxc.org/][KeePassXC]] and love it. When I set OfflineIMAP up, however, it didn't
|
||
have ~libsecret~ compatibility. This would have made setup significantly
|
||
easier but, as it already just works™, I don't really see a reason to
|
||
change it.
|
||
|
||
This new feature allows ~libresecret~-based applications to query
|
||
KeePassXC for your passwords or store them there on your behalf. CLI/TUI
|
||
applications that need a secure mechanism for background authentication
|
||
can use ~secret-tool lookup Title "TITLE_OF_PASSWORD"~ as the password
|
||
command. See [[https://github.com/keepassxreboot/keepassxc/pull/2726][the pull request]] for more details. Because this wasn't a
|
||
feature when I first set it up, I put my passwords in plaintext files
|
||
and encrypted them with the GPG key stored on my YubiKey. As long as my
|
||
key is plugged in, OfflineIMAP can authenticate and download all my
|
||
emails just fine. The process for using a GPG key /not/ stored on a
|
||
hardware token is pretty much the same and I'll talk about that process
|
||
instead.
|
||
|
||
These are the contents of my ~~/.offlineimap.py~.
|
||
|
||
#+BEGIN_SRC python
|
||
#! /usr/bin/env python2
|
||
from subprocess import check_output
|
||
def get_pass(account):
|
||
return check_output(["gpg", "-dq", f" ~/.mail_pass/{account}.gpg"]).strip("\n")
|
||
#+END_SRC
|
||
|
||
This runs ~gpg -dq ~/.mail_pass/use_exa.gpg~ then strips the newline
|
||
character before returning it to OfflineIMAP. ~-d~ tells GPG that you're
|
||
passing it a file you want decrypted and ~-q~ tells it not to give any
|
||
output other than the file's contents. For a setup that works with this
|
||
Python script, put your passwords in plaintext files with the account
|
||
name as the file name (e.g. ~use_exa~). You'll then encrypt it with ~gpg
|
||
-er <YOUR_KEY_ID> use_exa~. Running ~gpg -dq use_exa.gpg~ should display
|
||
your password. Repeat for every account and store the resulting files in
|
||
~~/.mail_pass/~.
|
||
|
||
The other option, ~sync_deletes~, is whether or not to delete remote
|
||
emails that have been deleted locally. I enabled that because I want to
|
||
have easy control over how much remote storage is used.
|
||
|
||
Here's the next block again so you don't have to scroll up:
|
||
|
||
#+BEGIN_SRC text
|
||
[Repository use_exa-remote]
|
||
type = IMAP
|
||
remotehost = imap.example.com
|
||
starttls = yes
|
||
ssl = no
|
||
remoteport = 143
|
||
remoteuser = user@example.com
|
||
remotepasseval = get_pass("use_exa")
|
||
auth_mechanisms = GSSAPI, XOAUTH2, CRAM-MD5, PLAIN, LOGIN
|
||
maxconnections = 1
|
||
createfolders = True
|
||
sync_deletes = yes
|
||
#+END_SRC
|
||
|
||
This one's pretty self-explanatory. ~type~, ~remotehost~, ~starttls~, ~ssl~, and
|
||
~remoteport~ should all be somewhere in your provider's documentation.
|
||
~remoteuser~ is your email address and ~remotepasseval~ is the function that
|
||
will return your password and allow OfflineIMAP to authenticate. You'll
|
||
want enter the name of your password file without the ~.gpg~ extension;
|
||
the script takes care of adding that. Leave ~auth_mechanisms~ alone and
|
||
the same for ~maxconnections~ unless you know your provider won't rate
|
||
limit you or something for opening multiple connections. ~sync_deletes~ is
|
||
the same as in the previous block.
|
||
|
||
Copy those three blocks for as many accounts as you want emails
|
||
downloaded from. I have 510 lines just for ~Account~ and ~Repository~ blocks
|
||
due to the number of address I'm keeping track of.
|
||
|
||
*** ~notmuch~
|
||
[[https://notmuchmail.org/][~notmuch~]] is /a fast, global-search, and tag-based email system/. This
|
||
what does all of our organisation as well as what provides the "virtual"
|
||
mailboxes NeoMutt will display later on. Configuration is incredibly
|
||
simple. This file goes in ~~/.notmuch-config~.
|
||
|
||
#+BEGIN_SRC text
|
||
[database]
|
||
path=/home/user/mail/
|
||
|
||
[user]
|
||
name=Amolith
|
||
primary_email=user@example.com
|
||
|
||
[new]
|
||
tags=unread;new;
|
||
ignore=Trash;
|
||
|
||
[search]
|
||
exclude_tags=deleted;spam;
|
||
|
||
[maildir]
|
||
synchronize_flags=true
|
||
#+END_SRC
|
||
|
||
First section is the path to where all of your archives are, the ~[user]~
|
||
section is where you list all of your accounts, ~[new]~ adds ~tags~ to mail
|
||
notmuch hasn't indexed yet and ignores indexing the ~Trash~ folder, and
|
||
~[search]~ ignores mail tagged with ~deleted~ or ~spam~. The final section
|
||
tells ~notmuch~ to add maildir flags which correspond with ~notmuch~ tags.
|
||
These flags will be synced to the remote server the next time
|
||
OfflineIMAP runs and things will be somewhat organised in your webmail
|
||
interface.
|
||
|
||
After creating the configuration file, run ~notmuch new~ and wait for all
|
||
of your mail to be indexed. This could take a short amount of time or it
|
||
could take minutes up to an hour, depending on how many emails you have.
|
||
After it's finished, you'll be able to run queries and see matching
|
||
emails:
|
||
|
||
#+BEGIN_SRC text
|
||
$ notmuch search from:user@example.com
|
||
thread:0000000000002e9d December 28 [1/1] Example User; Random subject that means nothing
|
||
#+END_SRC
|
||
|
||
This is not terribly useful in and of itself because you can't read it
|
||
or reply to it or anything. That's where the Mail User Agent (MUA) comes
|
||
in.
|
||
|
||
*** ~afew~
|
||
[[https://afew.readthedocs.io/en/latest/][~afew~]] is /an initial tagging script for notmuch/. After calling ~notmuch
|
||
new~, ~afew~ will add tags based on headers such as ~From:~, ~To:~, ~Subject:~,
|
||
etc. as well as handle killed threads and spam. The official [[https://afew.readthedocs.io/en/latest/quickstart.html][quickstart
|
||
guide]] is probably the best resource on getting started but I'll include
|
||
a few tips here as well.
|
||
|
||
*** NeoMutt
|
||
*** ~msmtp~
|
||
~msmtp~ is what's known as a /Mail Transfer Agent/ (MTA). You throw it an
|
||
email and it will relay that to your mail provider's SMTP server so it
|
||
can have the proper headers attached for authentication, it can be sent
|
||
from the proper domain, etc. All the necessary security measures can be
|
||
applied that prevent your email from going directly to spam or from
|
||
being rejected outright.
|
||
~msmtp~'s configuration is also fairly simple if a bit long, just like
|
||
OfflineIMAP's.
|
||
|
||
#+BEGIN_SRC text
|
||
# Set default values for all following accounts.
|
||
defaults
|
||
|
||
# Use the mail submission port 587 instead of the SMTP port 25.
|
||
port 587
|
||
|
||
# Always use TLS.
|
||
tls on
|
||
#+END_SRC
|
||
|
||
This section just sets the defaults. It uses port 587 (STARTTLS) for all
|
||
SMTP servers unless otherwise specified and enables TLS.
|
||
|
||
#+BEGIN_SRC
|
||
account user@example.com
|
||
host smtp.example.com
|
||
from user@example.com
|
||
auth on
|
||
user user@example.com
|
||
passwordeval secret-tool lookup Title "user@example.com"
|
||
#+END_SRC
|
||
|
||
This section is where things get tedious. When passing an email to
|
||
~msmtp~, it looks at the ~From:~ header and searches for a block with a
|
||
matching ~from~ line. If it finds one, it will use those configuration
|
||
options to relay the email. ~host~ is simply the SMTP server of your mail
|
||
provider, sometimes this is ~mail.example.com~, ~smtp.example.com~, etc.
|
||
I've already explained ~from~, ~auth~ simply says that a username and
|
||
password will have to be provided, ~user~ is that username, and
|
||
~passwordeval~ is a method to obtain the password.
|
||
|
||
When I got to configuring ~msmtp~, [[https://keepassxc.org/][KeePassXC]] had just released their
|
||
~libsecret~ integration and I wanted to try it. ~secret-tool~ is a command
|
||
line tool used to store and retrieve passwords from whatever keyring
|
||
you're using. I think KDE has ~kwallet~ and GNOME has ~gnome-keyring~ if
|
||
you already have those set up and want to use them; the process should
|
||
be quite similar regardless.
|
||
|
||
As mentioned above ~secret-tool~ stores and retrieves passwords. For
|
||
retrieval, it expects the command to look like this.
|
||
|
||
#+BEGIN_SRC text
|
||
secret-tool lookup {attribute} {value} ...
|
||
#+END_SRC
|
||
|
||
I don't know what ~kwallet~ and ~gnome-keyring~'s attributes are but
|
||
this can be used with KeePassXC by specifying the ~Title~ attribute. If
|
||
the password to your email account is stored in KeePassXC with the
|
||
address as the entry title, you can retrieve it by simply running...
|
||
|
||
#+BEGIN_SRC text
|
||
secret-tool lookup Title "user@example.com"
|
||
#+END_SRC
|
||
|
||
If you have a different naming system, you'll have to experiment and try
|
||
different things; I don't know what KeePassXC's other attributes are so
|
||
I can't give other examples.
|
||
|
||
You could also just use the same method I described in [[*Repository][the Repository
|
||
section]]! It will work perfectly fine here as well.
|
||
|
||
#+BEGIN_SRC
|
||
passwordeval gpg -dq ~/.mail_pass/use_exa.gpg
|
||
#+END_SRC
|
||
|
||
Now that the whole block is assembled, copy/paste/edit for as many
|
||
accounts as you want to send email from.
|
||
|
||
*** Summary
|
||
|
||
*** TODO Pong fluffy when finished
|
||
|
||
** TODO Making yourself overly available
|
||
|
||
*** References
|
||
[[https://www.nytimes.com/2021/03/05/opinion/ezra-klein-podcast-cal-newport.html?showTranscript=1][Stop. Breathe. We Can’t Keep Working Like This.]]
|
||
|
||
*** Notes
|
||
**** Get rid of information that isn't important
|
||
**** Escalate the info that is
|
||
**** Set /clear/ boundaries for when you are available
|
||
**** Enforce those with automatic DnD rules or use timers
|
||
**** With groups...
|
||
***** Specialisation is /good/ and should be /encouraged/
|
||
***** /All/ of the above points apply with coworkers as well
|
||
|
||
*** TODO Pong Jake when finished
|
||
|
||
** TODO Catchy title about Supernote being "the new paper" :Supernote:Writing:Productivity:Organisation:
|
||
:PROPERTIES:
|
||
:EXPORT_FILE_NAME: something-about-supernote
|
||
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
|
||
:END:
|
||
|
||
I like writing things down. I like the feel of the pen (preferably a
|
||
fountain pen) glide smoothly over the paper, that nice solid feeling of
|
||
the tip against the table, seeing the ink dry as it flows from the nib,
|
||
accidentally swiping my hand through it before it's finished and
|
||
smearing a bit of ink across the page, cursing under my breath as I dab
|
||
it up with a handkerchief or a napkin or something else nearby. I also
|
||
love that writing things by hand [[https://journals.sagepub.com/doi/abs/10.1177/0956797614524581][has an impact on memory and improves
|
||
retention]].
|
||
|
||
*** The problem
|
||
Unfortunately, I don't love keeping up with that paper. Across many
|
||
different classes, even with dedicated folders for each one, something
|
||
important inevitably gets lost. Notebooks are also bulky and can take up
|
||
a lot of space. I tried [[https://bulletjournal.com/][bullet journalling]] for about a month earlier
|
||
this year and, while the process was enjoyable, the maintenance was not.
|
||
My brain moves faster than my pen (even though I have terrible
|
||
handwriting) and I inevitably forget letters or even whole words. This
|
||
is a problem while writing in pen because white-out looks ugly and I
|
||
dislike wasting whole pages because of a couple mistakes.
|
||
|
||
The obvious solution here is to get an iPad with an Apple Pen, right?
|
||
Right??
|
||
|
||
Wrong because Apple bad[fn:2].
|
||
|
||
*** The solution
|
||
Enter the world of ... what are they even called? E-ink notebooks? Paper
|
||
tablets? E-R/W[fn:1]? Do they even have a "device category" yet? I don't
|
||
know but they solve my problem in a wonderful way.
|
||
|
||
As the names suggest, these are devices that can /usually/ open and read
|
||
e-books (EPUBs, PDFs, etc.), annotate them, and create standalone pages
|
||
of notes as if they were full notebooks. The most well-known of these
|
||
devices is likely the [[https://remarkable.com/][reMarkable]]. They had a [[https://venturebeat.com/2019/10/08/remarkable-raises-15-million-to-bring-its-e-paper-tablets-to-more-scribblers/][hugely successful
|
||
crowdfunding campaign]] and produced the reMarkable 1, followed by [[https://blog.remarkable.com/remarkable-2-the-next-generation-paper-tablet-91b47d0080cb][the
|
||
reMarkable 2 in 2020]]. There are a few others by now but we'll look at
|
||
the reMarkable first.
|
||
|
||
*** The reMarkable
|
||
This device boasts all of the features I was looking for. It renders
|
||
digital content, from books and manuals to comics and light novels,
|
||
allows you to mark those documents up as you would if it were physical
|
||
media, create full notebooks of hand written text, organise them,
|
||
search, and, if your handwriting is legible enough (mine certainly is
|
||
not), perform OCR on your notes and email a transcription to yourself.
|
||
It even runs Linux and the developers have opened SSH up so you can
|
||
remote in and tinker with it as much as you like. Because of this,
|
||
there's a pretty awesome [[https://github.com/reHackable/awesome-reMarkable][community of people creating third-party tools
|
||
and integrations]] that add even further functionality. My favourite is
|
||
probably [[https://github.com/bordaigorl/rmview][rMview]], a really fast VNC client for the reMarkable that allows
|
||
you to view your device's screen on any computer.
|
||
|
||
After watching all of [[https://www.youtube.com/c/MyDeepGuide][MyDeepGuide's]] [[https://www.youtube.com/playlist?list=PLsSI9-gaSSmiXwb7Vjk5Vb-nB41UTnrXd][extensive playlist on the
|
||
reMarkable]], however, I decided to go with a different product.
|
||
|
||
*** Enter the Supernote A5X
|
||
The [[https://www.supernote.com/#/product?type=SN-A5-X][Supernote A5X]] has all of the basic features the reMarkable has:
|
||
reading documents, writing notes, and organising your content. Its
|
||
implementation, on the other hand, seems to be much more polished. It
|
||
also lacks some features from the reMarkable while adding others.
|
||
|
||
*** Operating System
|
||
While the reMarkable runs Codex[fn:3], a /"custom Linux-based OS
|
||
optimised for low-latency e-paper"/, the Supernote just runs Android.
|
||
There are both benefits and detriments to this; on one hand, they're
|
||
running all of Android, bloated that it is, on a very lightweight
|
||
tablet. On the other, they don't have to develop and maintain a custom
|
||
operating system. This allows them to focus on other aspects that are
|
||
arguably more important so I don't actually mind that it runs Android.
|
||
|
||
The only place that Android stands out is in system operations; file
|
||
transfer uses MTP and, when you swipe down from the top of the device, a
|
||
small bar appears as in early Android. This lets you change WiFi
|
||
networks, sync between the companion app on your LAN, the remote
|
||
servers, take a screenshot, search, and access the system settings.
|
||
Nothing else about the device really makes me think of Android.
|
||
|
||
*** Community
|
||
I don't usually browse Reddit but [[https://old.reddit.com/r/Supernote/][the Supernote community]] there is
|
||
fascinating. I haven't looked around enough to know exactly what his
|
||
relationship is with the company, but one of the members, [[https://old.reddit.com/user/hex2asc][u/hex2asc]],
|
||
seems to represent Supernote in something of an official capacity. He's
|
||
incredibly active and usually responds to posts and questions within a
|
||
couple of days.
|
||
|
||
Before I purchased one, [[https://old.reddit.com/r/Supernote/comments/lhffyd/sync_targets_open_document_formats_and_crossnote/][I wrote a post]] asking about a couple of things
|
||
that concerned me: sync targets, open document formats, and cross-note
|
||
links. I don't ever plan to write full documents with a keyboard on the
|
||
Supernote but it would still be nice. The other features would be
|
||
absolutely killer for me as I would like to maintain a Zettelkasten (I
|
||
wrote about [[/vim-as-a-markdown-editor/][using Vim to do so]] last year but didn't end up sticking with
|
||
it) and manage document synchronisation with my own Nextcloud server.
|
||
The community was quick to respond and confirm that Zettelkasten
|
||
functionality would be implemented soon™. u/hex2asc responded /the day
|
||
after/ and said that WebDAV would be supported but not earlier than May,
|
||
ODF would likely not be supported, and cross-note links were definitely
|
||
a possibility. Another community member has been avidly following the
|
||
subreddit and even put together an [[https://app-rm.roadmunk.com/publish/03e6dca3d769e2b7015f7f48a649cb3f75f44d9e][unofficial roadmap]].
|
||
|
||
*** Interfaces
|
||
|
||
**** Home & Organisation
|
||
|
||
***** TODO Record very short videos
|
||
|
||
**** Settings
|
||
|
||
***** TODO Record very short videos
|
||
|
||
**** Writing & Annotating
|
||
|
||
The following images are screenshots of the full page above with the
|
||
possible UI variations while reading a book. This first one is default,
|
||
with the editing bar at the top. It is exactly the same as what's
|
||
displayed on the blank pages for hand writing full notes. From left to
|
||
right is the Table of Contents toggle, the pen tools (fineliner,
|
||
"fountain" pen[fn:5], and highlighter), the erasers, lasso select tool,
|
||
undo/redo, context menu, palm rejection toggle, previous page, goto
|
||
page, next page, and exit.
|
||
|
||
[[/assets/pngs/supernote-reader-default.png]]
|
||
|
||
You can hold your finger on that bar and drag it down to detach it from
|
||
the top. The default width exposes all the tools without whitespace. You
|
||
can move it around the screen by dragging the circle with a straight
|
||
line through the middle on the far left.
|
||
|
||
[[/assets/pngs/supernote-reader-medium.png]]
|
||
|
||
If you tap that circle, the width shrinks and everything except the
|
||
pens, erasers, and undo/redo buttons are hidden. It can be dragged the
|
||
same was as in the previous image and tapping that circle will expand
|
||
the bar again.
|
||
|
||
[[/assets/pngs/supernote-reader-small.png]]
|
||
|
||
The last mode is with the bar completely hidden. You achieve this just
|
||
by dragging it to the right edge of the screen. Once hidden, you can
|
||
swipe right to left from the edge and it will be revealed flush with the
|
||
right edge.
|
||
|
||
[[/assets/pngs/supernote-reader-minimal.png]]
|
||
|
||
*** Experience
|
||
**** Reading content
|
||
I love e-ink. I think it looks beautiful and would love to have an e-ink
|
||
monitor[fn:4]. That said, the Supernote has an especially nice display
|
||
with 226 PPI (pixels per inch). The image below was taken with my
|
||
phone's camera so it's not very good. However, if you zoom in a bit, you
|
||
can see that the curved edges of some letters are /slightly/ pixellated.
|
||
Viewing with my naked eye at a comfortable distance, it does look better
|
||
/to me/ than some of my print books.
|
||
|
||
[[/assets/pngs/supernote-resolution.png]]
|
||
/At the moment,/ I am pretty disappointed with Table of Contents detection
|
||
for ePUBs. A great many of my books seem to use a legacy ToC format that
|
||
the Supernote sees and tries/fails to read before attempting to read the
|
||
more recent
|
||
|
||
**** Writing notes
|
||
I write notes as often if not /more/ often than I read and annotate books.
|
||
It's the main reason I purchased the device and I love the experience.
|
||
|
||
**** Surfacing Content
|
||
|
||
*** TODO Pong Isi and Volpeon when finished
|
||
|
||
** TODO Setting LXC up for local "cloud" development
|
||
* Education :@Education:
|
||
** TODO Homeschooling
|
||
* Music :@Music:
|
||
* Pipe Smoking :@Pipe__Smoking:
|
||
* Dungeons & Dragons :@Dungeons__and__Dragons:
|
||
|
||
* Footnotes
|
||
|
||
[fn:5] It's not really a fountain pen even though that's what they call
|
||
it; it's just pressure-sensitive.
|
||
|
||
[fn:4] While this would be absolutely awesome, it would also be
|
||
prohibitively expensive and difficult to write software for. E-ink
|
||
displays are /far/ from cheap and the incredibly low refresh rate would
|
||
render usual computing habits ... odd. For example, words wouldn't show
|
||
up right as you type them; the delay there would be significant and the
|
||
same goes for a mouse. The idea is nonetheless compelling.
|
||
|
||
[fn:3]Taken from their [[https://support.remarkable.com/hc/en-us/articles/360006699537-About-reMarkable-2-][support page about the reMarkable 2]]; search the
|
||
page for /operating system/ and it should show up.
|
||
|
||
[fn:2]I dislike Apple's operating system, their hardware, business
|
||
model, privacy practises, and much of what they stand for as a company.
|
||
Don't @ me.
|
||
|
||
[fn:1]E-R/W is a play on media commonly being labelled as R/W when you
|
||
can read from it and write to it.
|