|
To help answer questions like "who's working helpdesk right now?" or "I need
a tech over here", we used a handful of roles which were set with the
"@mention" flag enabled.
That means that someone could be focused on any server channel and having
a conversation, and post a message with that special @role syntax to flag
any people currently on duty for that function to hop into the channel to
see what was up.
To facilitate self-service for said on-duty-ness, I constructed a role-menu
specifically for those "hailable" roles.
It wasn't so much a "clock" in the jobsite sense, although some of the
logging actually would show when roles were assigned and deassigned to
people; it was more like putting on a certain colored vest, which is what
made me think of the iconography at the top.
The overall idea certainly made sense to streamline getting help to people.
For a while I wasn't sure which roles we needed to put in this, and a bit of conversation ensued around an initial set. The first layout before actually menuing it was just to show the design crew where I was headed with the idea, and obviously it would change before being put into service. |
|
|
The initial setup with item-per-line looked too squinched-together, so I tried double-spacing the entries. That made the whole thing too tall, I thought, so in the development process I rearranged the message to spread the items across the page instead. |
|
The "across" method turned out to be a bad idea as it came up totally confusing on narrow mobile devices; thanks to Anna for pointing this out. Trying to put hard newlines in the text clearly didn't work so well either. I didn't have a mobile set up to do Discord, so I had to rely on her view of it for feedback. |
|
I went back to the "tall" arrangement and let the text flow itself more or less naturally, and that turned out to be okay. On mobile, people are used to scrolling to see everything anyhow. |
|
This is more of the sausage-making that has to happen in the channel where
the menu is, and then one has to go back and manually delete all that
stuff.
The long number is the target message ID, obtainable from the target message
meatball menu
when you have "Developer Mode" set for yourself.
The sync-up process is a little klunky, and gets even worse when you
go to change any of the role icons or try to move stuff around.
Due to highly varying external demands on which roles should be in the "clock" or not and thus duty-switchable, I had to re-edit this whole thing at least three times. |
|
This type of menu was one more appropriate to graphic reaction-icons as opposed to purely numeric, but Gail didn't like some of my choices. Another *two* edit cycles because the first try didn't sync up right. Eventually we gave up on the separate "moderator" function anyway. |
|
It got messier once Safety and IRT got involved, and then it was pointed out that their roles were always pingable regardless and they didn't really need to switch anything on and off. But they seemed to want some presence in this anyway. Now I had a quandary: what to call extra items for them? I wasn't about to *de-role* their base Safety and IRT "red shirtness", because those roles inherently carried some extra sway on the server. As an interim hack I added a couple of "on-duty" role variants for them but none of that actually meant anything. Again, it was all about optics. |
|
Then there was the battle over what power any group would hold to deal
with other users, be they nickname changes or kicking out or whatever.
This went back and forth a bunch, and I kept pointing out that if any
working status was to receive additional powers, it should NOT be switched
through here since then any other staffer could attain those powers
by simply clicking a role on the Clock.
Such things needed to be externally managed, and a decision made about
who was going to handle that.
Note carefully, though: with suitable buy-in from all players, it would be possible to construct custom menus to bestow elevated power temporarily to *certain* users, or design a few bot-functions to channel and utilize parts of elevated privilege in a much more controlled way. [See the "muting" rathole, in fact.] In other words, with some effort you could write "sudo" in robot-ese. Because of the complexity of Discord's role/permission model, let alone when bots get involved, the transitive paths that can inadvertently get set up when you're messing with this stuff can be subtle and escape notice. Just like any other security problem. |
|
Eventually the directive came down, presumably boiled down to a final
decision: Lose most of the switchable roles.
At first it almost sounded like "lose the clock", but folks like the tech
crew had already decided that it was a good thing they wanted to actively
use, so I defended its continued existence in some form.
So the final state was just this, before a final pass rebuilding the clicky-reactions, and I could finally leave the thing alone. Four hailable roles left as a token gesture, and I think the only one that ever really got used was @Tech once in a while. |
|
This is what the final role-command group configuration looked like at the YAGPDB end. The YAGPDB doc on role-menus lays out how to set this up fairly well, although it's a little sketchy on how the "edit" function is supposed to work. That's one reason reworking a menu is a pain in the ass unless all you're doing is *adding* to it. |