Often I share a screen recording so that others can follow along with tips, processes and generally shared knowledge. However the screen recordings produced by macOS are huge! Here’s how to share smaller recordings, using the command-line version of HandBrake and Hazel:
Rule details
By default new recordings are dropped on the Desktop. Create a new Hazel rule monitoring new files in the Desktop directory:
If all of the following conditions are met:
- Name starts with “Screen Recording”
- Extension is “mov”
- Size is less than “500 MB” (this excludes large recordings)
Do the following to the matched file or folder:
- Add tags “Red” (to indicate the file is being processed)
- Run shell script “embedded script” (see below)
- Move to folder “Trash” (delete the original)
Embedded Script
handbrakecli --preset="Web/Gmail Large 3 Minutes 720p30" -i "$1" -o "$1.mp4"
My last 48 second recording clocked in at 408KB, not bad.
WordPress Tavern makes a case for why accessibility matters in WordPress. In the meantime some of us have been discussing this for 25 years, and so have something to say about it.
The main problem with accessibility is the term itself. What we are actually talking about here is a universal user experience.
The industry needs to stop selling accessibility as a checkbox and we need to stop viewing it as something extra to do. Inherently every feature and decision we make is already more or less accessible — it is not an on/off switch.
By applying the inversion principle, we should look at what barriers are preventing people from using our websites to the fullest extend, and code all future solutions with these lessons learned.
Aiming for anything less than universal access also makes little economic sense. Let’s ask ourselves: why make a theme and then make it hard to use on purpose? Why make a theme and only allow a subset of people to use it? Do you only allow people with a first name in the first half of the alphabet to log in to your site? Let’s not artificially limit the versatility of the web.
A universal experience should be expected now, and when someone cannot use your site it is a bug. Your site is not inclusive when people cannot use it.
With Sync Library (previously iCloud Music Library) enabled, simply move the file into the iCloud Drive > Music folder.
This setting can be enabled in Settings > Music > Library > Sync Library.
Ringtones are m4a files renamed to m4r, with a length under 30 seconds.
The ringtone can then be selected at the Settings > Sounds > Sounds and Vibration Settings > Ringtone list.
Enjoy the WordPress fun while it lasts folks, I’ve seen the light, and I am worried.
Automattic and the community are spending millions and millions on building a more useful but buggy JS editing interface for the web to make publishing rich documents passable. It can’t get a close button aligned on a modal, or scroll correctly in a mobile device. Basically, Gutenberg is a lesser version of Word 97. It’s not their fault, the browser stack is a brittle way to build apps. We’ve collectively stretched web technologies past what they’re best used for – there are no JavaScript native widgets that can compete with what the OS offers itself. It turns out the web excels to read documents, not write them. I know how it sounds, I’m writing this in the same editor! But we’re on the wrong path:
Because, while everyone is looking to the left at SquareSpace and Wix, trying to figure out how to improve the publishing workflow, on the right Alejandro Crosa builds an iOS app that publishes notes online by simply saving them. It abstracts the whole publishing process. Similarly to how Dropbox abstracted the filesharing site, a native app removes the web editor. In. Three. Weeks. Using Rails and Swift!
In 3 weeks he did a (subjectively) better job for this use case than the WP app and the WB mobile experience. Just look at it collectednotes.com and it’s blog — the latter which is written using the service itself!). Yes it does less, but it’s about the job to be done. Gutenberg does less than Word 97 and Dreamweaver. The point is, that’s fine.
WP is currently deciding whether the REST API should be open to third party editors. It’s mission is to democratise publishing, but somehow this is up for discussion. However it turns out the best experience is a native one. Should WP forego the admin interface, change Gutenberg’s full site editing into the theme editor, and restructure itself for what’s to come? WP has a lot of moving parts, and consensus isn’t easily reached. It seems to me that the web will experience will refocus on reading documents, with content creation in apps.
If Apple ever adds a backend service to Pages to sync with a static site generator, or someone goes 10% further than iA Writer’s web-publishing feature in a ‘writing app’ than the whole WP ecosystem is sherlocked.
It’s time to wake up.
