A Primitive Draupnir GUI

Draupnir is built to be operated by sending commands like !draupnir rooms in its management room, and reading its responses in the room timeline. That's a universal way of interacting with a bot, but it's not very friendly to a new moderator.

So we want some sort of UI that's more friendly.

To begin exploring what a moderation GUI could look like, I built this.

The "Moderation view" column on the left is my new bit. It is an extra section in the side menu, which shows up if the logged-in user has sufficient privileges. On the right hand side is a standard room time-line view, showing some interaction in the Draupnir bot's management room.

The "Moderation view" section shows a few kinds of status information from Draupnir. These display contain the same information that we can receive on request in the timeline, only in a place where they don't scroll away and where we can hide and reveal each one separately.

How Does it Work? Limitations and Improvements

This first iteration sends command messages such as "!draupnir status" to the draupnir control room, and captures the response messages from Draupnir. It does the same for each of the several status-like commands.

When it sees any message from the Draupnir bot in the management room, it updates the corresponding view section (based on text substring matches, ugh). If you click the "refresh" button, it sends all the status-getting commands, so that the responses will (soon) come back and update the view.

Updating the view in this way is inefficient of course. There is no mechanism for Draupnir to "push" new data to this UI. We would need to design some such mechanism in order to make the interface sufficiently responsive.

When this code sends a command message in the Draupnir control room, and when a reply comes back from Draupnir, we see these messages in the room timeline view as well as in the new display. It does not attempt to suppress the timeline display.

The response messages in this version are received as pre-formatted HTML, as sent by Draupnir, not as machine-readable structured data. This limits the possibilities for display and interaction. We could re-work Draupnir to provide an API returning structured data responses. Then we could format and present the data on the client side. This would allow more flexibility in styling and filtering of the data. This would also enable the GUI to present action buttons attached to the displayed data, because it would be able to know which data elements represent a room, a message, a user-id, a protection rule, and so on.

Where Next?

Although this user interface is (arguably) a little more comfortable to use than the purely command-and-response interface that Draupnir provides natively, it does not feel like the right base to build on. Probably neither PubHubs nor Draupnir wants to continue it in this direction.

I think, more than the technical issues in getting such a view updated and displayed nicely, a bigger issue is it feels unfocused. Rather than a GUI that just has the ability to display all the possible info, it feels like we would want a GUI that focuses on specific scenarios, bringing together all the required info and control for, for example, managing a spam attack, or managing a user who violates CoC but has previously been in good standing.