With it, comes a new author field, and also a source field. Which means a text shot can contain a title, author, source, and the quote. This hopefully makes Text Shot become more usable when sharing quotes from books, and maybe a few other places that I haven’t thought about.
Alongside the new fields, there’s also a “Copy Alt Text” button. This, of course, generates and copies a description of the text shot, that you can upload alongside the image when you post it to sites like Mastodon.
Here’s an example text shot:
And here is what the alt text would be for it:
A text shot containing the following information:
Title: Text Case CLI via Homebrew
Author: Chris Hannah
Highlight: To use these formats, you can pass in input in three different ways - you can use the --input option to pass a string of text, the --in option to specify a file to use as input, or you can pipe in data from stdin.
There’s also a bunch minor UI changes that no-one will probably notice. 😅
Ever since I rebuilt Text Case around the concept of user-built flows, I’ve always been missing one key part of the original version, the list of all of the formats with instant previews. It might have been long, and maybe with big bits of text it took a second or two to transform into every format. But it was really useful to not only transform text quickly, but to also see it in various formats at once.
That’s why, I’ve decided to add back that feature, but in a new slightly new guise.
There’s now a new “Scratchpad” tab in Text Case, which allows you to enter text at the top, and then see the results of it being formatted using all of your custom flows, and also every single format available in Text Case!
At the same time, there’s also a new button in the Flows section to add a single Format. This is when you want to have your own custom list of formats, but you don’t really want to build a full flow.
And I couldn’t stop there without also adding a few extra colour options for flows, and also some extra visual tweaks all throughout the app.
I’ll get right into it, I think most app subscriptions shouldn’t exist.
Not because I have a vendetta against subscriptions, but because in most cases, they are used as a substitute. They are used as a mask to hide the lack of real upgrade pricing.
When a developer feels like they need to have a continuous stream of money coming in, for them to work on and improve an app, it’s because they want security to allow them to continue. They want reassurance that they won’t be wasting time.
A more honest solution would be that if you work on a major update to an app, that you could make it available alongside an upgrade price.
It then gives agency to the user, where they can make a decision on whether they want to pay for an upgrade. Sometimes an app works for you, and there’s no extra value to be gained. Other users may appreciate the increase in functionality and would be willing to pay for it.
It also assures the developer that they can work on an upgraded version of their app, and not have it lose them time or money. From both existing users upgrading, and from the potential of new users.
If I suddenly announced that Text Case was moving to a subscription model, I expect a lot of people wouldn’t be best pleased. Sure, I could make the argument that this would come with regular updates, but what if someone is fine with the app how it is? Why would you need to pay for something you don’t want?
But at the same time, if I spent months working on a whole new version of the app, I’d feel a bit weird releasing it to everyone as a free update. But if I could make it both the new default version for new customers and offer it to existing users at a much smaller upgrade price, that would make a lot more sense.