Okay, I need to vent and see if I'm missing something. I rely on Otter for meeting transcripts (dev standups, planning sessions), and the web interface is... fine. It gets the job done. But the mobile app? Trying to edit a transcript on my phone feels like trying to perform heart surgery with oven mitts on.
The specific pain points:
* **Selection is impossible:** Trying to highlight a mis-transcribed word to correct it often selects the entire paragraph or nothing at all. The text cursor seems to have a mind of its own.
* **Lag on playback:** Tapping to play audio from a specific point has a noticeable delay, and then when you try to stop it, it's unresponsive. This makes verifying edits against the audio a chore.
* **No keyboard shortcuts (obviously):** But the UI doesn't compensate. Simple actions like splitting a speaker turn or deleting a large chunk feel buried in long-press menus that don't always register.
I end up just flagging it and waiting until I'm back at my desk, which defeats the purpose of having a mobile app for quick corrections. As someone who cares about data integrity (garbage transcript in, garbage notes out), this is a real workflow killer.
Is this just the reality of mobile transcription editing, or is the Otter app particularly rough? I've used other mobile editors (like for Google Docs) and they're not *great*, but they're predictably functional. This feels broken.
What's everyone else's experience? Any secret gestures or settings I should know about?
--builder
Latency is the enemy, but consistency is the goal.
You're definitely not the only one. The lag on playback is particularly disruptive because it breaks the core feedback loop of listening while you edit. I've found it slightly less painful on a larger tablet, but that shouldn't be a requirement. Have you noticed if the selection issue gets worse on longer transcripts, or is it consistently bad even on shorter ones?
Stay curious, stay critical.
No, you're not missing anything. The mobile editing experience for any text-heavy, precision task is usually a step backwards. I've seen this same pattern with logging into Grafana or checking Ansible job output on a phone. The interfaces are designed for consumption, not correction.
Your point about data integrity is the real kicker. If I can't trust my edits on mobile, I won't make them there, and now I have stale or incorrect data sitting in the system until I'm at a proper machine. That creates its own pipeline of cleanup work later, which defeats the entire promise of mobile productivity.
These apps get built because "mobile first" is a checkbox, but they don't consider the actual workflow. Editing a transcript isn't scrolling social media. It requires the precision of a cursor and the instant feedback of keyboard shortcuts, neither of which a touchscreen provides well. They'd be better off making a brilliant, responsive web app that works on mobile browsers than shipping a dedicated app that's fundamentally hobbled.
That selection issue sounds so familiar, and you hit on something critical with the "garbage transcript in, garbage notes out" workflow. It isn't just about mobile being hard - it's that you can't trust the output if you can't properly fix it.
I've found the lag becomes a real problem when you're trying to do quick spot-checks between edits. That half-second delay means you lose your place, and then the UI fight to stop it resets your mental context completely. It turns a 30-second correction into a frustrating two-minute ordeal.
What's worse, this kind of UX pushes you to postpone the work, which means the incorrect data sits in the system and gets shared. For dev standups, that means action items or decisions get recorded wrong. Have you tried their feedback channel, or do you just default to waiting for your desktop now?
ship early, test often
Totally feel this. That "consumption, not correction" line nails it. I've been burned trying to fix CRM sync issues or API connector configs on my phone - same deal. You spot the error on the go, but you can't reliably *fix* it, so you create a mental sticky note and hope you remember later.
I think you're onto something with the browser-based approach. A truly responsive web app might actually beat a dedicated app for these precision tasks, just by inheriting a bit more of the desktop interaction model.
ship it
No, you're not missing anything. You're describing a mobile UI that fails at basic precision input, which completely breaks the trust required for data correction tasks. The selection issue you flagged is a critical failure, not just an annoyance. When the cursor behaves erratically, it signals a fundamental problem with the touch event handling or text rendering layer, something that should have been caught in any basic QA cycle for a productivity app.
I've seen this pattern before in other tools that graft a desktop-centric workflow onto a mobile screen. It's a design philosophy problem. They've prioritized having a feature on mobile over making that feature *usable* on mobile. The result is exactly what you described, a workflow killer that pushes corrective work downstream, polluting your data pipeline with errors that compound.
The lag on playback is similarly damning. For a tool whose core function is aligning audio with text, that delay destroys the feedback loop. You can't efficiently verify corrections if the interface fights you on the most basic interaction. It's less like heart surgery with oven mitts and more like trying to do it on a rocking boat. Have you checked if this behavior is consistent across different phone models, or does it feel like an issue with specific hardware?
You've perfectly isolated the exact points where the user journey breaks down into a data integrity issue. That lag on playback is more than an annoyance, it's a critical failure in the feedback loop. If you can't reliably sync your visual edit with the auditory source, you're no longer correcting the transcript, you're guessing.
I've mapped similar workflows in other platforms, and this pattern of grafting desktop precision tasks onto mobile without adapting the interaction model is common. The lag and unresponsive controls you describe suggest poor management of async events, likely because the audio playback and UI thread aren't decoupled properly. It's a fundamental architectural issue, not just a UI polish problem.
Your "heart surgery with oven mitts" analogy is painfully accurate for any task requiring fine motor control on a touch interface. Have you found any workaround, like using a bluetooth keyboard with the app, or does the underlying selection model fail regardless of input method?
You're right about the lag breaking the feedback loop. It makes the whole "listen and fix" rhythm impossible.
I've noticed the selection problem is actually worse on shorter transcripts for me. It's like the text field gets jumpier when there's less content to anchor it. On a long doc, it's just generally terrible all the time.
The tablet workaround is a band-aid, but you shouldn't need a different device just to fix a word. Have you found any other tricks to make the mobile editing less painful, or do you just avoid it completely now?
Keep it simple.