Right now, if a command cannot be parsed after making an edit, edits are no longer watched and the command user's further edits will not have an affect. This is to prevent retry storms that blast the user with error messages.

This could be fixed by storing the editedAt field of the bad edit and only retrying to parse once the editedAt field changes.

asdfasdfasdf

As a command user / meeting facilitator, I want to edit the message content after the meeting, so that I can focus on the meeting without simultaneously trying to update the content.

☀️ SourceCred meeting attendance bot

Like a good pomegranate balsamic molasses reduction, distillation of splendor often takes some time. I’m boldly going with that as my excuse for why this took some time, yes. Also, apologies for the somewhat mixed-style writeup: this started as a list of ideas, then suggestions for changes, then a UX audit, then a blend of all the above and more. 😅

“You have to start with the user experience, and work backwards to the technology.”
— Steve Jobs

I often think about this quote when I work on any kind of interface or interaction with technology. I imagine myself using the tool or whatever, and really push my laziest and most-clueless self to the fore. I then ask “what is the ideal interface to cater to this user and their various needs?”

The rest tends to come from using it with a keenly discerning eye about what aspects of use are error-prone (whether bot-wise or PEBKAC), frustrating, or confusing to people.

(I wrote some of this before our subsequent conversations and your updates, so if you go “it already does this!” at a lot of things, Great! :D )

Ideal interface

In all the below, “user” means the invoking user who issues the command.

First, to get to an ideal minimum interface for the user (to make it faster, easier, and more accessible), I stripped out all the non-essentials from the bot using an abstracted perspective:

• No explicit Topic flag — this should be the only required input, and if no other specific flags are entered, “Topic:” can be assumed;
  • It could even use a Craig-style format to make this optional too, i.e. entering just $meeting could produce a meeting ‘name’ of “meeting-room 2021-01-22 at 21:34:13”
• No Duration: Bot could have automatic cessation and/or manual join/leave commands, and make the Duration flag optional;
• No Notes link: while we use a notes link for meetings, not everyone does;
• No Host: not everyone lists or uses hosts;
• No Channel: plenty of Discords only have one voice channel, and the default should be to watch the channel that the user is in.
• No OutputChannel: default to the invoking channel;

The result is the following Minimum User Action for activating the bot to watch for meeting Participants:

$meeting
	or:
$meeting <topic>

That’s it. Give it the name of the meeting, and nothing else.

Under the surface, this requires the following default behaviors:

• Default to watching the voice channel that the user is currently in;
  • Error IF user isn’t in one. Output: “Please include which channel I am to observe if you’re not participating yourself.”
• The first input after the $meeting command is treated as the meeting name (flag: Topic), without requiring that flag;
  • If the meeting name contains a colon, I suspect the bot might inadvertently treat it as a random flag, yes? In which case, can it support a quoted topic? “Collab Jam: Faruk <> Thena”
• Automatic polling cessation: after two polling intervals (2 mins) of no attendance in the watched meeting room, it stops watching;
  • If there are back-to-back meetings, manual inclusion of the Duration flag becomes useful to ensure separate meeting observances.
• Default the Output message to the invoking channel;
• All flags are case-insensitive, and single-word (ideally no hyphenated either);

Then following this, explain the various optional flags and their purpose, as well as how they affect the output message.

Configuration

• Filter out other bots, specific handles, handles-by-match (e.g. to filter out all handles with ‘RECORDING’ in their name);
• Automatic leave/cessation period (in intervals or in minutes, whichever is most intuitive per the configuration file);

Possible / nice to have?

• automatically capture URLs for the Notes flag output;
• message output template to allow customization of output & variables;
• meeting name (Topic) default format, for if it is to allow just $meeting ;
• (FUTURE) a wizard interface, alongside single line command invocation.

Configurable DEFAULTS (constants, can also be overridden as flags):

• DefaultChannel: “” // default to a specific channel to record when the user isn’t in one
• OutputChannel: “” // if blank, invoking channel
• AlphabetizeParticipants: true/false // default: true
• StripNonHandles: true/false // default: false
  • If enabled, this would filter out words from lines like Host or NoteTaker that sometimes end up in the output.

And then finally, I would generally have a flow for all possible error states and issues, to write out clean messaging for those flows that explain what went wrong, why, and what the user can do. I’ve already done more than is really appropriate for a designer to do without direct involvement of the dev, at this point, so I’ll save that since this requires looking at the code.

Overall, this is kind of how I imagine doing the UX for this bot.

Use the voice channel the author is currently in by default

test

I am just curious what would happen if the list of people captured by the bot would exceed the character limit for a single message. Would it be able to send multiple messages until all attendees were recorded?