Published by

What to do if Command + R won’t reload your VSCode window

So CommandR hasn’t been reloading my VSCode window. But the “Reload window” command in the palette (ShiftCommandP to open palette) shows that it should work. Charles told me how to fix it!

To sort it out, click the cog icon next to the “Reload window” command in the palette to open the Keyboard Shortcuts settings for that command. Then under the “When” column, right-click isDevelopment and select “Change when expression”. Delete the contents, then press enter. There should now be a dash under “When” to indicate that it’s empty. Close the Keyboard Shortcuts file, then try reloading a window by typing CommandR and it should work.

Published by

Fluid type sizes and spacing

I’ve been using a fluid type and spacing system on the most recent builds I’ve completed. Here’s why I use it, and how I approach it. I mainly use SCSS (a Sass syntax), but it’s also very do-able with plain CSS.

Screencast of Gort Scott’s homepage, resizing it in Chrome’s inspector

The example above demonstrates the result on gortscott.com, resizing the window from about 2300px down to about 640px and back again. The type and spacing across the page begins scaling down when the window is 2095px wide and stops shrinking at 1047px wide. At that point the text begins to reflow as the CSS Grid layout continues to shrink. Eventually at 703px wide the layout shifts, and again at 543px wide.

Read more

Published by

Some long-winded thoughts on privacy policies and consent popups

This Q&A is compiled from conversations I have had with many, many clients and collaborators who have had a hard time navigating things like the GDPR, privacy policies, cookie notices, consent messaging, and other related topics.

Here are all the questions covered below:

Read more

Published by

General maintenance tips for website owners

This was originally written as a bit of a guide for my clients and collaborators, an aggregation of similar tips I have given to many of them individually in the past in so many shorter emails and conversations. Since it is relevant to most website owners though regardless of their relationship with me, I decided to share it more broadly here.

Websites require maintenance, even those with the smallest of footprints.

This is what I would consider “bare minimum” website-related maintenance tasks including checking your payment methods and contact details, reviewing your login and security practices, performing updates and taking backups, and checking your privacy policy.

If you do fall behind on maintenance (it happens to the best of us!) and something goes wrong, at the very bottom you’ll find some tips on what to do if your site goes down suddenly.

The vast majority of these tasks do not require a web developer or IT person, almost anyone can perform this maintenance so long as you have access to necessary logins, can follow instructions, and are willing to set aside the time.

I say “almost anyone” because some people are understandably uncomfortable with wading in to this stuff, they may get confused or a bit daunted by the user interfaces they have to use. In that case, just be sure that you are working with someone that can hold your hand through it or can simply do it for you. Also, not everyone has access to all of their service providers. If you’re in a different situation, for example if you retain a web developer, design studio, or IT person to continuously maintain your website, then these are worthy topics to discuss with them but ultimately they will probably need to complete these tasks for you.

Of course there are other maintenance tasks that are super worthwhile. For example it might be worth checking search performance or 404 pages with Google Search Console if search engine optimization (SEO) is important to you, or to check analytics if that’s relevant to your site. And it’s worth speaking to your web developer about front-end maintenance. CSS and JavaScript gets better all the time, as do browsers, so old front-end behavior can really date a site.

But that’s all just the cherry on top. If you complete the tasks below I’d say you’re pretty golden, probably a step ahead of 80% of the site owners I’ve come across.

Read more

Published by

How to embed an Are.na channel using an `iframe` in HTML

A friend got in touch recently about using this WordPress theme, asking if it would be possible to integrate support for Are.na channels in the theme. I suggested that it’s probably out of scope for the theme but could be great as a plugin that integrates the Are.na API, definitely something I’d be interested in making. Started thinking about how it might work best, wanted to keep it relatively simple and such since ideally I’d want it to work with classic WP and Gutenberg.

Turns out, I was way overcomplicating it. I mentioned the plugin idea to Sam and he suggested just doing an iframe embed like they do on the lovely Are.na blog. Of course! 🤦🏻‍♀️

I’d still like to explore the plugin idea at some point since it would offer a few more opportunities (see things to consider about embeds below, particularly the fact that Are.na embed support is undocumented), but this seems like a nice way of doing it in the meantime.

Example below of Gemma’s Internet Explorers channel as an embed:

How it works

This is the embed code for that particular iframe:

<iframe style="border:none;" width="100%" height="590" src="https://www.are.na/gemma-copeland/internet-explorers/embed" title="Gemma Copeland’s Are.na channel “Internet Explorers”"></iframe>

If you’re less familiar with HTML, here’s what’s going on.

The opening and closing HTML tags <iframe></iframe> stand for an Inline Frame element. This type of element nests a separate resource like a webpage on to the page you’re currently looking at. It contains the attributes style, width, height, src, and title to modify the way it behaves.

Since many browsers render an iframe with a border by default, we’re using the style attribute to get rid of the border on this iframe. You can also style HTML elements with classes and CSS, but we’re using this technique, known as inline styles, for simplicity’s sake.

The width and height attributes specify—you guessed it—the width and height of the iframe. If you were missing either of these attributes, the iframe would collapse. According to the standards, these values should both be set as integers which the browser interprets as pixels. That said, browsers seem to be able to interpret a 100% width correctly, meaning that it fills 100% of the width of its container. If you want to stick to standards, you could add a high width value and then add max-width:100%; to your inline styles.

The src or “source” attribute tells the browser what content you want to embed. Without it, you’d just have an empty iframe. The URL we’re using here is exactly the same as the URL for Gemma’s actual Internet Explorers channel (https://www.are.na/gemma-copeland/internet-explorers), with the addition of /embed on the end. If you try visiting this URL, https://www.are.na/gemma-copeland/internet-explorers/embed, you’ll see that it is essentially a stripped-down version of the original Channel page that is more suitable for embedding.

The title attribute indicates the contents of the iframe. It can be important for accessibility since some screen readers will use it.

Things to consider before embedding content on your site

There are a few things worth keeping in mind if you decide to try this. These notes apply to any embedded content, regardless of where it’s coming from.

1. An iframe embeds the tracking and cookie behavior of its source, not just its contents

When you embed another webpage on your site with an iframe, it will behave the exact same way as if you had visited the source website. In other words, that website may collect data about your visitors, use cookies, embed additional third-party tracking, or monitor your visitors’ interaction with the embedded content.

You should be sure that you’re ok with this before including an embed on your site. Personally, this is one reason why I don’t use embeds very often.

I feel comfortable embedding an Are.na channel in this case because it’s for demonstration purposes, they adhere to the GDPR, and I’m satisfied by the way they handle data according to their privacy policy.

2. The accessibility of an iframe embed depends mostly on the source page

It’s recommended to add a title attribute to your embeds for better accessibility, but that’s pretty much where your accessibility control stops. If the source page hasn’t been built with accessibility in mind, it may be difficult to browse for people that use alternative ways to navigate the web.

Unfortunately, Are.na channel embed pages are missing accessibility features such as unique title elements, descriptive alt texts for the block images, and semantic elements such as <figure> or <figcaption>. This is kind of understandable though since these embed pages are an undocumented feature, something that they probably made more for their own use, and they’re no doubt focusing their main efforts on the public-facing product. Would love to see it tweaked though, particularly since they use these embeds on their own blog.

3. It’s nearly impossible to change the way an embed looks

There’s very little you can do to change the look of an embed. You can change the way the frame itself appears, like removing the default border as we’ve done in the example above, but you usually can’t change the contents of the embed.

Sometimes a platform will accept additional attributes or URL parameters that change an embed’s functionality. YouTube is an example, see their Player Parameters documentation. But this just changes the general functionality, it doesn’t allow you to actually change the placement of the play button or change the controls from red to blue. You can use some fiddly JavaScript to get things looking like you want, but it’s pretty hacky.

Instead, if you want to heavily customize the way that the embed contents look, you should probably integrate the content using the platform’s API if they offer it. This is what we did on Gemma’s site, using the Are.na API and Eleventy to add channels directly to her homepage. This content inherits her site’s styles, so it’s more in keeping with the look and feel of her site.

4. Embeds can break

Broken links are an ever-present problem on the web, people are always changing URLs and taking down content. A broken link is only noticeable if you click it, whereas a broken iframe can look pretty crap. If this would bother you, then you might want to be careful about how much embedded content you include on your site.

Besides this, the source website can restrict which domains are allowed to embed their content at any time. This is unlikely to happen with a platform like Vimeo or YouTube which offer embeds as a part of their advertised functionality. But with this Are.na channel embed for example, Are.na might decide that they only want to allow their embed pages to be embedded on their own site and change their Content-Security-Policy or X-Frame-Options HTTP response headers accordingly. And it’s their right to do so if they wish!

If you want to increase the likelihood that third-party content will be available on your site in the future, it’s best to use documented methods, ideally an API. If you integrate content via an API, you can craft a graceful error message in the event that the content doesn’t load. This can look a lot more forgiving than a broken embed.

5. Embeds probably won’t be crawled by search engine bots

This is… not a huge concern IMO. But I mention it since it may be a concern for others. Search engine bots don’t tend to crawl iframe contents, meaning that they won’t take that content in to account when determining what your page is all about. If this is super important to you, then use the platform’s API (if available) to integrate third-party content directly in to your site.

Edit at 2pm: Changed width description since 100% isn’t technically in line with standards, though it works.

Published by

Open source tools for multi-source and cross-format academic publishing

I’m working with Sasha Engelmann and Sophie Dyer on the Open Weather platform, an archive and learning resource related to NOAA satellite 🛰 imagery. Sasha just shared a few open source publication tools that were brought to her attention by a friend and fellow artist at her Akademie Schloss Solitude residency, wanted to add them here for further research and future reference.

Manifold: A platform for publishing academic texts online

Manifold is a free “intuitive, collaborative, open-source platform for scholarly publishing”. See their repo on GitHub.

Manifold powers the Fembot Collective including Ada, Fembot’s journal on gender, new media, and technology. Looks like Fembot has been working with Manifold since about a year ago when the platform launched their pilot. Read Ada 16: Emerging Gender, Media and Technology Scholarship in Africa.

It looks pretty cool (and so does Fembot + Ada!). Manifold can bring together a whole lot of different methods of writing such as Epub, Markdown, HTML, and Google Docs. Hence the name Manifold, I guess. This is incredibly useful when bringing the work of different researchers together. Also makes it clear to me that good markup in writing is so worth it.

Manifold wants to make a digital book much more than just a screen version of a physical book, something that can easily fold in explorations, supplements, and other resources that augment the main text. It also incorporates annotation and discussion settings to keep the conversation going.

I’d love to see a book that really heavily uses the platform’s unusual features. Metagaming: Playing, Competing, Spectating, Cheating, Trading, Making, and Breaking Videogames is a featured project that’s worth a look. The chapters are punctuated with metagames they’ve created that you can download and install.

As a reader, I feel that the typography lets it down a bit. I found it hard to read, particularly on larger screens. A slightly narrower maximum width to the main text column would help a lot. Losing the justification and greater paragraph indentations would help too. Manifold does have some theme options, but it doesn’t involve control over the typography.

If your priorities are bringing together content from a wide arrange of sources, incorporating the work of disparate researchers with varying levels of technical abilities, and relative ease of setup (the documentation seems comprehensive), then Manifold seems like an incredible tool. If you need to retain any control over the design though or if you also want print publishing tools, it might not be the right fit for the job.

And probably worth mentioning: I think you’d need at least a bit of technical know-how to get this set up safely and securely. Probably worth getting in touch with Manifold directly if you’re an org since they’re still in beta.

B-ber: A tool for single-source, cross-format, design-conscious publishing

Triple Canopy is a magazine that “resists the atomization of culture”. They’re responsible for b-ber, a tool for single-source, cross-format, design-conscious publishing. Here’s how they describe it in the b-ber GitHub repo:

b-ber is both a method and an application for producing publications in a variety of formats—EPUB 3, Mobi/KF8, static website, PDF, and XML file, which can be imported into InDesign for print layouts—from a single source that consists of plain-text files and other assets. b-ber also functions as a browser-based EPUB reader, which explains the name.

Their text introducing b-ber “Working on our thoughts”—title from the Nietzche quote “Our writing tools are also working on our thoughts” according to the footnotes—is a good read, explains the impetus and a bit about the ups and downs of how it evolved.

B-ber can only consume one input, an extended form of Markdown. This makes it more limited than Manifold in that regard, but the output options are substantial. It’s particularly strong for the design-conscious, the fact that you can import to InDesign and easily theme the browser-based EPUB reader is pretty fantastic. This is exactly the sort of thing I was looking for back when I was working at Occasional Papers!

The reading experience of the default b-ber theme (or whichever they use on their post) is nicer than Manifold in my opinion, it’s just a lot easier to read. There are some snags, but I imagine you could resolve these in a custom theme. Related to that, see their repository of b-ber demos and b-ber theme starter.

It’s definitely worth following the development of this project if you’re in to digital publishing. Their announcement post was published back in December, not very long ago! Excited to see how it develops.

As with Manifold, I think you’d need a reasonable amount of technical knowledge to get this set up. Since it seems to be more of an internal Triple Canopy tool that they’ve kindly made open source for wider use, they probably wouldn’t be able to provide as much support as Manifold might be able to. (This is just a guess though!)

My experience

Though I’ve been tempted, I’ve never built something that was meant to have a digital bookish-ness, everything I’ve developed has had online-first layouts and components in mind. Some sites have had fairly extensive print styles, but that’s usually as far as it goes.

The most common related problem I’ve run in to on sites with long-format academic writing is footnotes. I’ve never come across a CMS that handles footnotes well. Heck, even HTML doesn’t handle them all that well, there aren’t any appropriate semantic elements as far as I’m aware (though there were in HTML3?).

The only easily accessible markup system that works with footnotes AFAIK is extended Markdown syntax. To use extended Markdown on a client site though, A) I have to be sure that the client is on board with learning quite a bit of Markdown (they often are once they understand the benefit, but some are stubborn!), and B) it needs to be compatible with whatever layout system the designer has devised.

I used this approach a while ago on the Jock Kinneir Library site, as of right now they’re using footnotes on the Biography page.

This implementation wasn’t super straightforward since the site couldn’t use a single Markdown field for content, we needed more of a page builder to accomplish the layout. Because of that, I had to do some trickery to recompile the footnotes at the base of the page content as opposed to after each text section. Honestly I can’t 100% remember how I accomplished it… It’s on Craft so uses Twig templates, and I don’t think we had the time to make a custom module that would take advantage of server-side logic. I do remember that it was a bit hackier than I wanted, but it safely accomplished what needed to be done.

If I need to include footnotes or something similar in the future, I’ll probably refer to this comprehensive article on footnotes, endnotes, and sidenotes (via @s3ththompson).

Would be curious if others have come across similar free, open source tools, or if anyone knows of work being done on the HTML spec to get some progress with footnotes.

At any rate, all of the above just reinforces my opinion that anyone who writes, regardless of how tech-savvy, should learn how to write in Markdown at minimum, ideally the extended syntax. If your archive of writing is in a machine-readable format, you’re miles ahead should you ever wish to publish it somewhere remotely digital or want to convert it to an IDML file or something similar.

Edit 24 September 2020: Added link to article about sidenotes.

Published by

Moving your email from one host to another

I recently helped an artist friend move an email address associated with her domain name from one host to another. These are the steps we took.

TL;DR — Moving email from one host to another is a pain. If you have to take it on yourself, take each step carefully and when in doubt, get in touch with your email hosting provider for advice.

⚠️ I wrote up these instructions as a self-help guide for my friend and decided to publish them here since I figured a lot of people might be in a similar boat. Turns out I was right, I get a lot of emails about moving email! However, if you want someone to manage an email move for you or provide one-on-one support for email, unfortunately I don’t offer this as a service. I’m not the right fit, my specialty is building websites, not managing email. If you don’t want to take it on yourself (which is fair!), you must get in touch with an IT person or systems administrator, not a web developer. If you’re not sure where to find one, ask around for recommendations or have a quick search online for local IT outfits that might fit the bill.

Read full instructions

Published by

Selecting open, free, or commons licenses for content and code

Content and code licensing is a bit of a minefield.

The first thing to remember is that in the UK and USA at least, all creative works are automatically protected by copyright from the moment they are made. The creator retains exclusive rights to their work, and nobody can share, copy, or use the work without the creator’s direct permission unless they are sharing it in fair use (critique, comment, parody, etc.). This is the reasoning behind the classic “all rights reserved” statement you often see in relation to a creative work.

Cover of “Copy This Book” by Eric Schrijver

But it is foolish to believe that “all rights reserved” will always be respected for content online. Tumblr and other platforms have made it so effortless to share others’ work that the public perception of copyright is seriously warped. Creators are very welcome to reserve their rights to all of their work but if they’re releasing it online under such terms, they should be prepared for a lot of violations.

The nature of the Internet created a need for less restrictive copyright licenses, and a whole host of open, free, and commons licenses have filled the void. This is my experience navigating the space for my own work including some of the resources I’ve used, the licenses I have chosen, and my reasoning.

Continue reading

Published by

Q&A related to privacy-first messaging apps

I rely heavily on messaging services since many of my friends and family (probably the majority) live outside of the UK, as do some critical professional contacts. I mainly use WhatsApp for encrypted messaging but have wanted to move away from it for some time due to concerns about Facebook. The recent news regarding the integration of WhatsApp, Instagram messages, and Facebook Messenger has been the catalyst for actual change within my group of peers.

The Q&A below is an amalgamation of many different conversations I am having at the moment about moving to a more privacy-first messaging app. I have focused on Signal and Telegram for the time being since they seem to be the most likely candidates.

I’ve done my best to pull together this information in a fairly short time, and some of it is new to me. If any of it seems incorrect, let me know.

I have nothing to hide, and I have no fear of my data being used against me by a private company or the government. Why should should I make data privacy a priority when I’m choosing a messaging app?

There are many ideological arguments against the “I have nothing to hide” viewpoint, most of which I agree with. That said, it can be near-impossible to agree 100% on ideology, so perhaps it is better to consider the practical.

When your messages are not encrypted, their contents are visible to anyone that has access to them. In an ideal world that would only be you, the recipient, and whatever app you use to manage your messages. Unfortunately, the reality is more complicated and there are many weak points that can be exploited. For example, if the WiFi network you’re on is insecure, your messages will be exposed to unintended prying eyes. Think of the last time you connected to WiFi in an airport, hotel, or cafe. Was it always password protected? Was it clear who supplied the network?

You may not be worried even if your messages were compromised, surely there is nothing in your messages that could be of consequence. But what about the photos of your adorable 4 year old niece from your sister? The online banking details you sent to your partner since the rent payment failed and they needed to sort it out? The message to your worried mother about your blood test results? The company Twitter password you sent to a co-worker that urgently needed access?

There are some things that are best kept private, and encryption lets you do just that.

I’m concerned about the privacy of my data, but why should I switch when WhatsApp already has end-to-end encryption? Isn’t that enough?

It is certainly a great step in the right direction, but whether it’s enough depends upon how much you trust Facebook and how you feel about Facebook’s role in the spread of misinformation.

As things currently stand, WhatsApp’s privacy policy allows limited data sharing with Facebook even though messages are encrypted end-to-end. Since the integration between WhatsApp and Facebook is only being strengthened, I feel it is reasonable to think that the data sharing will continue or possibly grow.

I don’t personally have much confidence in Facebook regarding their use of my data, no matter how minimal, so WhatsApp is not my first choice for encrypted messaging.

Oh man, another app… I really don’t want another app…

I’m with you! It’s frustrating. I don’t have a good answer for this, except that personally I’m going to try to cultivate a little more patience for multiple apps. The WhatsApp / Facebook “monopoly” is kind of what led us here in the first place.

Besides that, the best advice I can give is to frequently Kondo apps and micromanage your notifications. Smartphones give you great, granular control over notifications nowadays, so take full advantage. Turn off the chimes, turn off the lock screen notifications, turn off the message previews. It makes managing multiple messaging apps (and your sanity) a lot easier.

And finally, if you feel like one particular app is a really great fit, then advocate for it! If you’re enthusiastic about it and get your friends / family on board, you may find you have fewer apps to juggle.

My phone is ancient! What privacy-focused messaging app would offer support for my device?

It depends upon the limitations of your specific device.

Signal currently supports Android and iOS. You can find more information about Signal’s operating system requirements in their documentation. Telegram currently supports Android, iOS, and Windows Phone. You can find more information about Telegram’s operating system requirements in their FAQs.

I am not sure about the memory or disk space usage for the different apps though, this is something I would have to look in to further.

I’m very up for switching to a privacy-first messaging app, but the actual switch will involve convincing my contacts to leave too. I wouldn’t mind bringing this up, but it feels like a political decision. Political discussion is not welcome in my field / organisation / family / friend group. How can I approach this?

This is a very understandable and tricky concern. How best to approach this depends completely on your specific circumstances and relationships. It is impossible to give general advice, but I’ll give it a go.

You could delay the conversation, however I would say that even if you do not have the “should we make the switch” conversation with your contacts now, it will likely come up at some point due to the current trajectory of WhatsApp. When you do broach the subject, perhaps consider focusing on the practical upsides of switching to an encrypted messaging app (see answer to first question above for more on this).

If you feel you simply can’t bring this up, then of course you could always continue to use WhatsApp for certain conversations and use a different app for others. Though every app provider would probably prefer you believe otherwise, there is no rule against using multiple apps!

On a more general note, the mis-use of personal data has led to previously unimaginable consequences and turbulence in recent years. As such, every decision related to the transmission of personal data, even something as mundane as choosing a messaging app, is unavoidably political. So though we cannot avoid the political nature of the choice, we can control how we treat that choice. We can be passive, or deliberate.

What is preventing these privacy-focused messaging apps from being acquired by some tech giant and the cycle happening all over again?

If the messaging service is already controlled by private investors, perhaps not much. Here is a very brief summary of how Telegram and Signal are structured as organisations. Note that much of the information that follows has been gleaned via Signal article and Telegram article on Wikipedia.

Telegram is owned by Telegram Messenger LLP and has been funded by Digital Fortress LLC. They have stated that they are not for profit but are not structured as a nonprofit, possibly due to the overhead involved in setting up an official nonprofit. The sustainability of their business model is unclear, however they did put together an Initial Coin Offering (ICO) to fund a new blockchain platform and cryptocurrency. Activity around this seems to have halted in early 2018.

Signal is owned by Signal Messenger LLC which is funded by the Signal Foundation, a 501(c) nonprofit organisation whose mission is to make “private communication accessible and ubiquitous”. Much of the funding ($50 million) used to create this nonprofit came from Brian Acton, a WhatsApp co-founder. Acton left Facebook in late 2017 and is now the foundation’s Executive Chairman. Signal’s open source Signal Protocol is said to be used by a number of large entities (including WhatsApp) for encryption. Part of Signal’s ongoing business model may be to offer services in relation to their protocol, though that is just speculation.

Because of Signal’s nonprofit status, I feel more confident in Signal’s longevity as an independent entity.

Regardless, there will always be churn in this sector, so I would expect to switch again some day. I look at switching messaging apps in a similar way to how I look at switching banks. It is a big hassle to switch, but eventually the arguments for leaving outweigh the reasons to stay. So I switch, and then I keep tabs on it to ensure it remains the best of the options that are open to me.

I really rely on [insert very specific feature]. Would another privacy-focused messaging app support the features I need?

Perhaps! The best place to find out is the app’s own website, they’re jumping to tell you all of the great things their app can do. Another place that might be worth checking is Slant.

Personally, I am most concerned about conversation backups and mute / unmute capabilities.

I want to have some way of backing up my conversations in case I ever lose my phone. But with convenience comes a cost. Backups are notoriously tricky with encrypted messaging since they introduce another potential weak point, the server that stores the backup. With Signal, you can back up on Android but not iOS (though iOS backups do seem to be on their roadmap). Telegram seems to allow backups of some sort, but it is unclear what this means for encryption. The only easily-available information I could find currently was their related FAQ “Why not just make all chats ‘secret’?” and their founder’s blog post “Why Isn’t Telegram End-to-End Encrypted by Default?”

Both Telegram and Signal seem to support conversation muting according to various documentation and articles I found online. The muting duration and other functionality offered by each service will likely be slightly different from WhatsApp.

If I’m going to switch to a more privacy-focused messaging app, which app should I choose?

The three biggest factors in choosing a messaging app are probably the user base, features, and data privacy.

From a data privacy perspective, Signal is likely the best choice. Signal is fully open source, meaning that the security in every aspect of the service can be reviewed and is publicly-verifiable. Though Telegram has an open API and protocol, the backend software is not open source so the security cannot be fully evaluated by a third party.

From a features perspective, it is probably safe to say that WhatsApp is the most fully-featured encrypted messaging app out there currently. It is hard to tell how those features might change over time in light of Facebook’s plan to integrate it with Facebook Messenger and Instagram. Telegram used to be more fully featured than Signal, but at the moment it seems about neck-and-neck.

In terms of user base, it seems impossible to get very accurate numbers. The better thing to do, perhaps, is to just ask around. See what your friends and family are already using. There is a very good chance that certain circles will prefer one to the other. Personally I have more friends on Signal than Telegram, but that may relate to the sector that I work in.

But as a final point, maybe just don’t choose. There is nothing wrong with using multiple messaging apps. I use FaceTime and iMessage with my family because they all happen to have iPhones (though Apple’s not perfect!). I use Signal with lots of friends. I’ll probably hang on to WhatsApp ultimately as well, for a little while at least, since certain contacts are going to struggle to switch to a different app for one reason or another.

A closing thought. Though I’ve focused on Telegram and Signal here, there are a lot of other encrypted messaging apps out there to explore.

For mobile, take a look at Viber, Line, Threema. For business-y stuff, maybe take a look at Wire or Keybase. If you’re just talking desktop and are interested in getting a little techy, check out Freenode and Scuttlebutt.

This is a conversation worth continuing.