WebXDC apps live in a chat, and all chat members can interact with them.
I suggest a simpler draft-editing apptype, for apps which
live on a single client
are not visible in the chat
can only access the draft messages of that client
have sed-like capabilities
Use cases
A very simple draft-editing app might replace all instances of “teh” with “the”, or expand a set of shortcuts and abbreviations. More complex ones could fill such perennial requests as markdowns, and emoticon replacement (:smile: producing ).
If the draft-editing apps were independent extensions, and set up in a way that allowed them to be added to a client or core if appropriate, this would offload developers, and give users the freedom to expand functionality in directions they want.
UI
Draft-editing apps could be click-to-run, or toggled on/off. Where frequent access is not needed, they could be in a submenu somewhere. A row of dockable buttons just above the text-entry field might give easy frequent access where needed.
I’m not suggesting a windowing system! More “[button to] run a preset sed command on my draft text”.
By test, there’s room for about a dozen square buttons in one row across my mobile screen, which is more ready-access mini-mini-apps than I think I’m likely to want. Alternate UI suggestions welcome!
Supporting to “dock” webxdc and allowing access to DC UX & native API is a recurring idea. I can’t put my finger on which topic covers it the best, but this comes to mind:
This is a much narrower proposal than clientside bots; these draft-editing apps would not have read or write access to the internet, the filesystem, the chat window, or anything except the current draft text.
They would be significantly more sandboxed than WebXDCs, with far more limited dependencies and abilities.
Then you realize that it would look even cooler if the emoji replacement happened in real time similarly to how it is done in other messaging apps. And thus you realize that the compose box needs to be fully replaced by a single webxdc rendering the text itself and handling each key press. This would also come in handy for spell checking, as some platforms still lack this crucial feature.
I could also envision a live rich text editing widget in which you could type markdown, while it rendered a preview for it (either in the same box as in Discourse or under it) to send as HTML email at the end.
Are you sure that you could provide sufficient value for a user if the whole I/O model only allowed to post-process the text in one-shot after editing is finished?
Not condemning replace-as-you type per se, it is cool, and I think I’ve seen as-you-type configurable regex replacement. But I’d rather have permutative mix-and-match drafttext-editing apps than a monolithic replaces-the-compose-box app, even if mix-and-match meant one-shot postprocessing.
I absolutely would not want my compose box to be a browser! That would be overkill and seems not very secure. DeltaTouch is already getting unusably slow for me in large chats, too, so I’m unkeen on slowing the compose window.
Expanso looks like it could be useful for simpler things (emoji not markdowns), but I don’t think the average user would use it for DC customization even if they weren’t on Android. I’m not super-keen on emoji replacement or markdown myself, but a simple general tool seems easier to implement than either. It would also allow things I would actually use, like alttext.
How do you plan to add alt text, via local image processing?
Also, to support the use case of rich text formatting, the transformation must support changing the type of the output from plain text to HTML, so additional metadata or API would already be involved.
I would hope you planned to confirm sending following typo autocorrection also, so that would need some further API or logic.
I could also envision slash-like commands in the same box like how certain messengers implement it for common actions, such as switching chats, changing your per-chat display name, avatar, changing the group name, kicking, /me (prepending your name to the message) /shrug (and other sideways emoji shorthands), sending in a named sticker, producing an invite link to your other groups, etc..
What could preferably be only done through live editing is autocompletion of the name of participants.
Spell checking could first highlight all your errors after initial submission and ask for confirmation or redrafting, but that’s a bit clumsier than if it was done live.
For alt text, I am not sure you’d have access to the attached file itself, but appending an alttext to a known filename (in plaintext or with the HTML image alt attribute) would be possible even without such access. Using the file’s internal alttext would be great, but.
I’d assumed that sending HTML markup would work. Regex could manage that, though Pandoc does it more elegantly.
If a draft-editing app could edit either on click or fully-automatically on send, then you could press the app button, inspect the result, and then press send.
Autocompletion would not work if not live, but expansion would.
I really am trying to suggest something very basic: just saved stream-editor commands, packaged in convenient GUI form. But it does not look like happening, and honestly there are many other features I’d far rather have.
).