Lessons Learned on Maintaining our Cohousing Community’s Newsletter

We got several compliments on the Dec 2022 newsletter I did for our Bull City Commons Cohousing community.

So I thought I’d put down here a few things that I do and a few lessons learned along the way. This post may be helpful to cohousing or other communities wanting to start their own newsletter.

I’ve been writing the Bull City Commons Cohousing newsletter since December 2019 or thereabouts when I took over from the former editor. You can see the newsletter’s evolution on our newsletter archives page.

Mailchimp

A former community member started the newsletter on Mailchimp. Because we’re always economizing, we use the free tier that has just enough functionality to get you going, but with the fancier tools (such as AI-powered scheduling of mailings) always out of reach.

Mailchimp is powerful and highly customizable, but it, like many online products and services in this age, is geared to the needs of commerce, business, online selling, and full-on marketing. As such, it’s got an arsenal of tools like audience segmentation and A/B testing that experienced marketers know how to manipulate. As a result, its interface can be forbidding and intimidating.

It’s true that BCC’s early years were dedicated to marketing and selling units. But because we were at the free tier—and because we were civilians doing this in our spare time after the rigors of the $DAYJOB—no one knew how to learn or how to leverage Mailchimp’s formidable firepower.

And while Mailchimp’s interface offers several templates and ways to get started designing a newsletter, it took several issues to learn the basics. For example, pictures spanning the whole width of the design needed to be resized on my Mac to 564px before importing into Mailchimp, or 264px if they were half-width. Mailchimp has a way to resize pictures in its own interface but I found it too arcane and frightening to use; I often found myself cropping an image instead of resizing it.

I’m not ashamed to say I paid for Paul Jarvis’ Chimp Essentials course so I could come to grips with Mailchimp. It was very helpful in explaining to me the basics so I could grok the Mailchimp concepts of audiences, campaigns, all sorts of stuff. (Jarvis sold the course to others and it exists now on Udemy as Mailchimp For Newbies: A Complete Mailchimp Course. Still worthwhile, I think, if you want to get a fast head start.)

In retrospect, all we needed was a database where people could easily subscribe or unsubscribe, a way to schedule the publication, and a way to design and assemble a simple newsletter with words and pictures. Mailchimp was over-engineered for our simple purposes.

Were I to start a newsletter today, I’d probably go with a simpler system like Buttondown or Substack if they had a free tier of service or a low annual cost.

Wix web site

I believe the same former community member who signed us up for the Mailchimp signed us up for a Wix web site.

The original pages were functional and looked very homemade. A few years ago, a few of our design-savvy members did a total overhaul of the site and today it looks great.

As far as the interface: none of the online web-building sites are easy to use if you’re a newbie (I’ve used Squarespace also, and it has its own quirks), and Wix is no different. Adapting to any of these platforms them takes time to understand how it works. It’s like how you need to spend time playing a game to understand its physics and rules so that you can both leverage and subvert them; it takes time and a lot of playing around.

When I took over the newsletter, I knew I wanted to leverage the web site. I saw the newsletter as a light, more mobile news delivery system, while the website could hold longer articles, bigger photos, etc. My early newsletter issues included the first few paragraphs of a longer story that was continued with a “Read more on the web site” link.

With the redesign, we included a real blog. I use the blog heavily and try as often as possible to link from the newsletter to individual blog posts.

Someone in our group suggested we go to Wordpress to save $$$ but that would be a mistake in my view. When I had a WP blog on my own server, I was always having to deal with Wordpress security issues. Also, to make Wordpress useful, you need to add extensions and plugins; the more of those you add, the slower the site runs and I think loses some stability, as well.

By contrast, right out of the box, Wix includes a blog, photo galleries, ability to upload video files, and more. One of the Wix features we use extensively is its Events functionality. We can create an event, users can RSVP, they get an automated email thanking them for the reservation, and then receive another automated reminder email three days before the event.

You could maybe do all that in WordPress but it would take time to figure out, time to research if it’s even possible, time to make it work, time to maintain it, and so on. There comes a point where you have to ask yourself how much your time is worth. For that reason alone, Wix is worth about $250/yr.

Also, for whatever reason, Wix is not a hacker target the way Wordpress is. Or at least Wix does a very good job of making their site secure and handling the security so that we don’t have to worry about that.

For us, Wix has a good set of features that saves us time, so it’s worth the cost as our website is our brochure to the world and potential members.

There are other site-building tools, of course, like Weebly, but I don’t have experience with them; there are scads of systems out there.

The December 2022 Newsletter

The innovation with this edition of the newsletter is that it’s composed entirely of squibs and summaries that link out to all the stories on the blog. So all I needed to do to assemble the newsletter was link out to specific blog posts.

Previously, the blog was either not there or I was delinquent in updating it, so the newsletters always had original stories and pix, sometimes long stories, etc. I didn’t mind that too much, as I wanted the newsletter subscribers to get something a little extra that the blog readers did not get.

But that meant the newsletters sometimes were way too long and became a bit of a slog to read. Stories are OK being long on the blog, though, which means the newsletter can be more streamlined than before. Hit the Page Down key, and you see photos and short blocks of text, making the experience more visually pleasing. From a user’s perspective, they can skim through the newsletter, get a sense of the whole without needing to read too much, and it’s only 2 or 3 screens long. If they want to delve deeper on a specific story, they can choose to click the link and read about it; if they don’t, they can easily skip it.

I subscribe to a lot of newsletters and totally swiped this layout from one of those. The streamlined design meant I was able to compile this edition in about 90 minutes. In the old days, pre-blog, it would usually take me 6-10 hours to create the newsletter because i’d be writing stories, searching for pictures, etc. all at the same time. Writing blog posts still takes time, but it’s 1-2 hours per story spread out over a month or two, instead of all banged up together into a single weekend.

Because I’m always procrastinating, the fewer decisions I have to make, the better. For that reason, I tend to accept the Mailchimp design defaults for fonts, etc. I could specify those things if I was really anal about it, but I’m not. I simply duplicate the previous newsletter in Mailchimp, and re-use the text and image blocks for the next one.

And anyway, Mailchimp designs are supposedly built to look good on laptop, tablet, and phone, so the less I specify about the design the better it probably looks. (Wix layouts also support multiple devices.)

One of Mailchimp’s integrations I take advantage of is publishing the newsletter to BCC’s Facebook page on publication. I don’t know if Buttondown or Substack do that, but it’s handy when trying to propagate the newsletter to larger audiences.

A Final Caveat

I would add that, if you do set up a newsletter/web site for your community, be prepared to be The One who will always be responsible for it. I happen to be technically savvy, which is handy, but I’m also now the unelected historian/reporter for our community. It’s unlikely I’ll ever be able to hand off the newsletter and blog duties to anyone else.

Timecube

When I’m actively working heads-down on a project, such as writing a newsletter or doing some tech workon the laptop, I set my timecube for 60 minutes. It reminds me to get up, walk around, and maybe get some fresh ideas on whatever problem I’m trying to solve.

When I’m not actively working on anything and am just cherry-picking tasks or winging it, I set the timecube for 60 minutes to remind me to get up, walk around, and not get lost in my head and in the internet.

Todays definition of bliss: cold and overcast rainy day, drinking coffee while reading my Sunday comics, Liz working tangrams, comforting and familiar Christmas music in the background.

Lessons Learned: Creating a slideshow in iMovie

Background

Our community held an appreciation evening for our architects and Durham Central Park Cohousing, whose members mentored us through the journey.

During the planning, someone suggested having a slideshow play in kiosk mode on the TV in the multipurpose room while the party went on in the adjacent Common Dining Room.

And of course, all heads turned to me since I’m the de facto publicity guy who drafts the BCC blog and the (now quarterly) newsletter.

My Approach

When given this task about a month and a half before, I of course procrastinated. Well, not all the time; I was quite busy at the $DAYJOB and with other BCC and personal assignments that creating this show was not priority. I also trusted my inner guidance to let me know what to do and when I needed to do it.

But one still needs to make decisions early on, don’t one? They help to give one a place to start and to set up some useful constraints. Starting with the end in mind, I decided on the following:

  • Keep the show to about 20-30 minutes.
  • No music or other soundtrack, because there would be so much talking and other music playing in the other room.
  • The show would be a blend of still photos and drone footage taken of the construction in progress.
  • It seemed to me the simplest way to compile the photos would be to put them in chronological order; therefore, every photo needed to be accompanied by the month and year the picture was taken. I thought people looking at the pictures would want to know when they were taken.
  • The show (either a movie or a PowerPoint slideshow or some other mechanism) had to play on my MacBook connected via HDMI to the TV.
  • The show would be broken into three main pieces: pre-construction, construction, and then move-in on up to the present day. Even during construction we were having events—such as the beam-signing—so I thought those pictures could be interleaved with the constructions at the appropriate moments in the timeline.

What I Actually Created

An iMovie video slideshow that lasted almost 40 minutes. All photos were watermarked with the image’s creation month and year. The video got good reviews from the folks who saw it, and it brought back some good memories. But it was way too long.

Processing the Images

Did I say I started too late? I started too late.

We had two large stores of image files on our shared Google Drive: one set devoted to construction, one to community events. Fortunately, they were arranged in folders—and sometimes sub-sub-folders—by date. Google Drive is too slow to click and move through, so I tried downloading the folders via my browser, but there were inevitable hiccups with some corrupted files, internet burps, and whatnot.

  • At that point, I searched out and found Cyberduck, which offered a fast and simple way to download those folders to my MacBook.

Now I had lots of folders and subfolders of images. I did not want to have to traverse all those folders; instead, I wanted a single folder with all the pre-construction images, a single folder with all the construction images, and a single folder with all the post-construction images.

  • I searched around and—I still can’t believe this—found exactly what I needed: a MacWorld article from 2011  defining an Automator workflow that moved files out of subfolders to a parent folder, and then deleted the empty subfolders.
  • I selectively used that Automator workflow to pull all those nested files up into a single directory for each category of images I had defined.

Now to process those images: sort them by name? By creation date? How to ensure I’m seeing all the files in the right order?

  • I prefer sorting by name; it just makes things easier all around, especially if I was going to do more post-processing of the files later. Or inserting other images I might find later so they fitted into their chronologically right place.
  • Much searching and trying out of programs led me to PhotoMill, which performed brilliantly.
    • The key first step after ingesting the photos, was to select them all and then select File > File Attributes > Set Creation/Modification Date from Capture Date… This added the necessary metadata to the images for the next step.
    • I created a preset workflow within PhotoMill that changed all the formats—a mix of JPG, PNG, and HEIC—to JPG, renamed all the files to start with each image’s creation date and time in the format YYYY-MM-DD HH:MM, followed by the original filename, and then added the creation Month and Year in a 50% opaque white font in the lower right corner of each image, as shown here.

With a folder of images renamed, sorted, and formatted the way I wanted, all that was left was to … sift.

Because I did not have a detailed outline in mind, and because I wanted to let the materials lead me to where they wanted to go, I felt the only thing to do was to sift through all those images to make a first cut.

So for about an hour or so every day, I sorted through about 3,800 image files. Most were quickly consigned to the Trash.

I totaled the numbers of files I had. If each image lasted 4 seconds on screen, then 4 times the number of files and divided by 60 would tell me how many minutes the show would last. That first cut got me to about 60 minutes, so I knew I had lots more cutting to do.

Creating the Video Slideshow

As I sifted through the files again, I hit on the idea of calling the video “Timelines.” I decided to keep the construction images and event images separate, but staying with the pre-construction and post-construction eras. So there would be smaller timelines playing within the larger timeline narrative. I also decided to stop the show after our celebratory gala in May, after the move-ins had finished and we were ready to enjoy our accomplishment.

During that second round of culling, I created new subfolders for the images and began investigating how to present them. After looking at PowerPoint and other kiosk/slideshow programs, the simplest and most powerful tool to use was iMovie.

I consulted a MacMost video course on iMovie I’d bought a while back to educate myself for another project. Gary very helpfully had several videos dealing with my specific use case, and he refreshed my memory on applying transitions, titles, and other niceties. Using iMovie also let me easily drop in some MP4 and MOV drone videos captured during some of our events and during construction.

We were now at, oh, a day before the event? I reported that I’d have a really good first draft, and figured I’d have most of Saturday to get it mostly good.

Renaming the files as I had done meant that, as I dropped in batches of files, they sorted into the sequence I wanted. Adding the drone videos was also dead easy. And iMovie let me know how long the video was, so I could do more drastic cutting as needed. I had iMovie render low quality videos I used to review what would be the final product.

The MacBook Pro’s M1 processor made very short work of the video creation; on my old iMac, it would have taken maybe 90 minutes. I was so happy I got the Pro.

The video wound up at about 40 minutes, still about 20 minutes too long. I did some cutting and moving chunks around, but did not have a better creative idea to support such a drastic cut. Had I arrived at this point a week earlier, a better idea would have appeared.

What I Would Have Done Differently

  • I could have eschewed watermarking all the photos in favor of using titles or other iMovie captioning. But then, I’d have still had to reference each image’s creation date to get that info correct. So, six of one…
  • I would have foregone sifting through 3,800 images. My process, for better or worse, is to sort through everything. I did find a few great shots that way, but that effort was over the top. As Liz noted, whenever people were not in the pictures, the air went out of the show.
  • In the next draft of this video, I will trim the 15-20 minutes of boring construction photos. Since I named the video “Timelines”, I will instead create more mini-narratives showing the progress, say, of the hallways and the lobby from studs to sheet rock to paint. Those will tell more meaningful stories within the larger construction narrative, and the impact will be greater to see 2 years’ progress on a defined space within the span of a few photos.

Resources