
Why I started Email Calendar How-To
It was 2018, and I was trying to set up an email calendar reminder for a client’s recurring meeting. The instructions I found online assumed I already knew which tabs to click in Outlook, where the ‘Recurrence’ button hid, and why ‘All Day Event’ mattered.
Every guide skipped the part where you’re staring at a blank screen, wondering if you’ve just broken something. I ended up calling my dad—who, despite being a retired engineer, still gets frustrated by modern software—and we figured it out together.
That’s when I realized most tech guides were written for people who already spoke the language.
This site exists for everyone else. If you’re setting up your first email account, troubleshooting a printer that won’t print, or trying to figure out why your calendar events keep disappearing, you’re in the right place.
No jargon, no assumptions, and no patience for instructions that read like they were written by someone who’s never actually used the software themselves.
Meet the founder

My first computer was a hand-me-down Pentium II with a 14-inch CRT monitor that flickered like a dying neon sign. My dad brought it home from work in the mid-'90s, and I spent weekends staring at its green-screen DOS prompts, convinced I’d one day understand what ‘C:\>’ meant.
The first thing I broke was the floppy drive—inserting a disk too fast snapped the motor gears. My dad fixed it with a paperclip and duct tape, then told me, ‘Technology isn’t about not making mistakes. It’s about figuring out why they happened.’ That’s the only rule I’ve ever kept.
I still have that computer. Well, not the original—it died in 2003—but I salvaged the case and mounted it on my desk as a reminder.
The power button doesn’t work anymore, and the ‘Windows 95’ sticker is peeling off, but it’s the only machine I’ve ever owned that taught me more about patience than about tech. The real lesson? Every glitch has a cause, and most of them aren’t as scary as they seem.
The failure that changed everything happened in 2015, when I tried to automate a workflow in Excel for a freelance project. I recorded a macro to format a report, ran it, and watched as the entire spreadsheet rearranged itself into gibberish. No error message. No warning. Just… chaos.
I spent three days reading forums, testing fixes, and finally realizing the issue was a misplaced semicolon in a cell reference. That’s when I decided to stop writing guides that assumed people knew where to look for the semicolon—and started writing ones that pointed it out.
I have one habit I can’t shake: I always take a screenshot before I troubleshoot. Not just of the error, but of *everything*—the taskbar, the open windows, even the desktop background. It’s a relic from my early days of tech support, when clients would describe problems I couldn’t reproduce.
Now, I do it out of superstition. If I’ve got a visual record, the solution feels less like guessing and more like solving.
Meet the mascot

The mascot started as a doodle on a Post-it note during a meeting about how to explain ‘recurrence rules’ in Outlook.
I was sitting at my kitchen table (yes, really—my desk was buried under old hard drives at the time) when I scribbled a stick-figure person holding a calendar, but the arms were too long and the calendar looked like a deflated soccer ball.
My coworker, Alex, pointed out that it resembled a ‘ghost in a time machine,’ which wasn’t helpful, but the image stuck. We knew we needed something simple enough to fit in a browser tab but recognizable enough to feel like a guide, not a glitch.
The next version was drawn on graph paper, this time with a proper circle for the calendar and a ‘!’ exclamation mark where the figure’s head should’ve been. The arms were still wrong—too many fingers, too rigid—but the calendar shape was starting to work.
Alex, who’d studied animation in college, suggested making the figure’s posture ‘collapsed,’ like someone who’d just realized their meeting was at 7 AM. That’s when the ‘!’ became a sleep mask, and the mascot got its first personality: exhausted but determined.
We named it ‘Cal’—short for ‘Calendar,’ but also because it sounded like a name you’d give to a tool you rely on.
The final version lost the sleep mask (too busy), the extra fingers (too distracting), and the ‘time machine’ arms (too sci-fi). What remained was a squat figure with a calendar for a head, holding a pencil like it’s about to write something important.
The pencil was a last-minute addition—Alex argued that ‘a mascot without a tool is just a sad blob’—and it’s the only part of Cal that’s ever moved. Now, it sits at the top of every guide, a silent reminder that even the simplest problems need a step-by-step approach.
What I promise you
This site exists to turn ‘I don’t know how to do this’ into ‘Oh, that’s how it works.’ No fluff, no filler, and no steps that assume you’re already an expert. If I can’t explain it in plain English, I’m not explaining it right.
What you can hold me to
- Every guide includes a screenshot of the exact screen you’ll see—and where to click next.
- If a step fails, we tell you why (and how to fix it) before you waste an hour Googling.
- We update guides when software changes—no ‘this worked in 2019’ excuses.
- If we’re wrong, you’ll know within the first three paragraphs (and we’ll fix it).
How I create a guide
Every guide starts with a real problem—mine or someone else’s. If I’m writing about setting up an email calendar, I don’t just read the manual; I open Outlook, create a dummy account, and follow the steps *exactly* as they’re written. Then I break them. I delete a file mid-setup.
I ignore a warning. I try to skip a step. The goal isn’t to find what works; it’s to find what *doesn’t*—because that’s where people get stuck. The notes from these tests become the first draft.
The ‘does it work?’ Stage
This is where I hand the guide to someone who’s never used the software before—usually a friend or family member who’d rather be doing anything else. Their job isn’t to follow instructions; it’s to get frustrated.
I watch for three things: where they hesitate, where they second-guess, and where they give up. If they pause for more than 10 seconds on a step, it’s either too vague or assumes prior knowledge. If they skip a warning, it’s not clear enough.
And if they close the guide without finishing, we’re rewriting.
The fix isn’t always adding more details. Sometimes it’s removing them.
A guide I wrote about Linux file permissions started with a paragraph about ‘user groups and permissions flags.’ My test reader stared at it for 45 seconds before saying, ‘Is this a secret code?’ The rewrite replaced it with a table of three columns: *File*, *Permission Needed*, and *How to Check It.* No jargon, no assumptions.
Just the tools they actually need.
The ‘does it make sense?’ Stage
After the test, I go back to the guide and ask: *Does this sound like something a human wrote, or a robot?* If a sentence starts with ‘Navigate to the…’ without saying *where* ‘there’ is, it’s gone.
If a step says ‘Click the gear icon’ without describing what the icon looks like, it’s rewritten. I cut every phrase that could be misunderstood—even if it means adding a screenshot. The goal isn’t brevity; it’s clarity. If a reader has to guess, they’ve already lost.
How a guide gets onto this site
Once a guide passes the ‘Does It Work?’ and ‘Does It Make Sense?’ stages, I let it sit for 24 hours before publishing. Not because I think of it as ‘resting’—it’s because I want to read it like a stranger.
If I get stuck or confused, I know the guide isn’t ready. Sometimes a paragraph gets cut entirely. Sometimes a step is split into two. And sometimes, months later, I’ll revisit a guide because the software updated—and realize I’d missed something critical the first time.
Write to me
I love hearing about the problems you’ve solved (or the ones you’re still stuck on). Did a guide here fix something that had you pulling your hair out? Did you find a step that didn’t make sense?
Tell me—even if it’s just to say, ‘This worked perfectly.’ The contact page is the best place to share your thoughts, and I read every message. (Well, almost every one.
I *did* once get a 500-word email about why my Outlook tips were ‘dooming the future of productivity,’ but that’s a story for another time.)
If you’re writing because you’ve got a tech problem we haven’t covered, include as many details as you can—screenshots help, even if they’re blurry. The weirder the issue, the more I’ll geek out over solving it. And if you’re just here to say hi? That’s fine too.
Just don’t expect me to know what ‘Ctrl+Alt+Del’ does on a Mac.
Delia Ocampo
The guides are grouped by category: App, Coding, Hardware, Operating System, Outlook and PowerPoint.