Morse code has a reputation. It looks complicated, nerdy maybe - a wall of dots and dashes, something from wartime thrillers and ham radio basements. In assistive technology that reputation is a problem — because Morse is genuinely useful for people who can’t use a keyboard but can manage a single switch. Yet it gets screened out early, on the assumption that it’s simply too hard to learn - or/and its old and surely new things are better right?

The truth is though - if you are blind, have limited physical dexterity and need to write there are few solutions which are really very efficient. So lets look at the data for Morse Code to see if the myths stack up.

Five years of data. From morse-learn, a free, no-login browser game that teaches Morse a letter at a time and quietly records how people do. Nearly 700,000 records from around 35,000 anonymous users. The full paper is out in Disability and Rehabilitation: Assistive Technology. Yay!

The headline — and I want to be careful with it — is that first impressions of complexity are a poor guide to how learnable something really is.

Where this game came from

The game we built on was Google’s Morse Typing Trainer for Gboard, made in 2018 with Tania Finlayson — herself a Morse user with cerebral palsy — with Use All Five and the Google Creative Lab, as part of Google’s broader effort to bring Morse to accessible communication. It was a lovely cute thing: a browser game, built in Phaser.js, that taught the alphabet a letter at a time. And it was fun!

It loooked lurvely but it was built around visual cues (actually visual mnemoics ie pictures that would draw out the dot and dash)and dot-dash patterns on screen. That’s fine if you can see. It’s not fine if you can’t. We had been finding at the Ace Centre that really the ideal group was those who were losing their vision but had dexterity to control two to three switches. So the visual cues were not that helpful.

Around the same time I’d watched a VSauce video on how people learn Morse, and it sent me down a rabbit hole. I found an BJOT paper by Jarus (1994) comparing visual, auditory, and combined methods for teaching Morse — and it got me thinking: what if you built a version that worked for someone who was blind? What if we took Tal Jarus' paper and do it again with a modern UI and this game engine. So we did — and we built all three channels in: visual mnemonics, auditory mnemonics, and tones. Jarus had asked the same basic question — visual, auditory, or combined? — and we wanted to test it at a scale a clinical study never could.

We had a need too - we were working with Mike at the time. Mike was literate had very limited vision, and he wanted to write very efficiently. We (Gavin Henderson and I) forked Google’s game and began adapting it with him. Mike shaped the auditory and visual mnemonics that meant something to him (eg you’ll find “Like Mike”). If you play it today and hear a spoken mnemonic, that’s because Mike helped work out what actually clicked for him. We brought in a voice artist, Matthew Wade, to record them properly, and an illustrator to turn the mnemonics into a set of printable Hello Morse poster cards. You can see the full set of mnemonics written out on Ace Centre’s Morse project page.

Mike sadly passed away before the paper got published. This paper — and the game behind it — owes him more than a footnote. He was a collaborator on this project. We’re grateful to him and to his family.

What we didn’t plan for was that putting the game on the open web — free, no login — meant it reached tens of thousands of people, nearly all of them sighted. So the cue data you’ll see below is mostly from sighted users, not the visually impaired users we originally built for. That’s a real limitation — but it’s also the only reason we have enough people to compare cue channels at all. And the thing we built for Mike — sound — turns out to matter in a way we didn’t expect.

How long, for those who stick with it?

The game is public and free, and with no login so a lot of traffic is curiosity (or possibly bots) — just over half of recorded users show zero progress. They land, they look, they leave. The interesting question isn’t about them. It’s about the people who stayed: how long did it actually take?

Among user-cue sessions where learners made substantial progress, the median estimated time to full-alphabet recognition was 55.6 minutes — about 0.47 characters per minute. That is hours, not the months people often assume. Toggle the threshold and you’ll see the headline barely moves: whether you require 50%, 70%, 80%, or 90% progress gain, the median stays around 55 minutes. It doesn’t mean everyone finishes in an hour, and it doesn’t mean they’re fluent. (Sidenote - we had done this paper earlier - our earlier data suggested a shorter median time BUT we had to trash the data as we found the data a bit unreliable..). It means the prerequisite — recognising all 26 letters — is within reach for engaged learners far faster than the “Morse is impossible” intuition predicts.

When someone is being assessed for a switch-access method, the relevant question isn’t “does Morse look hard on first exposure?” It’s “can this person get to useful recognition quickly enough to justify a trial?”

The surprising part: cues shouldn’t be static

This is where it gets interesting, and it’s worth playing with. The game offers three optional cues — visual (the mnemonic illustrations Mike helped shape, with the dot-dash pattern shown alongside them), speech (the auditory mnemonics), and sound (a Morse tone). Users can switch them on or off independently.

Toggle the cues below and watch what happens to predicted accuracy across the 26-letter teaching sequence.

Did you notice it? Visual cues give a big boost on the early letters — but that advantage fades and then reverses as you move through the alphabet. Sound cues do the opposite: almost no help at the start, increasingly valuable later on. The two lines cross somewhere around letter U (position 13 in the teaching order). (NOTE - it is possible people can SWITCH their cues - but we do adjust for this. So dont get confused - this data above isnt people switching their cues - its just from looking at the learning effect of each cue)

So whats going on here? We early on, you’re still mapping shapes to letters, so seeing the dot-dash pattern helps. Later, we think you’ve internalised the rhythm, and hearing the tone becomes the faster channel for the longer, trickier sequences. It’s a scaffolding-fade pattern: the support that helps a beginner can become a crutch that holds back a more experienced learner.

The design implication is that cueing probably shouldn’t be a fixed setting. An ideal system might start you on visual cues, then fade them and bring in sound as you progress. Maybe. Its a strong hypothesis from our data rather than a proven fact.

Why the late letters bite

Some letters are just harder. Hover over the chart below to see each letter’s pattern and how it fares.

The usual suspects — J, Q, W, Y, Z — sit at the bottom. Mostly that’s because they’re four-element sequences (more to hold in working memory), and because several overlap confusingly with other letters: W (.--) is a prefix of J (.---), so a slightly truncated rhythm maps onto two candidates. But there’s a second reason that’s less about the letters themselves: they’re taught last. By the time you reach them, you’ve either given up or you’re a persistent learner — so difficulty is tangled up with where a letter falls in the sequence, not just its shape.

What this means for how we design

A few things I’m taking away, beyond Morse itself:

Onboarding and teaching should be part of a AT product. We spend enormous effort on the interface and comparatively little on how someone is brought into it. The game works not because it’s flashy but because it introduces one letter at a time, (and the easiest/shortest in working memory first) gives immediate feedback, and lets people practise in short bursts. It moves it from a “this looks impossible” and “oh, I can do this” relatively quickly. Note too - there is something about NOT having to rely on a specialist sitting by you to do this with you. We are normalised now to game play - its the same thing.

Don’t screen out on first impression. If a method looks complex but has a high payoff and a short-ish learning curve, the difficulty you perceive on first encounter may say more about the teaching than the learner. Morse, Dasher, and novel UI access systems — all get ruled out too early for this reason.

Make support fadeable. Whether it’s cues, hints, or scaffolds, the help that gets someone started is rarely the help that gets them fluent. Build systems where support can adapt and withdraw as competence grows. This is where Self-Determination Theory earns its keep: one of its three core needs is competence — the satisfaction that comes from mastering something yourself. Hold their hand too long and you rob people of that feeling; pull it away too soon and you strand them. The cues have to fade at roughly the pace the learner grows, so the sense of “I did that” survives.

How you actually use Morse to communicate

Ok - great. We can teach it. How do you use this thing? For that, we made morAce — an open-source device that takes one or two switch presses, interprets them as Morse, and sends them as keystrokes and mouse movements over Bluetooth to any phone, tablet, or computer. NB if you cant use that - look at MorseWriter - a Windows application to help you to integrate morse as a access solution. (Also of course - dont forget about other solutions like the excellent TandemMaster ). And if you just want to try Morse on your phone, Gboard has Morse input built in — no extra hardware or software at all.

Thanks

This work rests on a lot of people. Mike and his family — the mnemonics in this game were largely his. Thanks to Tania Finlayson and the Google Creative Lab for open-sourcing the original trainer that started all of this, to Matthew Wade for voicing the mnemonics, and to the illustrator who brought the Hello Morse cards to life. Thanks to everyone who played the game over the years and left a trace of data, often while learning something themselves.

The game is still live at morse-learn.acecentre.net and still collecting data, so there may be a follow-up in another few years.

With thanks to co-authors Aleesha Hamid who helped shape the paper, Charisse Holder who gave it all a good read over for accuracy and quality, Gavin Henderson who did the original maths and code hacks, and to Ace Centre for supporting the work. In particular the OT’s who did do a lot of testing of this; Sam, Kezia notably - and the various OT students we had over the running of this that I bored to death with about Morse code..

So yesterday Michael in our team chatted through a client

Deteriorating Neurological condition. Signifcant VI - requires huge font Black on White background. Difficulty with Fine motor control but is literate. Tends to mouth words but not easily undersood.

She needs the letters so large we could use echo but we have to put it under apples magnifier - its not easy to setup.

Hmmmm. He is right. When we made pasco - you could do this. It allowed you to make the font so large it could show one letter at a time. But its not ideal (and that was super buggy). And Echo - we cant do that with. I need to fix it.. But..

Me: Do you need prediction?

Michael: Hmm yes - possibly

Me: Do you want next letter prediction:

Michael: Ideally.. yes

Hmmm. So what if we tear up the rule book (RICE scores does trigger this quite highly due to the rapidly deteriorating solution but really I dont like re-creating something..) and make something. Over the last 12 months I’ve made a ton of different stuff. All of these things were for a particular project but I’ve been careful to turn a lot of into libraries or standaline code. These “bricks” I always thought would be useful.. a JS word prediction system, a WorldAlphabets library and a TTS Wrapper in Node and Python…So we have the building blocks. What if I got a LLM to make this.. its pretty simple..

15 Minutes of prompting with Gemini (and then a bit of hacking - which took 4 times as long from me) I give you…

willwade.github.io/letter-by…

Code at : github.com/willwade/…

Its a React/Vite app (Gemini only does react but Im cool with that). And its leveraging our WorldAlphabets project and PPMPredictor. Note how it learns your own language and will improve over time.

Pretty happy with that. Still.. I really now need to go and fix Echo..

Last week we were honoured to win the Samantha Hunnisett Access Award at the CM Awards.

To be honest, I wasn’t expecting it. Most of my attention was on the big-ticket award of the evening — the Lifetime Achievement Award for Alli Gaskin. Alli was an awesome SLT colleague and friend, and she will be deeply missed. (If I did have any clue we were up for it I might have prepared a coherent speech and not drank two bottles of wine before hand. Apologies to all those who heard my garble on)

But fittingly, Alli also had a direct connection to Echo. While working at Lancasterian she supported a child whose communication needs weren’t being met by any existing AAC system. Echo bridged that gap. She immediately recognised its value and became one of its strongest champions. That connection made winning the award all the more meaningful.

Where It Started

Echo itself began initally as “Pasco”. Named by Euan Robertson (Phrase Auditory Scanning Communicator) we had it drafted for a while as we had around 6 or 7 end users who simply weren’t being supported by the auditory scanning options available. But then one of our clients Paul Pickford one day reached out to us. Paul said:

“I’m selling some stuff and I want to donate some money.”

Paul’s donation gave us the chance to act. Using our RICE framework, we prioritised building this tool — knowing it could have a meaningful impact.

The first version was hacked together quickly, but it worked. People like Darren, recovering from a brain stem stroke, were among the first to try it. From the start, Pasco (and then Echo) was shaped directly by the people who needed it.

A Chinese ICU Case

One case that has always stayed with me came from the early days, when Echo was still called Pasco and lived as a web app.

I met a woman in intensive care with significant visual impairment and minimal movement. But the bigger barrier? She was a native Chinese speaker, surrounded by English-speaking staff. Translation tools let staff tell her what was happening, but she had no way to respond.

We added multilingual support into Pasco: staff could cue in English, but she could output in Chinese. For the first time, she could communicate back. Her parents — also Chinese-only speakers — were in tears. I tried explaining with Google Translate, but it butchered my speech so badly I gave up and just demoed it. Seeing her finally communicate was enough to make me realise it was worth it.

Pasco Becomes Echo

At that stage, Pasco was still rough around the edges. The two-switch scanning had bugs that were difficult to fix. That’s when Gavin Henderson rewrote it in SwiftUI. (Side note: SwiftUI is a dream. I love it.)

That rewrite became Echo.

And then something amazing happened. I was at a conference in Croatia, getting ready to speak, when I noticed a talk being given in another language. I couldn’t follow the words at first, but eventually I realised what was being demonstrated on screen: Pasco. Somehow, it had been picked up and shared across borders, because we had made it open and multilingual. That moment drove home how far-reaching these tools can become when you don’t lock them away.

Open Source and Ongoing Challenges

Echo has always been about more than one app. It’s about showing what’s possible — and letting others build on it. That’s why we’ve kept it open source: 👉 github.com/acecentre…

We’ve also learned when to change direction. For example, we once had a clever “auditory splitting” feature — playing different parts of the audio to different devices. It worked, but it was fiddly. And ultimately, Apple’s iOS audio system won’t let us split audio streams the way we need. Until that changes, it’s not practical.

But the point remains: innovation often starts with finding a solution for one person. When shared openly, those solutions ripple outward and benefit many.

A Team Effort

So yes, the Access Award has Echo’s name on it. But really, it belongs to: • Paul Pickford — whose donation started it all. • Hossein Zoda — who built the first version (Pasco). • Gavin Henderson — who rewrote it in SwiftUI and brought Echo to life. • Michael Ritson (Ace Centre) — for deep input on visual impairment and access aspects. • Charlie Danger — who once needed it working with a scroll wheel as input. • And most of all, the end users — Darren, the client in ICU, and many others whose needs shaped the app.

It’s also for the wider Ace Centre team, who foster and curate ideas like this every day by working closely with individuals with disabilities.

Alright, gather ‘round, aspiring communication chefs! We’re about to embark on a culinary adventure – one where we cook up something genuinely useful for the world of Augmentative and Alternative Communication (AAC). This post dives into how we built tools to automatically correct sentences – specifically tackling tricky issues like typos and words mashed together without spaces. My goal here is to explain this in a way that makes sense, even if you’re not a tech wizard! I’ve gone with a cooking analogy. Now those of you know me know I love an analogy but also know that most of the time they are awful. This maybe one of them and I may take this a bit too far in this post..

What we did: We explored two main paths to auto-correction, like choosing between baking a cake from scratch or using a fancy pre-made mix:

1. Fine-tuning a Language Model: We took a small but powerful AI model (called t5-small) and taught it to correct noisy sentences. Think of this as perfecting a secret family recipe.
2. Developing Algorithmic Code: We also wrote specific computer code designed to fix spelling errors and add spaces where words were run together. This is more like mastering a basic, reliable cooking technique.
3. (Slightly less exciting but..well spoiler alert: the fastest and “best” using an online Large language model)

This project was built some time ago, and while some data might be a bit outdated, the core ideas are still super relevant. You can find all the code at https://github.com/AceCentre/Correct-A-Sentence/tree/main/helper-scripts.

A quick note: If you’re looking for a current solution for an existing AAC system, Smartbox’s Grid3 “Fix Tool” is worth checking out. My work here was done before that tool existed, and it’s why you won’t see me rebuilding our model today!

Hold up. Before we continue if you do want to do this I recommend two things! 1. DONT RUN MY CODE but look at it by all means and be critical of it! 2. Let me know of improvements but 3. DON’T GET YOUR LLM TO MAKE THESE SCRIPTS FOR YOU. You’ll learn heaps more if you do it yourself. I say this with a recent history of geting LLM’s churning out code. Do the harder thing. Your brain will thank you.

The Core Ingredient: Why Automatic Correction Matters for AAC

AAC systems need to do a lot of things but ultimately for an end user they need to allow fast ways of getting your thoughts out from what you are trying to say - and understandable ones at at that. This isn’t just my hunch; it’s what we consistently hear from users, staff, and project feedback. The key term here is efficiency.

Sidenote: Efficiency in AAC isn’t just about the output. It could be speedier services, better quality support, or even device improvements like smarter input detection, but just to be clear for this post we are focusing on efficiency in output

The challenge often comes from “noisy” input – things like typing fast, or facing physical access challenges. Auto-correctionis our secret weapon for cleaning up this messy input and helping users get their message across more effectively.

Unlike prediction (where the system tries to guess what you’ll type next), auto-correction actively fixes mistakes afterthey’ve been made. Think about your phone – it’s constantly correcting your typos before you even see them. This happens seamlessly in the background, making it feel like your typing is perfect! (And you really notice it when it doesn’t work!) So, why isn’t this standard in AAC, where mistakes are equally common?

Approach 1: Building Algorithmic Correction Tools (Baking Our Own!)

When creating an AAC correction tool, it’s helpful to first understand the common “noisy” sentence types. These are the kinds of input issues we need to fix:

• Ihaveaapaininmmydneck (No spaces and typos – a double whammy!)
• I wanaat a cuupoof te pls (Double key presses – sticky keys, anyone?)
• u want a oakey of cjeese please (Hitting nearby keys – positional errors)
• can u brus my air (Missing letters/deletions – vanishing letters!)
• Can you help me? Can you help me? (Repeated phrases – when a stored message goes wild!)

These sentences are typically short. While word prediction can help create perfect sentences, it often requires significant visual scanning and mental effort, which isn’t always ideal for AAC users.

Sidenote: We actually don’t know this for sure. There are some papers that document these types of errors but in short we don’t have a great grip on what is actually written by AAC users.. more on that later..

Tackling Words Without Spaces and Typos (Writingwitjoutspacesandtypos)

This is one of the trickiest problems. How do you separate words when they’re all jammed together?

Well turns out if you know some python code there is a clever library called wordsegment. This tool uses information about how common single words (“unigrams”) and two-word phrases (“bigrams”) are to figure out where words should be. Here’s an example:

from wordsegment import load, segment  
load()  
segment('thisisatest')  

# Output: \['this', 'is', 'a', 'test'\]

It’s very effective! However, language is deeply personal. If wordsegment doesn’t know a user’s unique slang or abbreviations (like “biccie” for biscuit), it will struggle. For example, Iwouldlikeabicciewithmycuppatea might become ['i', 'would', 'like', 'a', 'bi', 'ccie', 'with', 'my', 'cuppa', 'tea'].

Truth is though, even with slight imperfections, the meaning is often still clear, especially if the user is communicating with a familiar partner. Sometimes, “good enough” is perfectly acceptable! In AAC, “co-construction” – where communication partners work together to understand – is super important. It happens all the time and you need to imagine any AAC system doesn’t work without it. We don’t always need to achieve perfect output.

Adding Our Secret Family Ingredients (Personalizing Algorithmic Tools with User Data!)

Imagine if we could incorporate a person’s actual vocabulary and common phrases into wordsegment’s data. This would significantly improve its accuracy for that specific user. We could take a user’s real-life language and use it to enhance the tool’s understanding, like using your grandma’s secret spice blend!

The wordsegment library allows for this kind of customization. When we did this work we even created specific “typo-heavy” two-word phrases based on real typing errors to make it smarter. This is a solid starting point, though capturing every personal nuance is challenging.

Another option is a “fuzzy” search approach (see this blogpost for some ideas on this). This method is light on memory and doesn’t require powerful computer graphics cards (GPUs), making it suitable for running directly on a device. While it might not be lightning-fast, it could be “quick enough” for many situations. However, it still faces challenges with acronyms, names, and highly unusual abbreviations.

Approach 2: Customizing Large Language Models (LLMs) (The Fancy Pre-Made Sauce)

What about the powerful Large Language Models (LLMs) like OpenAI’s GPT-3.5 Turbo? Let’s try wrapping our noisy sentences in an OpenAI GPT-3.5 Turbo API and see what happens:

The results are pretty nice. You can immediately see the benefit: users can focus on typing without being distracted by predictions. This could dramatically improve communication speed.

However, a key consideration with online LLMs is privacy. When communication data is sent to a cloud service, it raises questions about how that data is handled and to be fair some users - and providers of AAC are nervous of this. While some services offer opt-out options for data being used for model training, the notion of personal communication data residing in the cloud is something to address carefully.

It’s fair to say that whether “sending data to the cloud” is “unacceptable” is a nuanced point. Many people routinely use cloud services for sensitive personal information (like email, documents, or medical records), and some are increasingly comfortable sharing personal data with online AIs (is that a word now?). While some AAC users will undoubtedly prefer to keep all their communication entirely offline, others may not find it unacceptable, especially if there are clear privacy controls in place.

The primary privacy considerations often boil down to:

• User Comfort and Perception: Users might be uncomfortable with the technology if they perceive the privacy risk to be greater than it actually is, or if they don’t trust the AAC providers to have robust privacy controls.
• Provider Controls: The risk of poor privacy or security policies by an individual AAC provider, which could lead to chat data being logged, stored, or mishandled in the cloud.
• Security Measures: The risk of security breaches providing unauthorized access to chat data flowing through APIs.

These risks can and should be mitigated through robust security measures and strong privacy controls, such as not logging or storing chats unnecessarily, and avoiding associating them with user-specific IDs in API calls. If an AAC provider implements these correctly, the benefits of advanced online LLM capabilities might outweigh the concerns for many users, even if it doesn’t allay everyone’s apprehension. But either way - it would be darned easier to explain to end users if data never left the device.

Therefore, for AAC, we need a solution that is:

• Efficient: Quick to cook! Gets to you what meant accuratley and quickly
• Privacy-focused: All in your kitchen, no external diners!
• AAC-text savvy: Understands our unique culinary style!

Training Our Own Language Model for Correction (The Holy Grail: Baking Our Own Language Model!)

Spoiler alert - This is what we want to make - note this video is all running on device

Building our own language model from scratch sounds daunting, but it’s more achievable than you might think! The fundamental ingredients are:

1. Data: A large collection of “noisy” sentences (like actual user input) alongside their perfectly “cleaned” versions. The more this data resembles real AAC communication, the better the model will perform.
2. Even More Data: Seriously, data is the most crucial ingredient.
3. Code: The “recipe” for teaching the model.
4. Computing Resources: Some time and a computer (preferably with a graphics card).

The biggest challenge is DATA. There’s very little publicly available “AAC user dialogue” data. What is “AAC-like text”? It’s a surprising gap in our industry’s research – we don’t have large datasets showing how people actually use AAC. Are stored phrases used all the time? What kind of unique language do users create? We’re often just guessing.

So, we have to “imagine” what AAC-like data looks like. Researchers like Keith Vertanen have made fantastic attempts with artificial datasets. We also believe “spoken” language datasets might be a good starting point, as AAC aims to enable “speaking” through a device. We looked at corpora like:

• BNC 2014 Spoken
• AAC Text
• Daily Dialog

The problem? These are mostly perfectly transcribed texts, lacking the glorious typos and grammatical quirks our correction tool needs to learn from. We needed truly “noisy” input.

Injecting Noise: Making Our Data Deliberately Messy

To make our pristine datasets messy, we artificially injected errors using tools like nlpaug. While this creates synthetic noise, we also sought out real typos from sources like the TOEFL Spell dataset (essays by English language learners). For grammar correction, we also looked at datasets like JFLEG Data and subsets of C4-200M which contain grammatically incorrect sentences with their corrected versions.

Our Grand Baking Plan: Data Preparation:

1. Take each spoken text corpus.
2. Inject typos into the sentences and strip out common grammar elements (like commas and apostrophes, which AAC users often omit).
3. Create three versions of each sentence for training:
   • With typos.
   • With typos and compressed (no spaces).
   • The correct, clean version (but still without spaces, to train for de-compression).
4. Also, incorporate a grammar baseline layer using the grammar datasets.

We then used a “text-to-text transformer” model (specifically, the t5-small model) to learn from this data. This type of model is designed to take one text input and transform it into another, making it perfect for correction tasks. We chose t5-small because it’s lightweight and efficient enough to run on a device.

You can find the script for preparing the data here (you’ll need to download the BNC2014 corpus separately). The training process took several hours on a decent GPU. The resulting model is available on Hugging Face.

The Taste Test: How Did Our Bake Perform?

Let’s look at how our different correction techniques performed on a set of 39 test sentences (which contained both compression and typos):

• Algorithmic Approach (Wordsegment + Spelling Engine): Took about 14 seconds to process the test sentences. This approach is surprisingly quick for what it does, and it has no memory issues. However, its major limitation is that it will fail if it encounters words not in its dictionary, or novel grammatical structures.
• Online LLM (Azure/OpenAI GPT Turbo 16K): Took an astonishing 13 seconds! This speed, even with an external network call, is remarkable.

Now, for our custom-trained models:

Here are some example results comparing the incorrect sentence to the correct version and outputs from various models:

Our custom-trained model (HappyWill) actually outperformed GPT in terms of average similarity! While its total time was longer because we ran it on a small cloud machine, it would be much faster on a local device – and, crucially, it keeps all data private.

However, it’s important to note the “inbuilt” algorithmic technique (the Wordsegment one). While its “accuracy” (meaning, how often it perfectly matched the exact expected output) was low for our specific test, its output was surprisingly readable, and it has no privacy or significant memory concerns.

You can try the inbuilt algorithmic correction yourself for a short while via our API:

curl -X 'POST' \
  'https://correctasentence.acecentre.net/correction/correct_sentence' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "text": "howareyou",
  "correct_typos": true,
  "correction_method": "inbuilt"
}'

Or access the API directly in a browser: https://correctasentence.acecentre.net (just remember to set "correction_method": "inbuilt").

So, the next crucial step in our culinary journey? We need to hunt down, or create, an even richer, noisier, and more authentic corpus of data. The quest for the perfect “ingredients” continues!

(Oh dear.. This cooking analogy really went too far… I do apologise)

Key Takeaways

From this project, we’ve identified a few critical points for developing communication tools:

• Understanding Language Models for Correction (How to Broadly Make a Language Model for Correction): We’ve shown how a custom, fine-tuned language model (like t5-small) can be developed to correct complex errors while keeping user data private and enabling on-device processing. It’s about tailoring the perfect sauce to your needs.
• Algorithmic Approaches Can Be Effective (Algorithmic Approaches May Be As Good In Some Circumstances): For specific problems, like adding spaces or basic spelling, simpler algorithmic approaches can be surprisingly readable and efficient, offering a viable alternative to complex AI models, especially when novel input isn’t a primary concern. This highlights the importance of matching the tool to the specific type of communication challenge – sometimes, a good old stew is just what you need!
• The Need to Understand User Corpora Better (We Need to Understand Better Users Own Corpora): Regardless of the approach, the effectiveness of any correction tool is heavily dependent on the training data. There’s a significant need for more authentic, “noisy” datasets reflecting how AAC users actually communicate. Truly understanding users’ unique vocabulary and communication patterns – their personal “flavor profiles” – is essential for building the most effective tools.

I hate having to do this. But I have.

I’ve made ANOTHER tool to load up your env vars in a terminal. Why? Because I had a mare getting direnv to work on my specific Windows machine. It was really due to the way our office locked down the way a users $PROFILE works - that is it puts everything on OneDrive and there was a ton of admin issues getting it all working correctly. So, stupidly, rather than fixing that properly I found it (more fun?) to build a cross platform simplifed direnv tool.

So its called envloader, FInd details here and how to use.

In short Let’s imagine your directory - or one above it - has a .env or a .envrc file. It might look like this.

MICROSOFT_TOKEN_TRANS="token-for-trans"
CONFIG_ENCRYPTION_KEY="RqliKRLnkQxTOzgx_molctcWXM_alqSaNYVxCTBjma0="
SIMPLE_VAR=hello123
JSON_VAR='{"name": "test", "value": 42}'

This is common syntax for dotenv and direnv, but it won’t work as-is across all terminals. You need a tool to convert it properly for your shell. direnv IS your tool of choice, but if you like me, you cant just get it working - or the numerous other tools out there like it and you spend too many hours fiddling to get them to work (because you have a Windows machine which has really tight admin rights on it) you could try this little tool I’ve made..

Install on Mac/Linux

brew tap willwade/envloade
brew install willwade/envloader/envloader

or Using Scoop

scoop bucket add envloader https://github.com/willwade/envloader
scoop install envloader

then in a terminal you can run envloader and press enter. It will find a .env or .envrc and convert the lines appropriately for your shell.

e.g.

envloader

Make your life a bit easier and write an alias in your env - details here

I haven’t gone to town building lots of neat integration tricks - and unlike direnv it DOESN’T autoload on entering/exiting a directory. But running ‘envload’ now does the trick just fine for me. Maybe for you too.