Next generation design: A Paper UI replacement proposal

[rlkoshak (Rich Koshak)]

@David_Graeff

next generation Paper UI.

Let’s come up with a new name. By referencing PaperUI we will be primed to compare this design to PaperUI when we really need to assess it on its own merits. Just an idea.

@David_Graeff

Context help on every single page. Inline explanation texts were necessary.

Does this extend to code entry? One thing I used to love about Java development with a good IDE was not just that we get code completion, but we were also just a quick key combo away from the JavaDocs. Even some of the Ansible add-ons to VSCode and PyCharm have this and it’s a real time saver. I’ve no idea if anything like this is possible but it sure would be nice.

Comments (they are a little rules heavy since I’ve spent a lot of time with the experimental NGRE):

• The Rules List view is missing an edit icon

• I don’t like the mix of JSON and YAML for rules. I’d rather see the JSON part also broken up into YAML

• I love the Rule creation page

• It’s not shown but I would like to see the ability to create and jump to the Script editor from the Rule Creation page. For example, I drag a Script block to the grid and I have a choice of selecting an existing Script (more than one?) or new and it takes me to the Script editor page.

• Where possible, when I save or cancel something in the UI I should return to where I was. This is one thing PaperUI gets really wrong IMHO and it makes using it very frustrating.

• The example code in the Script editor doesn’t really make much sense to me. The Rule is already created on the Rule creation page. The Script part is just the “body” of the Rule. The equivalent of the code between the when and end in Rules DSL. So the only code that should be necessary here is print("This is a 'hello world!' from a Javascript rule.");. The rest of that code is setting up the Rule and Rule triggers, which is handled elsewhere in the UI. Or do you intend this UI to also be the UI for creating what we call JSR223 Rules today? I want to make sure that we give users the option to have to hand code as little as possible should they choose to, but then give them a way to gradually move into coding as far as they want/need to. I also want to make sure that conceptually, at least using the nomenclature of the NGRE as it exists right now, there is a distinction between a Rule and a Script. The Rule is a collection on one or more of “when”, “but only if…”, and “then” clauses and a Script is some hand written code that can be written for “but only if…” or “then”. When a user is coding in JSR223 style, they will be responsible for all the parts of the Rule in their code. But in the UI side, Scripts are a way to create our own custom “blocks” we can wire up with a trigger (“when”) to form a Rule. Make sense? I know the example shown is probably little more than just an lorum ipsum, but it’s a detail I think is important.

• Change the name of Timer to Scheduler or Schedule. That is really what we are talking about.

• Now that I see it, I wonder if it makes sense to use a UI more like one sees in Calendar apps like Google Calendar or Outlook for the “default” scheduler.
  
  Then under Custom we can present the cron expression type UI. We would need to include some more time based as opposed to just day based options. Users will be more familiar with that sort of interface and in the decades since calendar apps like this have existed, they have evolved into a UI like this for a reason.

• Is commanding an Item the only way the scheduler can trigger Rules? I think it is a pretty elegant solution. Does it make sense to include Astro events in the Scheduler? Then the entire Time of Day design pattern could be fully implemented in the Scheduler.

• I really like the options to select the version of an add-on to install and the buttons are clear.

Over all I like the over all look and organization. I love the hints at new features like the log viewer, health and status page, and ability to install alternative versions of bindings. I think it’s a great step forward I look forward to see how it evolves.

@5iver

I have ~200 Things and ~1000 Items. There is a lot of white space in the list view, which could be shrunk down for better viewing.

This gives me a thought. If I scroll to the middle of my list of Things or Items and switch to one of the other views, it would be fantastic if it kept my place. For example, if I’m looking at Item Foo which is number 45 in the list in the Grid View and change to the List View or the Text View I’m still looking at Foo.

@5iver

There’s a filter, but there doesn’t seem to be any option to sort Items, Things, etc.

Good idea. It would be really useful to have the option to sort by last edit time so, for example, all the Items or Things you are working on are at the top of the list.

@5iver

Textual configuration displays all Items or Things… individually would be much easier to mavigate.

But harder to copy/paste/bulk edit. I don’t know if I necessarily want ALL my Things, but having more than one I think is pretty important.

@RolfV

What I also though about, is how I currently make my rules. That is, for like 50% of my rules at the moment, a lot of mimicking other rules that I previously made. To achieve that I generally switch back and forth between tabs in Visual Studio Code. So would that in some way also be possible in a new rule interface as well? So some kind of copy-paste function for actual copying and a way to quickly and easily switch between different rules for mimicking?

Having worked with the NGRE a bit, I think a better approach for solving this sort of thing will be to either create a generic Script that can be called from the different Rules, or create a Rule Template (not shown in the mock up) that can be applied then edited as necessary. One thing to remember is that the NGRE is going to allow for more opportunities to reuse code than Rules DSL does.

@Andrew_Rowe

I have been digging around for 20 minutes trying to find the graphical rules engine project… what is it called with the node red type rules interface. That is what the rules engine should be in a ‘blue sky’ user interface IMHO. Some thing akin to IFTTT or stringify where folks with zero programing ability can piece together basic rules… someone please link but anyhow subject for another thread…

@ysc built it and it is described at Flows Builder - a visual designer for the new rules engine - #12 by ysc and the source code is at GitHub - ghys/flowsbuilder: Flows Builder - an alternative GUI for the ESH/openHAB2 automation engine

@yves

I assume that will always be related to the installed version of OpenHab.

It was mentioned that each JSONDB entry has a version field that denotes which version of OH it was created with. My understanding is OH remains backward compatible with the older versions rather than modifying the entries to comply with the new versions.

At least until such time that there is a change required by the binding that requires changing the format. But we have that problem whether you are hand writing .things files or using JSONDB.