Preaching online

This is, perhaps obviously, a mixture of both the opinions of someone that has sat through too many online sermons (even before the Age of COVID) and the trade of someone that has given too many online conference talks and presentations.

That said, as it pertains to preaching online...

Preachers: Presentation or Parish?

Is this an online-first presentation, or are you using streaming as a tool to connect to your parish? While some recommendations (e.g. worry about audio before video) are universal, many of the recommendations you'll read or hear or see online make assumptions about which of these styles of preaching is your primary goal. I'll do my best to call out those assumptions here, but nothing else matters until you know this answer.

For some folks this is obvious. For others it's a serious consideration. For others still, you'll need both at different times, and so you'll need to build two separate online preaching practices.

Presentations are, by and large, the simpler of the two. Speak to the camera, and use software to record or stream the output. There are dozens of simple tools like mmhmm and Zoom that are optimized for this style of communication, and there are seventy times seven takes online for how to improve them. I'll include a few of the less-obvious highlights and improvements regardless:

  • Frame the camera so that your face is horizontally centered in the frame, but the center of your face should be a third the way down from the top. Place and zoom the camera such that you can see your shoulders.
  • If you use gestures while you speak, make sure those gestures—and you—can be seen! It takes a lot of practice, but the same gestures can be given in a way that frame, rather than obscure, your face, with your elbows close to your side and your hands near your face. It feels weird, but it looks correct.
  • Slides are simple to incorporate into a presentation format, but this is a trap: you're preaching a sermon to folks that are, by default, isolated from one another. Err on the side of connection, rather than just communication.
  • I assume that the "presentation" format is preferred when your congregation cannot gather in the same place. In this case, they are "tuning in" (do people still say that?) from a variety of environments. Keep it short. You don't know what manner of distractions folks are dealing with, so the shorter and simpler you can keep your message, the better. (Even moreso than when in person.)
  • Don't underestimate the lack of feedback. You might be used to "reading" the congregation's response to something, but that is just not feasible, even over "meeting"-style software like Zoom. You're largely on your own, another reason simpler will go better.

Connecting your parish is, in my opinion, significantly harder. You don't want to detract from the experience of those in the pews, but you don't want your online congregants to feel like second-class citizens, either.

The tech you choose (covered below) can certainly help, but your primary job—much like the presenters, above—is to reduce the impact of distractions to those joining remotely, and keep your connection to those online from being a distraction from the message. Keep the format simple to follow. The length of the sermon is, IMO, less of an issue when folks can join in person, but the lengths of the "chunks" becomes more important instead.

  • If you pace while you speak, work with the tech folks to establish a boundary. Otherwise, you're liable to walk off-camera.
  • I cover this below, but work with the tech folks to minimize the need to move or reframe or refocus any given camera. It's hard to do well, time-consuming, and requires skill and practice. In addition, a still camera can help create a sense of "space", thinning the "fourth wall" between you and your online congregation.
  • For that matter, break the fourth wall. Smash it into tiny pieces, and sweep those pieces into the nearest bin. Acknowledge that you have folks online, and welcome them explicitly with your words and actions. Look at the camera on occasion.
  • Microphones are a knowable thing, and the more comfortable you are with the microphone(s) you use, the better the experience will be for everyone. Do you know how to turn it on and off? Could you mute it if you need to cough or go to take a sip? Do you know how to adjust it, if needed? Do you know how to replace the batteries?

No matter the format—presentation or parish—work with your tech folks. Thank them. Listen to them. If your role includes the autonomy to do so, help them understand their budget. Their work might not be literal magic, but they will need your help to balance the hundreds of minor details it takes for the magic trick of making the tech disappear.

Tech: audio

It's a touch counterintuitive, but when you're talking about streaming video, audio matters more. If you're going to spend a little money on gear, spend it on a nicer microphone before you spend it on a camera.

  • Spend some time to make sure sibilants and plosives are clearly understandable without clipping.
  • Have a second microphone that can pick up the preacher in addition to a lapel or lavelier microphone. This is especially useful for guest preachers, and can mean the difference between compensating for bad microphone placement and the AV person running up on stage mid-sermon.
  • Unlike video—we'll get to that—there's no making up for a bad microphone. Get a trusted brand and model of microphone, and save your pennies elsewhere.
  • Check the levels for the full dynamic range. Preachers like to be especially quiet or loud for emphasis, and will underestimate that range during soundcheck unless you tell them otherwise.

Tech: video

A little can go a long way. Often the main limitation with video is not gear, it's placement, focus, and lighting.

  • Place the camera at or above the preacher's eye line, but no more than 15º or so above it. This should be intuitive; no need to get out a protractor.
  • Move the camera as little as possible. It's better to have a second camera you can cut to than to try and reframe or refocus the same camera a dozen times during the service.
  • Keep the preacher in the middle of the frame. Yet again, you could move the camera to keep up with them if they like to move around, but the easier solution is to get some "gaffer's tape" and make an X where you want them to stand. Or a box they should stay within.
  • Make sure there are more lights in front of the pastor than behind to keep them from looking like they're in the Witness To Christ Protection Program. (This is especially relevant for folks preaching from home, an office, etc.) Lights should be level with the camera to as high an angle as 45º above.

Tech: slides

Slides might be the hardest part to implement. Your goal is to make them as simple as possible to run.

The most important decision lies between cutting between camera feed(s) and slides, or trying to superimpose the slides over the video feed. Either requires tech to pull off, but both the slide design and the tech itself need to optimize for one or the other. (If you already know your software is solving this problem for you, skip this section.)

If you're cutting, you're turned a tech setup problem into a communication problem. Make sure the tech team knows when to cut to slides, and when to show the preacher. Some folks will find this intuitive, and others will find it completely baffling without a lot of practice. Pairing them together can help immensely, but doubles the load on your volunteers. Short version: watch the feeds, and cut to the slides when they change (especially if the preacher likes to read from them). Count slowly to 3 when they've finished talking about or referencing what's on the slide, and cut back.

If you're superimposing, you're going to sacrifice legibility for folks in the room. Update slide styling and templates to use the lower quarter-to-third of the screen, with a completely black background. Your software should be able to overlay this on the camera feed, or you can use a device like an ATEM Mini to manage the math. The result should be the text on the bottom, and the preacher behind and above. This setup can lower volunteer burden significantly, as the preacher can now control the overlay. If they're finished being bathed in text, they can transition to an all-black slide.

Other: Recording & Streaming

If you're considering a recording, the closer you can get to the "sensor" (the microphone, the camera) the better the quality will be. Recording from Zoom might be the easiest, but will also be the lowest-quality option.

A good middle ground is to record all audio you're sending (e.g. from the mixer) and the video feed, and combine them in software afterward.

  • If you're using "meeting"-focused software like Zoom, make sure you mute everyone else. Including the "meeting host" or AV team. See if your software has a "Spotlight" feature for the main feed, and use it.
  • If you have other elements you are streaming or recording, take a minute to check the level of the preacher's microphone relative to the other elements. Try to avoid having the preaching be significantly quieter (or louder) than the other elements.
  • If you have a multilingual church, make sure you understand what the experience for translation is for online folks.

Other: Moderation

If you are live-streaming your sermon and the software has a chat feature, make it someone's responsibility to watch it. If you're connecting a parish, make sure they're in the room. If you're presenting, assign a leader or elder to moderate from their own connection.

  • If you have a welcome time or a time for "passing of the Peace", consider using breakout rooms to pair people off randomly. Give them a 60-second warning before you bring them back to the main room. If you're presenting to an all-online congregation, consider adding a time like this if you don't already do so.
  • Otherwise, consider kicking off a chat while folks greet one another in person. Cut the audio to that second microphone I mentioned, to give people a sense of how lively the room is, and lower the volume. If you have just a few folks connected from home, consider having the moderator speak up online, and welcome folks by name.
  • I've never had it happen myself, but it's not unthinkable that someone would crash your live stream. Don't lose sleep over it, but make sure you moderator has a plan for what to do, just like you have a plan for disruptions in your sanctuary. (You do have a plan for that, right?)

A few specific recommendations

  • The Black Magic ATEM Mini is a workhorse on the video side, and scales from a 4-input $300 model to a 16-in, 9-out, $1300 behemoth. Easy to use once you set it up, and Black Magic is a "household" name for video gear.
  • Shure microphones are a good balance of price and performance. If you don't know where to start, look at the SM57, SM58, and MX153. For a bump of quality (and price) for the band, look at the Beta line. If and when you ever outgrow these, you'll know better what you're looking for anyway.
  • You're not getting some unsustainable discount, but Sweetwater's support is second to none. If you're intimidated at all on the tech side, ask them for a "Sales Engineer", who will sit on the phone with you and talk through your needs. Again: you will pay MSRP for your gear. But if it breaks or it doesn't fit your needs, you have a living, breathing human with a name you can call for help. If not that, try to find a local shop to buy through. For these high-cost, niche purchases, Amazon is a minefield of scams and knockoffs. Avoid it.

Other: Closing thoughts

It is my personal opinion that the connectivity provided by the Internet is here to stay, and that God's global Church has been given the gift of gathering across our silly societal boundaries. I also know that these technologies are nascent and changing, challenging us to share solutions and give grace to one another while we figure out how to preach to God's people well in this present age.

Take these points with a grain of salt. Change them to fit your needs. Share them, if they helped.

God bless you in the incredible work you've been invited into.

(Photo by Matt Botsford on Unsplash. Love that site.)

Where the Pomodoros End

At some point in every software developer’s career (and likely so for other knowledge work), they are subjected to a tomato-based hazing ritual known as "the Pomodoro Technique".

The process is always the same:

The Initiate overhears the Senior Engineer Cabal during one of their cloaked rituals—the Morning Standup—as they describe the number of Pomodoros a task will take. During their open office peer one-on-one, the Initiate vocalizes their curiosity of how Italian tomatoes map to man-months, to which the Senior Engineer coyly responds:

  • A Pomodoro is a 25-minute span of uninterrupted work.
  • Each Pomodoro is followed by a 5-minute, uninterrupted break.
  • Use INSERT_TIMER_APP_HERE to keep track of your Pomodoros. All other timer apps suck.

And off the Initiate goes, never to be seen again. Not because they’re working, but because they’re testing alternative Pomodoro tracking apps. Only 173 to go...


Even if this story is only a shoddy attempt at half a polite chuckle, the Pomodoro Technique is both very real, very misunderstood, adored, and occasionally even effective.

But.

What about those interruptions? Leaving distractions—called “internal interruptions” in the lingo—aside for a moment, what are you supposed to do if others interrupt you?

According to the original Scripture, you are supposed to “inform effectively, negotiate quickly to reschedule the interruption, and call back the person who interrupted you as agreed.”

For such a prescriptive schedule of work, there’s nothing to acknowledge when that interruption is to be rescheduled for. Furthermore, as a leader I’m interrupted constantly, so this is not a small issue: it’s core to how I need to work.

  • Do I tackle all interruptions right now? If so, what is this timer doing?
  • Do I reschedule interruptions to take the place of my break? Not much of a break, then, is it? And breaks are why I need something like this!
  • Do I reschedule interruptions for after the next break? If so, does that count as a part of my next Pomodoro, or is this some sort of extrajudicial task?
  • Do I schedule some sort of “Office Hours” like a professor trying to corral a group of hormal late teens? Now you’re just being ridiculous. And that’s coming from me, who’s writing all this nonsense.

Where Pomodoros go to die

Interruptions kill Pomodoros. This is why so much of the language, writing, and culture of Pomodoro users talks about “protecting the Pomodoro.”

When your work is about interruption—when your work is about being the interruptable one—then you yourself have taken the Pomodoro Technique to a farm upstate.

Now what?

I’m still working on the same problem, but the solution I’m using today works better than I initially expected:

Run that timer all day

For a few months now I’ve had a small device running in the corner of my office. On it displays the current time, and most importantly a buzzer goes off at :25 and :55 when it’s “time” to take a break, and at :30 and :00 when that “break” would be over.

Do I actually take those breaks? Almost never, but the little buzzer keeps me informed of the break time I’m missing through my various meetings and interruptions, and my subconscious does a remarkable job of nudging me each time the buzzer goes off just how much of a debt I’ve accumulated. Practically speaking I only get to pay up a couple times a day, but now it’s become a conscious, guilt-free choice both to take the interruption and to take the break(s) I’ve neglected.

When I first started using the Pomodoro Technique circa 2009, my emotional takeaway was the feeling that I’d taken control of my time, no longer controlled by it. My tomato timer may be dead and gone, but this new timer has resurrected that feeling of control and determination, and I look forward to working with it for even longer.

ABRPT: Shuffle Playback by Album

TL;DR: I made a thing! You can shuffle your Spotify Saved Albums here.

Code here.

I have a relatively ecclectic library of music. In the above screenshot is an English electronic band, a French disco artist, and two American bands: one rock, and one bluegrass.

With a library like this, it can be downright jarring to shuffle everything.

Each music app has its own way of dealing with this problem, but none do so completely. Playlists? Terrible if a song fits more than one mood or genre or whatever. Tagging? Way too manual and finicky. Recommendations? Too biased and will eventually converge on one style of music.

I've dealt with each long enough to know how to get them to work, but I had really hoped there was a better way. After more than a decade of these sorts of jagged, jarring, manual, and often lackluster listening experiences, I had an idea: what if I could shuffle my library by album, rather than by song?

I know this isn't a novel idea. I have two of those oldschool, drum-based CD changers, each of which supports this exact feature. That said it's always felt like an ancillary feature, and hard to control. What if I could see a queue of those CDs, filter out CDs that I don't feel like today, etc.?

I have plenty of issues with Spotify. They don't pay their artists enough. It's a terrible solution for long-term library "storage", as they're constantly breaking whether a song or album is Saved to your collection. Their library of music is incomplete in selective ways. Their recommendations are White-centered.

That said they're the best option to try out this idea, and this was an opportunity to try Glitch.

Starting with the latter, I would use Glitch again for this sort of one-off, temporary-by-default project. I don't expect to run anything on Glitch long-term (though I know they support that), but it's fantastic for quickly standing up an experiment. The biggest frustration was using JavaScript and Node again, which I would prefer to continue avoiding in the future.

But using Spotify for this worked great! If you go to the ABRPT app, you can (after Glitch warms up the app) log in with Spotify and see a preview of what random 8 albums ABRPT wants to queue up. Clicking Apply appends those albums (song-by-song due to a limitation of the Spotify API) to the end of your Play Queue.

If you don't have an active Spotify device, this may fail; start Spotify playback on the device you want, and try again.

If you want to check out the code, it's all available here on Glitch. Check it out, and let me know what you think!

Gizmo 21: Today Display

TL;DR: The Today Display holds a single 2.5" by 3" index card, just big enough for the most important notes and tasks for the day. The STL is available on Thingiverse.

This design was inspired by the Analog Kickstarter. I liked the idea of a card holder to localize my daily tasks, but I already have a "productivity system". Everybody does. I already have a rolling backlog of work that needs to be done. Most people do. All I wanted was a card holder.

Furthermore, a full-size index card (3"x5") is too big for a single day's tasks: cutting the cards in half produces just the right size for the most important work I need to accomplish, and nothing more.

Usage

I keep yesterday's card around long enough to help update my team with any leftover notes. With any luck, though, I've spent a few moments at the end of the previous day starting today's card:

At the top of the card, I put the date. Along the left edge of the card are bullets: a dot for a task, and a dash for some critical but not actionable detail. As mentioned above, if I think it won't fit on the card, it belongs somewhere else.

Don't overthink it.

What's With the Logo?

Did you ever have a random idea that you couldn't get out of your head? The most ridiculous, out-of-nowhere idea provides its own rationale as it lives between your ears. So it was with this logo.

Initially I was just playing around with various forms. As with most visual work, I doodled and doodled and doodled. Eventually, I started playing around with two of my favorite characters: the ambersand (&) and the question mark (?).

If you'll excuse my over-the-top nerdiness here, take a second and think about these little things: on the one hand, a visual portmanteau of the Latin word "et", and on the other a "lightning flash" to end a sentence. Beautiful! Unique! Absolutely incredible.

As I was playing with them, I realized you could flip the ampersand, and connect it to the question mark. It was a really fun corruption of those symbols, and it stuck in my brain.

At some point in a project I realized I'm losing steam—maybe it's interest, maybe time, maybe energy—and my solution to that is always the same: lower the bar, and ship. Now that I had a logo idea that I liked, I dropped it into Sketch and shipped it as fast as I possibly could. Plain color. "Good enough" Bezier curves fitting the transition between the two characters. Export to SVG. Move on.

After I deployed it, though, it haunted me a bit: did it "mean" anything? Well, no. Did it need to? Well, no. If it did, what would it?

Again, the logo doesn't mean anything. It's not special. It's an accident, and I love it. But your brain needs it to mean something. If you're like that, too, take your pick:

  • If God has a favorite question, it's "And?" What a model to live up to. "Schoon, I could really use this help." Sure. And? "Schoon, this happened." And?
  • "And" is always better than "but", and a question is always better than a statement.
  • The URL is the backbone of the Internet, and the "query" component of the URL is how you share information via URL. What two characters provide that query structure? The ambersand and the question mark.

And now that I've published even this ridiculous screed, my brain can rest.

HotelCalifornia.js

Thanks to Jason Karns for the title idea. This is mostly edited from a Twitter thread, so for other comments and commentary, see the thread.

I really thought I had finally built a simple, maintainable, modern, single-page application.

Nope.

When I returned to this project after only six months, every build resulted in nothing but errors. Errors as far as the eye could see.

No environment should be this hostile.

At some point I just can't afford to keep trying. JavaScript is an otherwise accessible, easy to learn language (as computer languages go, anyway), and you can be productive very quickly.

You just can't walk away.

Just like Hotel California, you can check into writing a JavaScript application, but you can never leave. You are doomed to repair broken dependency after broken promise, ad infinitum.

I've never experienced anything like this from a programming environment, before or since.

For better or worse, browsers remain a ubiquitous application host, and one required of any business, no matter how small.

So what do you do?

One option might be compile-to-JS, and I want to keep an eye on that space. None of those options are so mature or so stable or so accessible that they can really compete, though! And culturally, they feel just as churn-driven as the environment they hope to replace.

What else?

I've spent a non-insignificant part of my JavaScript career replacing server-rendered applications, but I need to take my small business the other way. Environments like Go and Ruby have a more stable API, and the served-up HTML has FAR more device compatibility.

Why not?

Perhaps ironically, the reason not to is that it feels like untested water. So many modern applications moved away from 100% server rendering, touting it as "faster" and "better for users".

Is that still true? Who is pushing the boundaries of an alternative?

One way or the other, I feel left without a choice. JavaScript libraries, frameworks, and even developers feel hostile, even abusive.

I've used too many to expect the next to be any different, and I've been using them too long to expect them to improve.

I'm disappointed.

I'm disappointed because I really want this ubiquitous, accessible development environment to change.

I'm disappointed because I still feel it WILL change, and I might miss it.

I'm disappointed because I can't wait for it to change to stay here, on the web, making apps.

Project Kong: Reuniting

The final episode of my Project Kong series, a fun (and adorable, if I do say so myself) demonstration of how it works.

Enjoy.

Project Kong: Tracking via Bluetooth

This video touches on the basics of what we need from Bluetooth and the little RedBear we installed earlier in the series: tracking. Bluetooth, particularly the current standard for Bluetooth Low Energy, makes a good platform for wirelessly tracking physical objects.

In our case, BLE is what Kong will use to track the person it's trying to follow and protect; a small wearable on the person makes the individual “visible” to Kong.

Project Kong: What is AI?

This video is an admittedly very shallow dive into the theory of AI, all to support the question, "Where does Kong need to go from here?" If you're looking for a deeper dive, here are a few respources:

  • I lumped quite a few specific algorithms into the general bucket of “heuristics”. For more specific versions of what I was talking about, consider A*, a heuristic based search (specifically path-finding) algorithm.
  • Wikipedia (of course) has a pretty comprehensive article on neural networks.
  • The libraries Donkey Car uses for neural networks: Keras and Tensorflow

Project Kong: Using the RC Controller

This video has our first modification to the Donkey Car; we restore the use of the original remote control. To do so we use a RedBear Duo to read the PWM signals comming from the RC receiver, forwarding them on as control codes over a serial connection made to the Raspberry Pi.

The both the code for the new SerialController part and the firmware for the Duo can be found on the project's GitHub page.

Attribution

The music in this video includes “Sunrise”, “Nameless Beat”, and “DeadBeats” by TazLazuli. Their SoundCloud can be found at https://soundcloud.com/tazlazuli, with Twitter at twitter.com/tazlazuli.

Project Kong: Calibration & Test Drive

The hardware has been assembled. The software has been installed. In this episode, it's time to calibrate that software and take the whole rover for a spin.

This video starts with a quality of life improvement: we move the main power switch for the car itself to a much easier-to-access location. It's been life-changing for the rest of this project. As a part of that section of the video, I show the macroscopic I've used for all the adjustments: “opening up” the car like a book, mounting the custom components to the flat platform, etc.

Also, mounting tape.

After a quick run-through of how to boot everything up, the video walks through the basics of calibration. The original documentation can be found on the Donkey Car website.

Finally, we go for our first test drive! Huzzah!

Attribution

The music in this video includes “Days Like These”, “Golden Hour”, and “In My Dreams” by LAKEY INSPIRED: https://soundcloud.com/lakeyinspired

Project Kong: Installing the Software

With the hardware fully assembled, this episode focuses on installing the software, connecting the car to the local Wi-Fi network, and creating the scaffolding for our Donkey Car project. This is the second of three in this series dedicated to assembling a Donkey Car without modification.

The accompanying documentation can be found on the Donkey Car website, but in particular, the following links will be helpful:

  • The Raspbian image we downloaded in this video can be found here.
  • The Etcher application I used to flash that image to an SD card can be downloaded from their website.
  • Introductory guides to SSH and Nano can be found here and here, respectively.

Attribution

The music in this video is “Elevate” by LAKEY INSPIRED: https://soundcloud.com/lakeyinspired

Project Kong: Assembling the Hardware

The first step for Project Kong is to assemble the hardware sent by Arm for the Donkey Car. This video (originally intended for YouTube) walks through that process.

The actual hardware assembly (i.e. not the intro or outro) was the first thing I recorded for this series, and it may show. That said, I think it's a useful supplement to the official Donkey Car docs.

Best of luck, and do get in touch if you have any issues.

Project Kong: Overview

This video introduces the first videographed project: Kong.

Kong is a small, autonomous, beginner-friendly rover designed to help with elopement in children living on the Autism spectrum. It leverages the Donkey Car platform for the car, adding a RedBear Duo for Bluetooth scanning (and some other, wonderful capabilities revealed later).

JavaScriptural Exegesis

This is a recording from OpenSourceBridge 2017 of my talk, JavaScriptural Exegesis.

I had the privilege of giving this talk twice more: at Bellingham Codes later that fall, followed by LibertyJS in front of the biggest audience I've ever had the pleasure of presenting to. It's a flurry of “out of the text” conclusions drawn from the ECMA-262 Specification, and it was a delight to prepare.

Many thanks to both Test Double and Bellingham Codes for all of their support and feedback.

YouTube Shenanigans

I've been working on a simple video series for months. I've been learning how to shoot, organize, edit, practice, re-shoot, re-edit, render, and export video. I've been prototyping the project being recorded, writing scripts, and rebuilding the project as a one man film crew. I have designed and re-designed title cards and social media icons and banners.

And then I uploaded the above to YouTube.

First, I uploaded it to my personal Google Account, but I realized it would be safer to upload it to a separate, branded account. By YouTube's own recommendation, I created a Brand Account for this content. I uploaded the first few episodes, and went to bed.

The next morning, my account was disabled. No explanation.

In their typical tone, Google “helpfully” suggested I could request my account be reinstated. I did, and went back to waiting.

After a week, they disabled my Google Account (not the Brand Account), and reenabled it. Cue pats on the back.

I've gone through that rigamarole twice more, and still no satisfactory solution or explanation. If you've ever heard me say, “Choose a vendor that cares you exist,” this is exactly what I'm talking about. If this project was reliant on YouTube (to make money, it kinda is), it was dead on arrival, and I have no recourse.

Choose a vendor that cares you exist.

...The End.

View Archives