Greg’s brought it to my attention that the ThoughtAsylum Action Group as it currently stands is pushing some of the iCloud limits that Drafts actions sync is built upon. As a result, I need to make some changes before I make it so big that it stops working
Step 1 - The Relatively Easy Change
The first change is that in the next update I plan to make some amendments that will move the TAD-Library action out of the main library. This is only currently actively used for the download of the file version of the library, but there’s also a setting where you can switch the action group to use that action rather than the file. I plan to just make the TAD-Library action a separate download in a separate group (to dissuade anyone putting it in the original group and busting the limits) for anyone who wants it, and I still plan to keep it up to date, in line with the file version. The file download action (TAD-Setup/Refresh) will be modified to run independently.
This will roughly halve the library size, but I plan to keep expanding, so I’d like to build in more growth capacity just in case. This is where I want to get some advice.
Step 2 - A Change Where I Need Advice
I want to put in place a strategic solution rather than a tactical fix. Drafts gets features so frequently that I can take advantage of (I currently have some sat in a TA - Beta Only action group for instance), I really want to ensure that I include the potential for more growth in the TADpoLe library and the action group without bumping into the same size issue in a year’s time.
The current action group has 55 sections containing 380 actions.
Expand to show the sections
Library
Scripting
Information
Whitespace Removal
Sort & Permute Lines
Draft Status
Draft Syntax
Delete
Select
Move Cursor
Insert Content: General
Insert Content: Current Date/Time
Duplicate
Markdown
Drafts Markup
HTML
Discourse
Mass Processing
Slash Command
Web
Tag Management
Dictation
Create Drafts
Recent Drafts
Workspaces
Populate Clipboard
Share as Content
Share as File
Edit
Templates
Previewing
Persistent Variable Examples
Action Groups
Action Groups - From Install URL
Editor Insertions
Text Modifiers
Sample Content
TextExpander
Reader Mode
URL Encoding/Decoding
Online Information
Word Actions
Action Control
Helper Actions
Tasks
Advanced Logging
Mac Audio
Matched Line Removals
MediaWiki Syntax
Clipboard
Meta Based File Management
App Control
Cross-Linking
Link Note
Draft Embedding
There are so many dependencies on the library, and for ease of manual update for users (and to an extent me), I’ve kept everything in one action group. But I feel that the next logical step is going to have to be to split it.
The question is what would be the best way to split this for such future growth?
Would it make sense to just switch to a new action group when this one reaches a particular size (e.g. 400 actions)?
Should I split the sections in the existing group and split those off into two or three other groups of somehow related sections?
Should I sort the sections alphabetically and split into a number of groups by alphabetic section (e.g. A-M & N-Z)?
I’d like to make the transition as easy and sensible as I can. There is no single “correct” answer, so I figured the best way to figure out what might be best was to ask and see if there are any other ideas or a consensus around one of the ones above.
Thanks in advance for any and all suggestions and recommendations.
Hey @sylumer great to put this question out in the open.
In my opinion your library consists of many groups of actions that are helpful based on the task you are tackling e.g. Markdown processing. Text cleanup or selection and moving. Dates.
I would suggest that it is a great tool for looking up stuff but not so great for selecting (and finding) that actions.
My idea would be to give the user a general update mechanism in a core library including things like logging and so on and give the links to the more specific topics from there.
Extract other stuff in completly seperate action groups or hand them over to other projects/developers.
Another idea would be to create a configuration file to reduce the fields of interest of the developer.
Multiple instances of tadpole (with different configurations) could then be used to reduce the amount of actions in the library
Would you not search the directory and evaluate the details of the action group first before downloading? The action group information does also have a link to a page documenting each action.
Most of the actions have a dependency on a couple of actions in the group. Drafts currently has no way to automatically support Drafts inter-dependencies or library file dependency. Hence collecting them into a group. One download, one setup, and you can use everything.
Yes. I’d be happy to see a core group (the current “Library” section?) + actions grouped for specific functions as optional installs. This might not map exactly to your current sections but instead collect some of them together. Maybe something like three different “flavours” of TADpoLe?
The full group is a lot to digest as is (and I’ve spent time looking through it to figure out what’s most useful to me), particularly if someone already has their own groups of actions accumulated over time. Having it split into optional groups might be a good gateway for people to start with the functionality they need, and then explore further?
Also to say (tangent): I’ve reached a point where I’m as likely to search for an action as I am to select it from a menu directly. I really appreciate the fact that you’ve prefixed all of your actions so it’s easy to filter down from a search.
You could split the library, and still handle relatively elegantly testing for its presence, something like:
let action = Action.find("MyLibraryAction");
if (!action) {
// prompt with link to library action?
context.cancel();
}
I will say for most users the “one big group” approach is not going to be very friendly or discoverable. If they search the directory for the function they are interested in, they are not likely to read the whole group description and dig through the group to find something for a specific use case. They would be far more likely to favor an individual action (if it exists) that seems to meet the need.
I think downloading and writing the library to local storage is the best case. This would allow easy versioning as well, so if the user has an older version of an action that relies on an older version of the library, it can run in tandem - maybe saving the libs as “MyLibrary-1.1.js”, “MyLibrary-1.2.js”, etc.
After several weeks of deliberation, re-working, and some new additions, I have applied some changes.
There are now seven ThoughtAsylum Action Groups, one being the original core group, and the other six containing sets of actions taken from the original, plus some new ones as well.
The groups no longer contain an action that contains the TADpoLe library file. It can be generated once you have carried out a set-up refresh by utilising the TAD action, but unless you have a very specific need to have the configuration set to call from an action rather than a file, there should be no need to generate this. I’ve left the functionality in primarily as a demonstration of how it is possible to programmatically rebuild an action.
To restore the full functionality of the previous group, you will need to refresh the core group (ThoughtAsylum), and install each of the other six groups. All of the names and sections remain the same as before.
If anyone spots anything that is not working, please let me know.
Yes. Just remove and reinstall exactly the same way as you would have done previously for an update.
If you want to restore all of the previous functionality, you now have to install and periodically reinstall seven action groups rather than just one. Something I would like to have avoided, but I had a higher level need to address the potential sync issues of the future.
I know Greg has mentioned something about notifications on action updates, so I’m hoping longer term that this may develop into an App Store-like option that will allow a user to choose to update action groups that have received updates since they last downloaded them.
I’m just finishing off a blog post for my web site that will cover what was done at a high-level. It won’t go into the why I did everything the way I did it, but might provide some additional insight into what was required to make the changes.
