Create your own Mastodon UX

I’ve been discussing Mastodon UX wish lists with some new acquaintances there. This excerpt from A Bloomberg terminal for Mastodon concludes with part of my own wish list.

In a Mastodon timeline, a chatty person can dominate what you see at a glance. When we participate in social media we are always making bids for one another’s attention. As publishers of feeds it’s wise to consider how a flurry of items can overwhelm a reader’s experience. But it’s also useful to consider ways that feed readers can filter a chatty source. Steampipe’s SQL foundation affords an easy and natural way to do that. Here’s part of the query that drives the list view.

select distinct on (list, person, hour) — only one per list/user/hour person, url, hour, toot from data order by hour desc, list, person

It was easy to implement a rule that limits each person to at most one toot per hour. Next steps here will be to apply this rule to other views, show the number of collapsed toots, and enable such rules on a per-person basis.

As a warmup exercise, I decided to first add a simple control for boosts that enables me to see my home timeline with or without boosts. To give technically-inclined readers a sense of what’s involved in doing this kind of thing with Steampipe, I’ll describe the changes here. I’m obviously biased but I find this programming environment to be accessible and productive. If it seems that way to you as well, you might want to try out some of the items on your own UX wishlist. And if you do, let me know how it goes!

Here are the original versions of the two files that I changed to add the new feature. First there’s home.sp which defines the dashboard for the home timeline.

dashboard “Home” { tags = { service = “Mastodon” } container { // a text widget with the HTML links that define the menu of dashboards } container { text { // a block that displays the HTML links that form a menu of dashboards } card { // a block that reports the name of my server } input “limit” { width = 2 title = “limit” sql = <And here’s the new version. It adds an input block called boosts, and passes its value to the referenced query.

dashboard “Home” { tags = { service = “Mastodon” } container { // a text widget with the HTML links that define the menu of dashboards } container { text { // a block that displays the HTML links that form a menu of dashboards } card { // a block that reports the name of my server } input “limit” { // as above } input “boosts” { width = 2 title = “boosts” sql = <Steampipe dashboards are built with two languages. HCL (HashiCorp configuration language) defines the UX widgets, and SQL fills them with data. In this case we’re selecting static values for the boosts input. But any Steampipe query can run there! For example, here is the input block I use on the dashboard that filters the timeline by the list to which I’ve assigned people.

input “list” { type = “select” width = 2 title = “search home timeline” sql = <Now here is the referenced query, query.timeline, from the file query.sp which contains queries used by all the dashboards.

query “timeline” { sql = < ‘url’ is null then content else reblog_content end as toot, to_char(created_at, ‘MM-DD HH24:MI’) as created_at, case when reblog -> ‘url’ is not null then ‘🢁’ else ” end as boosted, case when in_reply_to_account_id is not null then ‘ 🢂 ‘ || ( select acct from mastodon_account where id = in_reply_to_account_id ) else ” end as in_reply_to, case when reblog -> ‘url’ is not null then reblog ->> ‘url’ else url end as url from mastodon_toot where timeline = $1 limit $2 ) select account, person || case when in_reply_to is null then ” else in_reply_to end as person, boosted || ‘ ‘ || toot as toot, url from toots order by created_at desc EOQ param “timeline” {} param “limit” {} }

And here is the new version of that query.

query “timeline” { sql = <The original version uses a single CTE (aka common table expression aka WITH clause), toots, to marshall data for the concluding SELECT. The new version inserts another CTE, boosts, into the pipeline. It uses $3 to reference param “boost” {} which maps to the self.input.boosts passed from home.sp

The SQL code is all standard. Postgres is the engine inside Steampipe, and I sometimes use Postgres-specific idioms, but I don’t think any of those are happening here.

The HCL code may be unfamiliar. Steampipe uses HCL because its core audience are DevSecOps pros who are familiar with Terraform, which is HCL-based. But its a pretty simple language that can be used to describe all kinds of resources. Here the resources are widgets that appear on dashboards.

The other thing to know, if you want to roll up your sleeves and try building your own dashboards, is that the developer experience is—again in my biased opinion!—pretty great because if you’re using an autosaving editor you’ll see your changes (to both HCL and SQL code) reflected in real time.

To illustrate that, here’s the screencast we included in our blog post introducing the dashboard system.

Not shown there, because we wanted to focus on the happy path, is real-time feedback when your SQL queries provoke Postgres errors. The experience feels very much like the one Bret Victor champions in Inventing on Principle. The core principle: “Creators need an immediate connection to what they’re creating.”

Here’s the wrong way that too often constrains us.

If there’s anything wrong with the scene, or if I go and make changes, or if I have further ideas, I have to go back to the code, and I edit the code, compile and run, see what it looks like. Anything wrong, I go back to the code. Most of my time is spent working in the code, working in a text editor blindly, without an immediate connection to this thing, which is what I’m actually trying to make.

And here is the right way.

I’ve got this picture on the side, and the code on the side, and this part draws the sky and this draws the mountains and this draws the tree, and when I make any change to the code, the picture changes immediately. So the code and the picture are always in sync; there is no compile and run. I just change things in the code and I see things change in the picture.

Bret Victor

We want to work the right way wherever we can. The experience isn’t available everywhere, yet, but it is available in Steampipe where it powerfully enables the experimentation and prototyping that many of us are inspired to do as we delve into Mastodon.

If you want to try this for yourself, please check out the setup instructions for the plugin that maps Mastodon APIs to Postgres tables, and the dashboards that use those tables, and ping me (on Mastodon if you like!) with any questions you may have.

See also:

1. Hope for the fediverse
2. Build a Mastodon dashboard with Steampipe
3. Browsing the fediverse
4. A Bloomberg terminal for Mastodon
5. Create your own Mastodon UX

Copyright © 2023 IDG Communications, Inc.

Source