Big UI changes (hopefully for the better) - right-click now spawns a menu on the canvas and launches to help the user make context decisions (like after a drag event). Drag & drop system is now 100% based on user rules (see defs/leaves.edn). Have a few servers up for demos / playing around with some sample SQL data (more coming soon).

rvbbit-frontend

I'll try and hit some of the high points, but there is so much in this release that you'll have to just discover (note to self: write better commit messages so you don't forget your own features).

Excel formulas!

You can now post-process your rowsets with real Clojure functions OR Excel formulas. You can even choose to materialize the changes into a new SQL table so you can pivot/group on them. Very handy.

Raw SQL Blocks!

Yes, yes, I know.

Rules based drag & drop system

Way of a bigger deal than you'd think. Have some special system? A weird DB? Some API call system? Now you can write drag and drop rules and functions for it and your users don't need to deal with the complexity.

Theme Madness!

Rabbit now ships with almost 100 themes(!), some subtle, some corporate, some wacky - and there is a really fast "full-screen preview" from the right-click UI modal as well.

ANSI strings as grid data? Sure.

Theme and Screen Preview

New Docker images and zip files available from the GitHub page.

Release “Snowshoe Hare” 0.2.0 · ryrobes/rvbbit

Lepus Americanus!

GitHubryrobes

GitHub - ryrobes/rvbbit: Reactive Data Board & Visual Flow Platform

Reactive Data Board & Visual Flow Platform. Contribute to ryrobes/rvbbit development by creating an account on GitHub.

GitHubryrobes

Feel free to email me, hit me up on X.

Latest version has a Docker image! We've come a long way.

I also released HareZero #1 - which is going to be a series of long form videos where I actually build something from scratch while explaining / discussing. Given that this was the first ever episode I went over a lot of basic things, keybindings, getting started, etc. It's long - but hopefully useful / interesting.

Formal documentation is still a work in progress so hopefully this can help to fill the gaps until then.

Still grinding away at bugs and features.

BTW, very open to consulting work / hire, email me at [email protected].

Check out the release on the GitHub page! Still working on a legit documentation site with live examples and documenting the entire "Clover" DSL as well as a number of other things that aren't quite obvious. I also did a number of quick and dirty videos going over some aspects that seemed easier to "show" than "tell".

Still lots of stuff to do, fix, add, etc. But at least people can give it a try! Please open Issues and Discussions on the GH page - or ping me on Twitter.

Haven't updated in a bit, lots of catch up on - but I've been focused on getting this thing out the door. So I'll just cut to the chase - almost time for the initial Alpha release. Way more content after that.

But first, a cool video of using an LLM to help you operate on a given table.

It's a simple example, but it's meant to test out the "Human to LLM to Canvas" feedback loop for completing RVBBIT-ish tasks. As the models get better, this will get better - but UI scaffolding-wise, I think this is on the right track.

Quick March development round up on some of the bigger, "demoable" things. I'm running slightly behind my planned release schedule, but I think it will be worth it - much more was accomplished than I had in my roadmap when I made the January video.

Hope to pull it all together and release as soon as I can.

Flow shadows (history)

Flows are great. Some are ephemeral, but many are not - we need a non-painful way to find out what happened - esp if there was an error or something went awry. It's pretty much what you'd expect it to be - an image of the flow as it ran with its inputs and outputs - but with a twist.

The historic flow run can be browsed via the actual flow builder UI - there you can examine the final state, run it again (with the historical materialized inputs), or fork that particular version into another.

Feels way cooler than it sounds.

Only thing left to round out the suite of features for "version zero" of integrated flows is proper scheduling - but more on that later.

Subscriptions

(an extension of "Everything is a Parameter")

You've probably heard me go on about "everything" being a parameter - and I truly think that is an important part of being able to make highly reactive and interactive data boards - but we can take that one step further by making params into (server side) "subscriptions" as well.

Think of it this way - if a param is a piece of data in your workspace, you own it, you care for it - a subscription is just a param that lives somewhere else. A param that is not yours, but you may want to borrow without having to feed and clothe it.

Sounds reasonable to me!

This way you can not only reference any flow values (and be pushed the new values when they happen), but also views and queries on saved boards (a reference to them, not a copied fork), as well as queries, views, and parameters on OTHER people's clients and sessions (even dead ones). Why other clients? Why not. It just goes to show the flexibility of this reactive data parameter ecosystem.

This can be great for traditional dashboard scenarios where you want to reference a query or a view - but ensure that any upstream changes also make it to your version as soon as they happen.

Earlier I mentioned flow scheduling - the cool thing is, when you have a system of universal reactive pieces of data - your "scheduler" starts looking a lot less like a cron job and way more like a set of IFTTT rules.

i.e. "Run this flow with THIS value, when it's tuesday, every time X happens, BUT only after the partition for table Z has landed, and only if metric Q > 500."

"Run this flow to generate the TPS reports when Bob logs in, and send it directly to his client, and play CartmanHey.wav for him."

"On Monday at 9am do X".

After all, dates and times are just another set of reactive parameters to run logic against. Will be showing this off in a future post.

Canvas map pulling

This is just a fun one, last month I mentioned flow map pulling where you were able to visually pick apart a nested structure of JSON or what-have-you and more easily get to the actual data you need. This is similar to the function on the data canvas - except instead of being hard-coded UI, it's implemented as a rabbit-code (name TBD, basically the shared data and view DSL) function just like you would call :vega-lite or :div or :h-box... simply :data-browser.

Drag out and get a reference that pulls data from the keypath you specified.

Lots of effort in the last couple of months has been on "flow" endeavors, and possibly put me behind schedule a little bit. I think it's an investment in the whole system though - and I think you'll agree.

Why are flows good and what can you do with them? Let's see.

Nice little chill video that I hope sheds light on it.

As you can see they are baked into the whole system. You don't have to use them, you can have a pure SQL + parameters + actions dashboard, but with flows it's really like "calculated fields on crack"... 👀

Been hard at work and haven't been posting - but I wanted to give a quick round up of some of the things that I've been working on. As always, forgive the Twitter videos, but it's my "go to" for stream of consciousness dev stuff these days.

So here is a bunch of neat stuff that I've been working on.

But first - you might say, "But Ryan, why all this flow nonsense, I thought this was a dashboard tool?". Oh yes, it is - but if your dashboard (or data board) is a handsome duck on the water, the flows are the little orange feet paddling like hell underneath.

...or if you want to be a handsome wooden duck with no feet (a la Tableau), that's cool too - whatever your fancy. Flows are totally optional, but I think you'll choose to use them.

More on this in a future blog post.

Anyways, in no particular order...

Changed the default flow layout to vertical, seems to be more space efficient when blocks actually have data in them...

A bit easier to have more content in blocks - things with multiple ports can expand wide instead of tall - closer to something like Max/MSP.

Also, some cool "live" Gantt chart action...

"Is this new mixed media / hyper media?"

Strange way to stumble upon it, from dashboard land, if true. Interesting thought though.

Dynamic theme params now extend to syntax highlighted surfaces / codemirror themes.

Small thing but it really "ties the room together" aesthetically (here my image-gen flow sets them automatically, based on the background image). Basically the "Data type" colors you assign to the theme will apply to those same data types in the syntax highlighter - IF you use the "dynamic" code theme.

Proper "optional" function inputs for custom functions.

This is mostly for Clojure people and those people who will be building flow primitives for others to build upon (at the moment, me) - many of you won't see or use this, but it's a very nice to have thing for the rest of us (again, me).

Flow blocks that can push UI dialog to the user.

Now this is an odd one that I've wanted in a tool for a long time...

Ask a question, verify something, create a chat bot, basically anything. Forces the flow to pause until it gets some return. Very powerful and flexible. Simple demo below.

Remember, all flows execute on the server, NOT on the client - but they can still find an operator and "ping them" regardless if they are "running" that flow or not. You can set up some pretty interesting interaction loops this way - far beyond what we think of as traditional ETL or dash action user flows.

Fun little video too, couldn't help myself with the :click-speak rabbit blocks. ;)

Flow "Map Pulling"

Just an easy way to pull apart large maps / JSON structures, super helpful when dealing with a rats nest of REST payloads, etc. Just creates a "GET" block for the keypath you drag. This is something that once I started building it, I can't be without it - and you shouldn't either!

Conditional Paths and Looping

Not something you're going to use all the time, but for complex interaction loops, etc - it can be really handy. I'd rather a system be able to do it and not need it then... you know, need it and not have it baked into the design...

A similar demo (dare I say - better?), but louder.

Echoes - "last seen" snapshots of entire working sessions

Very handy, inspired by tmux sessions + Smalltalk "images". I guess if Rvbbit is a "data desktop" this is like... multiple desktops?

This is another case of something I wanted to help me test various save files without losing my sanity - and it turns out to be a banger of an idea all around, and I take snapshots of the screen to make it sexy.

Flow Views (non-intrusive flow UI elements)

Putting it all together...

"But why would I want bits of UI in my backend flow anyways?"

Because any part of your flow can be put on a "surface", while the rest of the flow (heavy lifting + logic) runs below the "water line" (on the server) & only pushes + pulls from the surface as needed...

Business in the front, party in the back? Yes. Mostly.

Creating and running flows is great.

The visuals, the feedback loop, the almost lincoln-log-esque sense of operating something in real, tangible space. Something that can be sorely missing for a builder.

But when that's all said and done - all you want to do is INTERACT with it - be it an ETL job, some hybrid code pipeline, or literally a front-end visual script to programmatically mutate some dash elements.

I want the edges. Show me the inputs, show me the outputs and let me push and pull. The (beautiful) chutes and ladders interface of flow execution can often be relegated to just building, debugging, and showing off.

Hence we take a Mullet approach. We need 2 distinct kind of Flow interfaces.

#1 Builder, Creator, Tester.

Party in the back.

We are creative, we are visual, we need to see everything. Give me as much info as possible - live run, visual connections, step inspection etc. Map time and space. This is the traditional "node and line" type interface people think of. Super important, and I often prefer to build things this way - but also can be super-too-much-going-on for day to day flow use.

#2 User, just let me use the damn thing

Business in the front.

All the inputs for dragging in parameters, typing in literals, running the flow as you see fit - as well as all the outputs available and a snippet of sample data from the last run. Drag those values on to your boards and you will be subscribed to them moving forward, with new values automatically being pushed to your client.

Hell, even drag in the play button, and now you have a handy way to execute the flow (with it's new value overrides) without opening the menu.

If the flow is the engine, it's edges are the levers that actually control how it interacts with the outside world. Inside the black box boundaries, it could be Sputnik for all all I care.

Interesting example above.

Here is a flow that executes arbitrary Python code (I know, I know, but it's just an example, calm yourselves!). The user has a Python code text parameter as a UI block, a button to run it, and an output block that receives the results (ready for use in some other flow, UI element, what-have-you). Everything in the middle? Don't care. As it should be.

This panel is the "run-streams" panel. It basically allows you to "pin" flows to the boards you have open so you have easy access to run, mutate, read from them.

Maybe seeing it in action a bit will help.

The contraption inside the soda machine is super cool. But all I want is a damn soda. I hit the button and a soda comes out - I can look into the mechanisms some other day.

The value prop of "visual functions" lay mostly at creation and debugging time - it serves as its own "explain plan", but if it is working as intended - we just want the goods.

I feel that these kinds of design decisions are important for getting "complicated" functionality down to the end users in an ergonomic enough way where it can be wielded powerfully.

A flow with 32 steps can be seen as a beast, or it could be seen as a little river with 32 different points to set your boat in, or take it out.

Same concept, very different framing.

Which one feels more approachable?

So maybe we can have it all, baby. Serious business interactable in the front, while still letting our long beautiful locks of boxes and lines flow down the back in glorious pastel candy colored lines.

Just a few more tools for your Data UI toolkit. All customizable, of course.

Publishing a number of posts today of things that got finished in the last week or so since the announcement video. First up, some OS-like utility in your data boards - again, always optional, just another tool in the tool kit...

This means you can actually configure "windows" and "task bars" and "icons" for any Rabbit content. Run flows, open tables, etc. I haven't even quite wrapped my head around how this could be use in neat ways. It almost brings us into CMS territory - but let's not think those impure thoughts!

Check out the bottom video below for a bit more detail.

A bit of an impromptu video for you today, just a few days after the "big" RVBBIT Winter Preview video - which has been very well received, so I thank you all for that. I was up late working on a basic Hue Lights board that I want to use for a mounted touchscreen - and it uses a few features that I really haven't discussed much and thought it would be a good opportunity.

First of all, I really enjoy being able to design boards that have essentially 2 layers (a big component of what RVBBIT is all about):

• The presentation layer (glue reactive pieces of data and queries together)
• The flow layer - give the prezi layer some real utility with being able to trigger complex workflows as well as read from their outputs

This Philips Hue Demo is a nice compact little demo to make that point.

Before we get to the vid, just one more point I want to underscore. Voice. While totally optional, I think voice can be a powerful user input mechanism. In RVBBIT, in addition to all the "normal" voice things (talking to LLMs, etc) the voice input is literally just a text parameter, just like any other piece of data. Send transcribed voice to any part of your board or actions as you see fit.

Which presents us with an interesting opportunity. What if you could "assign" flows to trigger on certain phrases? For example, for my Hue demo, I attach "Hey Lights..." to the light flow. When the client hears me start off a voice input with that phrase is sends the entire phrase to the specific flow and flow step that I have configured. So here...

"Hey Lights, make the office bright green color"

"Hey Lights" signals that Flow X needs to be activated, so the entire sentence gets passed to Flow X's Step Y (all pre-configured in the video) where the flow is designed to unpack that phrase the execute the Hue API calls.

A super simple example, but opens a whole world of interesting use-cases that are all user-configurable. You are essentially configuring a "zero UI" interface.

Anyways, on to the video. Cheers. Please hit me up on Twitter with any questions.

You might have seen a curious little outro bit to the RVBBIT Winter Preview release date announcement video if you hung in there long enough.

I spoke about it a little bit on Twitter, which I'll include below. Still very much in the testing and experimenting phase, but it's a slightly different take on the "agent LLM" approach - having an AI "as an employee" model with clear task and ownership boundaries.

A unique thing about a "programmable & hackable" platform like RVBBIT is it gives things like LLMs the ability to create and communicate with the same tools as humans can, and that opens a whole new way to collaborate with them.

And besides, anyone who has ever worked in BI would agree with "Wouldn't it be great if an AI worker could maintain a dashboard after it has been published?" - take in the feature requests, make changes, have them approved, etc.

Literally the dream.

Anyways, this won't ship with the initial versions, but it's something I'm trying to get off the ground later this year.

Small thread below. Please hit me up on Twitter.

Video Link directly to the timestamp mentioned...

Appreciate all of you following my experiments, links, and micro dev blogging here - but it's almost time. If it wasn't apparent already, this video should give you a pretty good idea of what I'm going for with RVBBIT (just say 'rabbit').

Let's go!

(fun little "post credits" scene at the end also, heh)

Flow integrations continue... I was going to save "ETL stuff" for after release as an add-on, until I realized that I can instead make it a hackable visual blueprints play that can read & write to any part of the sys (actions, scripts, mutate client UI, cross-client, sub-flows...).

Way more interesting...

Drilling into sub-flows...

The plot thickens....

You knew it was coming eventually...

I've been chasing this idea for several years of a "unified" prezi/logic interface (all flow-based), while very cool, it isn't always practical for day to day data work AND prod dashboarding.

Better? A solid prezi/exploration layer with an underlying flow-runner.

A lot to unpack here, but for now - behold the experiments!

Natural feeling "sub-flows".... Naturally.

Flow are also great for integrations - they allow you to "kick" Rabbit content from one client UI to another (or broadcast it team-wide or boomerang back to you) - be it human curated, prog generated, internal LLM pushed, etc.

User-writable plugins that allow extra functionality. "Sidecar operations" for deeper analysis, generating special viz types, internal functionality, etc. Making integrations easy (or easier) for the end users...