Help Me Decide How to Change This

Hi everyone - I’m looking for some advice…

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 :face_with_hand_over_mouth:

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

You could even make a Pole to find unused action .

Two different methods are being used:

Action Directory: Search, Evaluate, Choose, Download

ThoughtAsylum: Download, Search, Evaluate, Choose

Is it possible to permit the search, evaluate and choose functions for ThoughtAsylum to occur before a decision to download one the actions is made?

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.

2 Likes

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.

And moving action into the right groups (for keyboard access) is nice too.
Remember those iOS users.

1 Like

Last night was the first time I downloaded TAD - and I’m grateful for this resource. Solved many points on my wish list.

My suggestion would be option #2:

Would make it more useful.

Looking forward to seeing this evolve. :rocket: