Tools

A Year of Podcasting: Publishing

| Jorge Arango

I’ve been publishing my podcast, The Informed Life, for over a year. During that time, I’ve had lots of folks ask me about how I do it. To celebrate the milestone (and to avoid repeating myself,) I’ve been writing about my set up: how I started, my recording gear, and how I edit episodes. This post is about how I publish the podcast.

Publishing is a key component of podcasting. You can record and edit an excellent show, but only a few people will listen if it’s not available for folks to find and download. These two things – finding and downloading — are related but not the same. They’re both crucial.

Let’s start with downloading. Mostly, podcasts are like blogs: content that’s published periodically on a web server where people can access it over the internet. The main difference, of course, is that blogs are primarily text-based, whereas podcasts are primarily audio-based. But still, the underlying technologies are very similar.

So-called podcatchers — the apps that we use to listen to podcasts — are RSS readers under the hood, much like blog readers such as NetNewsWire or the much-missed Google Reader. Besides rendering text, podcatchers provide specialized interfaces to listen to audio files. These audio files are referenced in the podcast’s (text-based) feeds, which are almost identical to the text feeds that power blogs.

I’m giving you this preamble to demystify the publishing process. A podcast is just a blog with audio.

That said, there are publishing platforms that provide specialized features for podcasts. For example, some aim to unify (and therefore simplify) the whole process by bundling recording, editing, and publishing features into one package. I didn’t consider such tools because I didn’t want to be locked into any one vertical platform.

My early research turned up one publishing tool that seemed to be preferred by many established podcasters: LibSyn. It’s been around for a long time, as evidenced by its rich feature set. This gave me confidence in the tool. (I’m always wary of relying on untested companies.) Alas, its longevity was also evident in its user interface, which I found clunky and complicated. My understanding of podcasting as “blogging with audio” was put to the test when I opened an account on LibSyn. Setting up the show and publishing a single episode required learning a new set of terms and filling in lots of information. It was more work than I expected or needed.

Hunting for a new publishing platform, I discovered that the one I use to host this site — WordPress.com — could also be used to host podcasts. I opened a new account on WordPress specifically for the show and was pleasantly surprised at how easy it was. (Especially for someone like myself, who was already familiar with blogging in general and WordPress in particular.) Publishing a new podcast episode boils down to writing a blog post and including a single audio file in it. Simple.

Of course, there are tradeoffs. A more powerful tool like LibSyn gives you more features and the ability to control things more granularly. More importantly, WordPress also lags in one key area: statistics. The system provides a dashboard that shows how many people have visited, how many pages they’ve viewed, etc. It’s the same dashboard you get if you’re hosting a blog (note I said “pages viewed”), and it’s wholly inadequate for a podcast. I don’t yet have a good way of knowing what episodes are more popular than others.

Still, it’s convenient to use the same platform for my blog and my podcast. Which is to say, WordPress integrates well with my workflows. It’s simple, inexpensive, and reliable. I’m also confident that WordPress (the company) will be around for a while. It’s unlikely I’ll tinker with this aspect of my setup for a while.

So that’s the “web hosting” part of my publishing setup. But as I mentioned above, putting the show on the internet isn’t all that’s needed: folks also need to find the show so they can subscribe. That’s where podcasting directories come in.

There are several of these, but the most popular is Apple’s podcast directory. Apple embraced podcasting early, including it as a feature in iTunes in 2005. They’ve since maintained a structured index of shows that’s used by other podcasting systems as well.

It’s worth noting that this directory doesn’t host podcasting files; that’s why you need a publishing platform such as WordPress. Instead, the directory allows people to find your show, and to rate and review it. (If you enjoy The Informed Life, it helps if you rate and/or review it in Apple’s podcast directory.)

Google provides a similar service through Google Play, but as far as I know, it isn’t as influential as Apple’s. That said, I added the show to Google’s directory late last year to make it easier to find for Android phone users.

There are several other platforms with directories. I often get requests from folks to include the show on platforms like Spotify and Stitcher. I’ve been wary of these and other such systems. I sense that many are trying to build walled gardens around their podcast initiatives. Some break the decentralized model by re-publishing shows in their hosting infrastructure and inserting advertising into shows. The obvious tradeoff? Not being on these distribution platforms is costing me some listeners. That makes me sad. But some of these practices — especially injecting ads into shows — make me even sadder. As a result, you’re unlikely to find my show in these systems anytime soon.

So there you have it, my podcast publishing setup. Of all the components and systems that make The Informed Life possible, these are the ones I’m most satisfied with. The one exception, as I mentioned above, is statistics. I’d love to have better information about how individual episodes are doing. (Apple provides a tool that’s supposed to give me such information. I didn’t mention it above because it’s not very useful.)

So, better statistics is one aspect I’d like to change about my podcasting setup. In the final post in this series, I’ll tell you about some other things I’m considering for the future of The Informed Life. Hope you can join me then!

Alternatives to 32-bit Apps on macOS Catalina

| Jorge Arango

When a new version of macOS comes out, I usually upgrade my computer relatively soon. I like having access to the latest features, and significant macOS release upgrades are generally trouble-free. That hasn’t been the case with the newest version, Catalina. The trouble stems from the fact that Catalina doesn’t run 32-bit applications. While most major software in the system is now 64-bits, there are still some stragglers — especially legacy apps and drivers that haven’t been (and likely won’t be) upgraded.

That’s why I waited longer than usual before upgrading to Catalina: there was one application in my system that was 32-bits, the driver for my Fujitsu ScanSnap S300M scanner. I knew this driver was incompatible because every time I launched it (under Mojave, the previous version of macOS), I’d get a warning saying that the app would not run in the future. (Here’s a way to learn which apps won’t work: under the Apple menu, go to About this Mac > System Report… > Legacy Software.)

Without this driver, the scanner is useless — even though the hardware is perfectly functional. This device is an important part of my workflow; I use it every other week to digitize most of my paper documents and correspondence. Fujitsu no longer sells this model and has no plans to release 64-bit drivers. So I was stuck. I had two choices: I could hold off on upgrading the operating system (for a while), or I could buy a new scanner. I didn’t like either option. Sooner or later, I’d have to upgrade the OS. And as I said, the scanner itself was in perfect condition; I didn’t need a new one. What to do?

It turns out there was a third option: look for an alternative driver. I found a third-party application called VueScan that works with a range of scanners, including the S300M. It’s been working well for me; the only downside is that it’s a bit slower than Fujitsu’s driver. But given my use of the scanner, it’s not slow enough to merit buying a new device.

Thus far, Catalina has been great. I’m especially enjoying the new Sidecar feature, which allows me to use my iPad as a second screen when I’m on the go. So far, everything is working for me — including my old scanner. The lesson: if you’re contemplating upgrading to Catalina, but are holding back because of legacy software on your system, consider looking for alternatives.

On Google Reader

| Jorge Arango

Yesterday, I tweeted about missing Google Reader:

The tweet touched a nerve; lots of folks have chimed in, mostly agreeing with the sentiment or recommending substitutes.

To be clear, I still read RSS feeds every day. (I use Reeder on the Mac and iOS and synch my feeds using Feedly.) Although I’m open to exploring alternatives, I’m not unsatisfied with my current arrangement. (Ringing endorsement!) So I’m mostly not lamenting the loss of Google Reader’s functionality. Instead, I miss what Google Reader represented: a major technology company supporting a truly decentralized publishing platform.

Google’s brand imparted some degree of credibility to an emergent ecosystem. I suspect a nontrivial number of people must’ve tried RSS feeds because Google provided a tool to read them. It’s great that tools like Feedly, Reeder, Feedbin, NetNewsWire, etc. exist, but none of them have the broad appeal or brand power that Google does.

I said I’m “mostly” not lamenting the loss of Google Reader’s functionality. This is because while current RSS readers offer the basics, Reader was a natural, cohesive component of my personal information ecosystem. Unsurprisingly, it looked and felt like (and integrated with) other Google tools like Gmail and Google Calendar, which I was using extensively at the time. As befit a Google product, Reader also offered excellent search capabilities. None of the RSS readers I’ve tried since offer the same level of coherence and integration that I experienced with Google Reader.

I sense Google Reader was a casualty of Google’s primary business model: selling its users’ attention to the highest bidder. I doubt RSS provided the scale or control required to run a mass advertising business. IMO it’s no coincidence that Google pulled the plug on Reader at a time when centralized social networks (Facebook, Twitter) were gaining traction in the mainstream. (Google+, which the company had launched a couple of years earlier, failed to take off. I wonder if they saw Reader as competition for G+?)

Six years after Google Reader’s disappearance, we’re wiser to the limits of centralized control over news aggregation. Subjectively, I sense many people are rediscovering the joys of blogging. (And, like me, using the social networks mostly as a way to publicize our blog posts.) Podcasts — which are based on syndicated feeds — seem to be more popular every year. While I miss Google Reader, I believe decentralized syndication is an essential part of the web’s future — not just its past. Is the time right for Google (or any of the other major tech platform companies) to embrace the platform again?

Desert Island Apps

| Jorge Arango

I’m always looking for ways of optimizing my personal information ecosystem. By this, I mean focusing on the work rather than futzing with the environment where the work happens. Ideally, I’d log into my computer, do a bunch of work, and then log out without having to think too much about the tools I’m using or how I’m using them.

The challenge is that digital tools are constantly evolving. There may be a new app out there that eases a part of my workflow, or perhaps one of the tools I’m already using has a hidden feature I’m not using. Sometimes such innovations can lead to tremendous efficiency gains, so it’s important to step back and review the ecosystem every once in a while. It’s a tradeoff between spending time working on the work versus on the way we work. A subtle, but important distinction.

Earlier in my career, I devoted a higher percentage of my time to working on my ecosystem than I do now. My toolset has been relatively stable for a long time. In part, this is because I eventually realized that many “new and improved” digital tools are specialized adaptations of more general, deeper tools.

For example, when my family and I were preparing to move to the U.S., I bought an app that allowed me to catalog my book library. I spent quite a bit of time messing around with that app. Eventually, I realized it was actually a specialized spreadsheet — something that’s also true of many lightweight data management apps. Rather than spending time learning a new app that perhaps adds a couple of timesaving features (in the case of the library app, it was reading ISDN codes), I could devote the time instead to figuring out how to do what I needed with the tool I already had: Excel.

Excel is an example of what I call a “desert island” app. Like the concept of desert island books (i.e., the short list of books you’d like in your bag if you were to be stranded in a desert island), these are digital tools that I could use to get my work done even if I had access to nothing else. They tend to be deep and broad, have large and devoted communities of users, and have been around for a long time. Other tools that fall into that category for me are the Emacs text editor, the Unix shell (along with its suite of “small pieces loosely joined” mini-tools), OmniGraffle for diagramming, and Tinderbox for making sense of messes.

Editing my newsletter in Emacs.
Editing my newsletter in Emacs.

These are all tools I’ve used for over a decade. (In the case of Excel, Emacs, and the Unix shell, over two decades.) But even after all this time, I’m nowhere near mastering them. My relationship with these desert island apps is a lifelong journey in which I will continually become more proficient — which will, in turn, make me more efficient. I test drive new apps now and then, but I always return to these old standbys. The effort of learning to use them in new ways is often less than that required by integrating new tools into my workflow.

What about you? Do you have “desert island apps”? Please do let me know — I’m interested in learning about what makes digital systems stand the test of time.

Trading Off Freedom for Convenience

| Jorge Arango

Google Docs is notifying users of the new Microsoft Edge web browser that their browser is unsupported. It’s surprising, given that Edge uses the same rendering engine as Google’s own browser, Chrome. I don’t know if there’s anything nefarious going on (i.e., Google trying to stifle competition in the browser space), but I was reminded of all the trouble I’ve been having lately with my preferred browser (Safari).

To recap: Chrome’s dominance in the market is now large enough that many web app developers target it by default, often at the expense of less popular browsers like Safari. One side effect of this is that some apps don’t work — or don’t work as well — with Safari. The situation has gotten worse since I wrote my previous post on the matter a little over a month ago. More and more major apps are failing for me in Safari, while Chrome gives me no such trouble. This includes systems that are key to my business, such as Quickbooks, Webex, and one of my banks’ websites.

These are systems I interact with on a daily basis. As a result, I now keep Chrome open all the time alongside Safari. I don’t like this situation, for the practical reasons I documented in the previous post. But more philosophically, I don’t like it because it’s a constraint on my freedom to determine the components of my information ecosystem.

The foundational components of my ecosystem are:

  • its operating systems (macOS and iOS),
  • file managers (Finder.app and terminal shell),
  • web browsers,
  • text editors.

I could get much of my work done with just these components. There are other specialized apps in the ecosystem (spreadsheets, diagramming software) that are very important to me, but not to the degree a text editor or a web browser are. (I can access spreadsheet applications using a web browser.) Being forced to replace one of my preferred options for these central components rubs me the wrong way.

Software organizations like Google want us to be all-in on their information ecosystems. I see this goal as being in tension with my wish to define and control my personal information ecosystem. Google’s ecosystem has a lot of neat features — especially if you must collaborate with other folks. (Something I do a lot.) One easy way out for me would be to acknowledge the reality of my current needs and switch over to Chrome. This would certainly be more convenient for me. But convenience often comes at the expense of freedom.

There was a time in my life when I used a lot of open source software: My PC ran on Linux; Firefox was my browser of choice; I worked mostly using Emacs and a host of *nix command-line tools. I had a great deal of freedom. I could even tweak the kernel of my operating system! But I also spent a lot of time maintaining this ecosystem. Every (seemingly) minor tweak required hours of Googling. And all of these tools were “behind the curve” technologically; the more commercial ecosystems had more and better features. I spent almost as much time trying to find workarounds as I did trying to work.

Eventually, I gave up on the whole open source thing and moved back to the Mac (this was at the beginning of the OS X era.) Mac OS was much more convenient than Linux, but it was also more limiting. That was part of its appeal. I also held on to some aspects of it (Firefox, Emacs) which were also present on the Mac. I was excited to switch from Linux to Mac OS, and undertook it with full awareness of the tradeoffs it required.

I’m reminded of this transition as I contemplate how to approach my web browser woes. I’m not excited about having to switch over to the monoculture du jour for the sake of convenience. This time, I’m also aware of the tradeoffs required this time around — and I’m not happy about it.

Direction and Action

| Jorge Arango

Invariably, the most popular posts on this site are the ones that deal with tools and practices. Whether I’m railing against wireframes or showing you a way to make language visible, if it features a concrete tool or technique, the post is likely to have traction. This doesn’t surprise me.

My tool-centric writings fall on the craft end of the craft ↔ philosophy continuum. Philosophy is a harder “sell” than craft. Most people would rather know what to do rather than how to think; they want things they can put in practice on the proverbial “next Monday morning.” The more actionable something is, the better.

Except that action can be undirected. And effecting action towards the opposite of “Good” (perhaps unintentionally) makes things worse. Direction without action frustrates; action without direction muddles.

I don’t aspire to give direction in my more “philosophical” writings. Instead, I’d like you to entertain the possibility that direction matters, and that you ought to discover one for yourself. The world provides ample evidence of things that are going well and things that could be better; it’s up to you to determine what those are and what you can do about them.

Against Wireframes

| Jorge Arango

Yesterday I led a bright and engaged group of folks through my Information Architecture Essentials workshop. Most of them were new to the discipline, and wanting to know more. We talked about many things, but had an especially active discussion about wireframes. I don’t like them and haven’t used them in my work for a long time. I thought it worthwhile to document my reasons here, in case it helps anyone.

Wireframes are a design artifact that has long been associated with information architecture. I’ve heard people ask to be “sent the IA” meaning they expect something that looks either like a sitemap and/or a set of wireframes. I consider these “deliverables” to be tools from a prior — more “waterfall” — era of web design and mostly a waste of time today, if not outright misleading. (I include sitemaps in this statement, even though I’m focusing on wireframes here.)

Although I’m sure it’s been written about at length (and better) elsewhere, here are some reasons why I don’t like them:

  • Wireframes are too abstract and not abstract enough. Wireframes are an attempt to explore the relationships between elements in a screen. Often this includes the relative visual priority of things. However, they attempt to extract aesthetics (the “visual design”) from these visual explorations. As a result,
  • Wireframes confuse stakeholders. I think of design artifacts as tools that allow people — both designers and stakeholders — to make design decisions. Wireframes are mostly clear to designers, but not to stakeholders. Asking folks to comment on the relative hierarchy of elements in a visual document while also asking them to ignore the aesthetics of the thing is a tall order.
  • Wireframes are ineffective as decision-making tools. Visual design affects the perception of the relationship of elements on the screen. Font and color choices affect the relative prominence of elements. More abstract wireframes fail to convey these important distinctions. On the flip side, less abstract wireframes are close enough to visual design to derail the conversation towards the lack of aesthetic nuance. As a result, wireframes are seldom effective in helping people make design decisions.
  • “But,” you may protest, “we don’t use wireframes to make decisions. We use them to convey decisions to developers.” Alas, wireframes are also ineffective as design documentation. Wireframes require more effort to produce and maintain than lower fidelity artifacts (like freehand sketches.) Evolution of the design seldom stops when the wireframe deck is complete, leading to either the deck becoming outdated or — worse — design being “fixed” because the wireframe deck is now “signed off.”
  • Wireframes give the impression that things are more polished than they are. I’ve seen designers present early-stage ideas as wireframes. (Perhaps because some folks are uncomfortable drawing freehand?) These artifacts can look very clean and beautiful, leading the viewer to assume that the ideas they present have been thought-through. Often they haven’t.
  • Wireframes are relatively expensive to produce. Given that so many organizations are using design systems these days, building a comp using a tool such as Sketch isn’t that much more work than making a more abstract artifact such as a wireframe.

So what’s a better way of doing it? I prefer freehand drawings, which allow designers to vary the fidelity of artifacts on the fly. Nobody confuses a freehand drawing with a more polished artifact. Freehand drawings are fast, cheap, and disposable; if somebody has a great new idea, you can draw it on the spot. Yes, this requires that designers learn to draw. (I’m still astonished that some people protest this; communicating visually is essential to design work.)

My preferred way of sketching freehand is to use the Concepts app on the iPad Pro. This app treats the lines I draw on the screen as vector-based “ink”; I can select sets of lines and copy them, paste them, delete them, stretch them, mirror them, etc. This allows me to reuse elements (such as window chrome) across drawings, speeding up the process tremendously. Concepts also allows me to share drawings directly to Slack, email, or other channels. The result: very tight feedback loops that enable the design process to move much faster.

What if you’re communicating design intent to developers? In that case, comps or prototypes do a better job than wireframes. It’s not unusual for developers to ask to be sent Sketch files so they can pull out things like colors and element sizes.

Of course, there may be exceptions to all of this. Some teams may have particular circumstances that allow them to move fast using wireframes. Some industries may require them as official documentation. But in my experience, they aren’t very effective. If you’re a stakeholder, don’t waste time and money by asking your designers to create wireframes. And if you’re a designer, learn the basic principles of drawing by hand (such as the use of distinct line weights, how to start and end lines, etc.) You’ll get better results faster.

How to Understand a Complex Subject

| Jorge Arango

Sometimes you need to understand a complex subject. When first getting into it, you’re faced lots of new concepts and ideas, unfamiliar language, unexpected connections between terms, etc. There’s lots of information to digest. Where do you start? How do you make sense of it all?

Understanding complex subjects is a meta-skill: a skill that helps you become better at acquiring other skills. When you hone your ability to understand, learning new things becomes easier. Improving your sense-making skills is a powerful boost for your effectiveness.

Concept mapping is the best practice I’ve found for making sense of complex subjects. A concept map is a visual representation of the relationships between concepts that affect a particular problem or domain. In contrast to a linear exposition of the subject, a concept map lets you pick the starting point for your investigation and allows you to see details in the context of the big picture. A well-crafted map achieves the goal Richard Saul Wurman laid out for information architects: to help others find their own paths to knowledge.

The best conceptual mapper I know is Hugh Dubberly. The Dubberly Design Office website has an entire section dedicated to showcasing their beautiful and insightful maps. These maps are inspiring — and also a bit intimidating. But concept maps mustn’t be elaborate or polished to be valuable.

A post on the DDO blog shows you how to create your own concept maps. I use this approach with my students and in my professional work; it’s the best way I’ve found to understand complex subjects.

Managing Screen Time

| Jorge Arango

One of the best features of the most recent version of iOS is called Screen Time. It allows you to monitor and control what you do with your mobile devices and when. For example, you can find out how much time you’re spending on social media apps and whether your usage is increasing or decreasing. You can also set limits for yourself on the device overall or on a per-app basis. And if you use multiple iOS devices (such as an iPad and an iPhone) you can configure Screen Time to show you your behavior across all of them.

To access Screen Time, you must open the device’s Settings app. (This feels a bit incongruous. Although I understand this is an OS-level feature, it feels like something that should be independent of Settings. Anyways, I digress.) In the Settings app you’ll see an option for Screen Time:

If you tap on this menu item, you’ll be shown a screen that looks like this:

Continue reading →