Deprecated: Return type of I::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 62

Deprecated: Return type of I::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 91

Deprecated: Return type of I::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 71

Deprecated: Return type of I::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 101

Deprecated: Return type of I::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 53

Deprecated: Return type of Collection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/collection.php on line 80

Deprecated: parse_str(): Passing null to parameter #1 ($string) of type string is deprecated in /home/public/kirby/toolkit/lib/url.php on line 135
One Tap Less | Every automatization is personal

Every automatization is personal

Every app has its origin on a problem yet unsolved, if you're developing an app and it doesn't have such sort of purpose, just go back to the drawing board and ask yourself "why?". Let's say there's a reason behind all the efforts we see on the App Store, meaning that every app serves a specific function and we acquire them because we share of the same issue.

After getting a productive system, I stopped pondering why people consumed GTD apps looking for an ideal. These systems are so specific, so intimate, it is tough for any, doesn't matter how complete, application to fit every single need. We adapt, we adjust our workflow to use our available tools. That's what makes us humans.

But when you link two or more apps into a single workflow, you narrow down the specificity. There's nothing more personal in terms of computing than developing your own stuff, be it a whole application, a python script or even something simpler and in this blog I risk suggesting you workflows to fix essential needs. There is, most certainly, an app for your needs, we just do more with less.

I'm giving this piece of advice to help you creating your own workflows, because every case is unique and only yours truly. I can help you there. If you have any necessity you'd like to automatize in your iOS device, let me know and I'll do my best to help you out.

Your memory is short

Drafts' latest updates were great. Lines, ranges, selections. There are just so many possibilities now, but my recommendation is to keep your workflows as short as your memory. Don't create a workflow relying on more than 3 fields, you won't recall more than that most of the time. This is a quick example, using the first line as subject, second line as recipient and the remaining lines as body for a markdown email, using the new [[line|3..]] feature of Drafts 3.5.

If you ever require the need for more than 3 lines of parameters, they'll be, most of the time, further more case-specific and you'll make a better deal creating two different actions. Think for a moment, the coolest part of automatization is not watching your inputs magically placed in the right fields, but having stuff automatically placed in fields for you, without typing. That should always be your goal. It'll be mine for a long time.