Next generation design: A Paper UI replacement proposal

I created some diagrams and slides for the openHAB Basics videos I’ve been making on my YT channel. I was planning to share the slides one way or another after I got through the last topic in the series (Rules), likely by creating separate topics for each section here on the forums. Here is an example slide, showing the overall “model” of OH2 components in SVG format.

Concepts

If this could be useful to the next gen GUI documentation, I can put that task of sharing higher on my priority list…

2 Likes

:smiley: I once drew something very much like this only it was a bit more comprehensive (and incorrect in a couple of places). It was also way back during OH 1.x. But it is interesting to see how different people draw the same concepts. I wish I could find it again. Lets talk about OH 2 Drawings . Scroll down and you will see a version that looks very similar to yours.

I did make this different layered view at some point too, I can’t remember why:

It is obviously missing the concept of a Bridge. I think I made it before that was commonly used.

One thing to note, if you want to make drawings for use in the docs, it was decided way back when that draw.io is the tool to use which will provide the raw editable files so others can edit it later.

I think a drawing like that could be helpful in the Concepts section of the docs. I don’t think it belongs in the PaperUI NG docs. Those should strictly “how to use” the UI and not cover the whole OH architecture. At least that’s my opinion.

1 Like

Yes that looks like a good overview.
I have found a graphic once that I included as a placeholder on https://davidgraeff.github.io/paperui-ng/tutorial-3.html.

That is what I’m aiming for. The texts should end up in the Paper UI NG repository. Either as markdown, processed during the build, or straight as html, like I’m doing that at the moment.

Do you envision the docs for this becoming a generic OH tutorial (using PaperUI-NG of course)? That opens the scope quite a bit but I like the idea of the docs and the embedded tutorial in the UI being the same.

I expect a person who installs OH for the first time not to read our website documentations first, except the “Install” part maybe.

That persons first contact will be the website interface (I have named it Setup & Maintenance) instead. I see the responsibility on that interface to teach the user the core concepts of OH and where to find those concepts within the interface.

After he/she has finished the tutorial, the person needs to know that he/she wants to install “bindings” to configure “things” and, if necessary, create “channels” which need to be “linked”.

3 Likes

OK, so the docs we are really after is the Beginners Tutorial (improved and completed) using PaperUI-NG as the interface.

I’m going to open a new thread now and explain the scope. PaperUI-NG / Beginner's Tutorial

Everyone who is willing and able, please join in!

Yes… perfect template for openHAB3 new user documentation!

OK folks. The work that is presented here is awesome and it really helps to show what is possible. However, it is a bit premature. Before this or any other proposed replacement for PaperUI or any other major part of OH is to take place, it will need to be discussed and approved by the yet to be established Architecture Council (hopefully very soon, once the snapshots are working again).

This approach is one potential approach and it is exciting to see where it can go and what is possible. But isn’t the only approach nor the only prototype.

I don’t want to stop the work but I do want to help direct the discussion a little bit from “this is what WILL replace PaperUI-NG” to “something like this COULD replace PaperUI-NG”.

Stay tuned for the Architectural Council process announcement which I think will bring some more context and direction to the discussions.

Thanks!

Rich

3 Likes

It sounds like you want to stop people from contributing good ideas and waiting for the AC, although I think that all texts, images, tutorials made for this design study are re-usable for every other future prototype. I mean that’s the entire purpose of this design study, I guess.

Cheers

1 Like

Not at all, but lots of users are responding with the apparent assumption that what is presented here is what will happen. I just want to inject a little context. It’s a proposal of what could be. Not a fait accompli. Some or all of these ideas will likely become incorporated into the next version of PaperUI. But there are other ideas out there too and the process for how the ideas will be adopted is not yet defined.

What is presented here is great and I did say I don’t want to stop the work, but there are certain aspects like config file formats, Rules builder approach, etc that have a huge impact on the future direction of OH and needs to be adjudicated by the AC. There are other developers who have done some work in this area that are not part of the discussion as well (e.g. Yannick has already built a prototype Rule’s editor for the NGRE).

Perhaps unless someone comes up with something radically different that the AC agrees to. I’m aware that there is another prototype that exists that is not being discussed right now. As a for instance, I’m already looking to have to rewrite about 30% of my existing NGRE docs to meet this GUI. I’m looking at about the same amount of work to meed Yannick’s Rule builder too.

And starting to build the docs at this point generates the impression that what is presented is what will happen. And we don’t know that yet.

Finally, Kai did ask us to hold off on some of these discussions until the AC is a little more defined so we don’t rile up the users like happened on the config file threads. My comment above is in part to respect that request as well.

3 Likes

At long last… This was really necessary.

Wrong thread ^^

True ^-^

I tried the design study, but it failed on firefox (65.0, 64bit) Finally got a glimpse of the future (very promising!) when changing to Chrome :slight_smile:

Oha, thanks. I usually check Firefox as well, but I missed a recent change.

I’m currently thinking about the rule editing. It’s not an easy task.

Editing is already possible, as seen in the picture, but how to present the three categories best?

Maybe having a three column design, or a tinted background behind triggers/conditions/actions respectively.
Or something like a frame, like here:

1 Like

There is a lot I don’t like about IFTTT, but their recipe builder is kind of nice. Break it up into a sort of wizard flow maybe for the initial creation.

Yannick’s prototype uses a top to bottom arrangement with color coding and a more “yahoo pipes/Node Red” arrangement of elements. So all the triggers go at the top. Then all the conditions, then all the actions at the bottom. Each section is denoted by a different color and sometimes shape.

Speaking of NodeRed, they have a little more free form (I don’t know if Yannick’s is presented top to bottom of constrained to top to bottom).

In both cases I don’t know if I like the need to double click to drill down into each node for the properties. I like the way the parameters are presented right at the top level here, though users will quickly run out of space if they have more than two of any one type.

I don’t know if it needs a frame if you have some other way to show like types. Rules pretty much flow on one direction so position on the graph could do it. Color can do it. Shape can do it. Any combination of the three could do it.

One thing that would be nice though is to have a special shape or color for the “run another rule” action. In that case clicking/double clicking could take you to that other rule. Double clicking a Script Action or Script Condition should open the code editor.

The lines are visually instructive but I’m not sure they are strictly needed. The triggers are going to pass to the conditions and finally the actions. Unless there are constructs in the NGRE JSON Rules I don’t know about that’s all that is allowed.

I’ve spent some time with the current PaperUI UI for this so I don’t really know the full of what’s possible with these Rules.

1 Like

There is this one construct that neither Paper UI nor Yannicks really good Flow Editor handle as far as I know. And that is Inputs/Outputs. That’s what you see in the above picture. I have modeled Outputs to be on the right side and Inputs on the left side of a “component”.

Those connections already bring in some “flow lines”, that’s why I struggle with the idea to add more visual connecting lines like Yannick does.

I’m also more left to right oriented in my first attempt. Top to bottom is another option.

Yannick is cheating a bit though. He is “compiling” the flow into real rules in a second step (because rules can’t handle if/else branches). I’d say the core should either support if/else for conditions or we need to limit ourselves in what is possible. But better not pretend that rules (without embedded scripts) can do something that they actually can’t.

I have closely looked at the input/output concept of NGRE and it is indeed possible that a Trigger connects to a condition and at the same time to an action (bypassing the condition). Conditions are also kind of on their own, because they are executed anyway within a rule, if they are connected to other rule components or not.

Definitely. It’s coming for the design study. Mainly to find out if a code editor dialog on top of a (complex) rule graph is doable. Paper UI does the same, and I’m not fully convinced, but we’ll find out.

What are the inputs and outputs in this case though?

For a trigger the input is “off screen” as it were, some event. The output is “rule triggered!”

The input for the condition is always “rule trigger x triggered!”. The output of a Condition is either to forward the “rule trigger x triggered!” or nothing depending on how the conditional evaluated.

The input for the Actions are “rule trigger x triggered!” and the output is, like the event, “off screen”.

Given this, is there something I don’t know or understand or does the fact that there are input/outputs on the nodes not matter that much in this context?

As long as it is consistent I don’t really have a preference. I’m sure it’s one of those areas where everyone will have their own preference.

I agree. I can’t speak for him but I suspect that was one of limitation with the JSON Rules that caused him to abandon the prototype until NGRE matured a bit. Because indeed if/else does not appear to be supported and we shouldn’t fake it.

But even with what is offered now is so much more than Rules DSL users are used to it’s going to be really powerful I think.

OK, good to know. So the lines are needed. I was starting to wonder if lines were needed at all. But there still really isn’t an output beyond executing the Action. Though if one implements a Condition Script, there is no end to the side effects they could cause from that script. :frowning:

I can already see the support posts on that one. :cry:

Inputs and Outputs are more like this:

An MQTT topic received trigger can have configuration (for example the topic to watch. But the user can use a wildcard topic here).

One possible output is the actual topic and another output is the received message. You can then connect those to for example the comparison condition or to a text-to-speach action.

Not many components support inputs/outputs though, because Paper UI never visualized them. But it is code wise really easy to support configuration as well as inputs.

Not really :slight_smile: The main thing that led me to wait a bit was that NGRE rules weren’t running anymore after an openHAB restart (they were left in the “uninitialized” state because of some bug, which I believe has been fixed since). I really believed the script actions and conditions could replace the DSL in most cases - you can even import libraries!

One of the purposes of the Flows Builder was to actually test an idea - re-using the NGRE as-is and especially its “run another rule” module to build more complex flows à la Node-RED, which could include “else” branches.
Using prefixes and tags the resulting rules are hidden in Paper UI so they wouldn’t be modified or managed (or even run) anywhere except in Flows Builder.
Basically a " when T then do A, then (if X then do B else do C)" flow is implemented using 3 rules (IIRC :joy:):

  • Rule 1: when T (trigger), do A (action) then run Rule 2 and Rule 3 checking conditions
  • Rule 2: do B (action) but only if X (condition)
  • Rule 3: do C (action) but only if NOT(X) (condition) - there is no way to negate a condition in the core so the client would calculate it for known modules.

So no need to alter the “IFTTT-like” model of the NGRE, just chain simple IFTTT rules together to achieve something more complex.

I actually added support for outputs in the code editor autocompletion for scripts.
Given a N1 node which is a trigger like (N1 is also the UID of the trigger module):

you get the outputs (oldState, newState) in a subsequent script editor:

image

or even the outputs from another node using the ctx variable - even those from other rules since the “run another rule” action preserves the context:

image

Input/Outputs are hard to grasp at first, they are not documented at all…

1 Like