Next generation design: A Paper UI replacement proposal

Development
1

Hello community,

in this post I’m going to introduce a functional* design study for a next generation Paper UI.
I tried to consider all remarks and objections that we as a community discussed in Next generation design : Ideas & Discussions.

*functional: You will see demo/example data only, not coming from a real OH instance. Most of the lists and pages are already dynamically populated, some are not.

Important: This is a design study and not set in stone. Your feedback and contribution is key for a better OH maintenance app.

I’d like to say a few words on some key aspects.

Design / Usability

Responsive design was one of the main goals.

  • The centered 3-column design for large and huge screen estate
    allows a clear design concept with actions/sub-navigation on the left, main content with a maximum width for better readability in the middle and a context area (mostly for context help) on the right.
  • Medium sized screens will collapse and condense the layout. The context help becomes a dialog.
  • On small screen estates the left actions/navigation area becomes a slide-able menu.

A have added a real home-page / start-page with a greeting and links to further topics like a tutorial page to address newbies.

All (code) text editors have syntax highlighting and validation. Ideally they also have auto-suggestions: That is not part of this design study yet, as I’m not yet connecting to the LSP (Language Server Protocol) service of OH.

A UI for Rules and for Timers. Timers are unfortunately not yet done, I need your help with a proper design to express even the most complex recurring cron timer expression.

Newby friendly

  • A tutorial in Paper UI NG is key to make a new user become familiar with core OH concepts and were to find those within the app.

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

  • Self-contained. I don’t want to take any files away from you, but OH should also be configurable completely without ever seeing a single configuration or log file.

  • Templates/Snippets for Scripts: A blank editor is not helpful at all. Templates/Starters will help make the user familiar with the syntax. Templates/Snippets can be fetched from anywhere, we could setup a github repository for example. At the moment I provide one basic template.

Functionality

A big concern at the moment is that we have a dual system of configuration. You either use the UI or files. And you cannot change to the other option without a massive time investment.

Please have a look at how I see this solved. Every thing/item/rule/timer has a “storage association” (aka filename). The backup service will consider those for exporting to several storage units (aka files).

Every thing/item/rule/timer has a list, grid and textual view mode. The latter one allows find/replace, batch editing. For the format I have settled on YAML for now. Please have a look and tell me if you like that syntax. Maybe there is a better suited format that I have not yet considered.

Find known problems more easily:

  • Binding / Service configuration pages show all open github Issues and Pull requests. This way a user can easily see if a problem he/she is experiencing is already known.
  • A troubleshoot section is shown in the context help, as long as the binding provides a “troubleshoot.md” file in the source code repository (yeah I know: not a single binding is doing this yet).
  • A changelog page and links to it in some places make users aware of breaking changes, to not repeat the MQTT introduction disaster again.

Technologies

At the moment there is no UI developer group yet, so it is not clear how we will decide which technology stack is to be used. For this design study I settled on these rules:

  • No js framework if not required: Most of the pages are just pure html with web-components and css.
  • Optional parts should be optional (“Progressive enhancement”): For example web-workers, service-workers, ajax-page-loads and so on.
  • For reactive parts like list rendering, the Vue framework has been used so far. Templates are part of the html pages though, so that designer/non-programmer can still participate and contribute without learning any Vue specifics.
  • The Visual Studio Code Editor (monaco editor) has been selected as the editor of choice.
  • For graphical rule editing I have chosen Rete-JS.

Browser support: This app targets modern evergreen browsers. This excludes internet explorer and I think that’s alright. You will also have some issues at the moment with Microsoft Edge until they have changed their rendering engine to the Chrome one, as planned for this year.

For the technical interested audience I explain the reasoning: We fell high with our choice of using the Angular JS framework for Paper-UI-old. Basically nothing can be recycled. In my opinion web components are the logical choice to not repeat that ever again, at least not for the next 10 years. Web components found their support in browsers only just recently (2018) and Microsoft did not yet catch up completely with Edge. Apple Safari, Firefox, Chrome and Opera and their respective mobile versions support this standard to the full extend.

Without further ado, please have a look: https://davidgraeff.github.io/paperui-ng/index.html

Cheers,
David

55 Likes
2

Wow!!!
Very very nice indeed
I particularly like the access to logging levels and documentation at the fingertips

2 Likes
3

I think this is a fantastic evolution of openHAB that will make it soooo much easier to get into for newcomers and regular users.
Very nice work indeed!

4

Really impressive. :+1:

I definitely like the new look and especially the new “Maintenance” section and the enhanded Add-Ons.

1 Like
5

LOTS of very nice things in here! I realize this is just a design proposal, and I don’t mean these to in any way detract from the awesomeness, but here is some feedback…

  • 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.
  • It would be nice to see what you propose for the list views… there’s not much currently in there. Having lots fo Things and Items, I prefer the listview over the gridview, as it’s more manageable.
  • A Tree view would be nice… which groups Things by binding, Items by type, etc.
  • There’s a filter, but there doesn’t seem to be any option to sort Items, Things, etc.
  • The view options reset when navigating away/back. The current Paper UI does something similar, after selecting a filter and navigating back from viewing a detail. Filter/view settings should remain until cleared, and persist between visits.
  • Textual configuration displays all Items or Things… individually would be much easier to mavigate.
  • The Thing properties look like they will be pretty cramped over on the right, and looks grafted on. Same for the menu on the left (above 1280x720).
  • Above about 1280x720, there is a lot of empty white space to the right and left of the screen. Below that, it looks a lot better.

Have you seen the Karaf Webconsole? Karaf in Paper UI would be pretty slick!

5 Likes
6

Could you post your ideas and issues with screenshots to the GitHub issue list please, thanks :slight_smile:

And yes I like to replicate some karaf webconsole features, e.g. use the rest interface of that service.

7

First of all, really very cool, looks nice.
I am not going to repeat comments that others made, but I can especially relate to the comments of @5iver.

Additionally:
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?

8

You are in a Webbrowser, the natural habitat of “tabs” :grin: use two sessions and the textual mode. Or did I misread you?

9

Absolutely… but are you referring to an existing issue, or suggesting that I open new ones?

Rule template functionality is already available (and functional) in the NGRE, so look forward to this in OH3. But it’s a little premature to get into developing a UI for rule development.

10

I disagree. OH3 discussions and development should happen in parallel as well. Of course that can only really kick off when the new build system and Esh merge back has been completed.

But if anyone of you have good ideas please sketch them, ideally with image material, and add them to the GitHub issues list of this paper UI NG repository.

1 Like
11

I would personally be fine using textual mode, but I think a big part of the NGRE, and basically of what you are displaying in the “Rules” section is aimed to be a system where you do not have to use code, to aide the users not comfortable with coding. Of course you can use two tabs, but you would have to take extra care that such a construction would not cause issues. I have seen several applications that start to behave very unpredictable when you are working in two tabs in parallel.
And then you’d still like to be able to copy things probably.

I commented on this because it is something that @David_Graeff showed in his design study, and the things I suggest might be of relevance to how to further develop this in the future.

12

Looks nice.

These days I don’t work with paper UI, I work completely with text file, wil that still be possible?

13

See the discussion link in the first post :slight_smile: This design study is really just the frontend. It requires some additional services like for example a backup service that can export/import yaml files. But every existing part of the core is untouched.

For OH 3 I would of course stand up for the idea of making all Xtend/XText (.thing/.item/.rule files) based parts of the core optional/deprecated. But that’s another topic.

14

David, first off, bravo for an excellent and well developed design study. I am amazed at how so many of the community’s suggestion were incorporated such as the log view and also the progress you made since I last checked out your preview version maybe two weeks ago.
I think this shows new and old users alike what this platform could be with a unified polished front end and still function with all the versatility that we all want from openHAB.

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…

As Kai says (paraphrased not quoted) we need to structure our discussions a little better

15

Terminology comment only - perhaps Scheduler is a better term in this ‘cron’ type usage.

Timer more like countdown and/or stopwatch functions within rules.

2 Likes
16
1 Like
17

I’m liking the starting point. Looks very good. Thank you!

18

This is a huge step forward: go for it :grinning:
Thx a lot @David_Graeff

19

Yes that’s a more fitting term.

20

A very good evolution of the GUI! Thanks!!
Imho, a floorpan integration with controllable item icons would be great (cfr habmin)
Additionally, a way to integrate/edit the v1 textual configurations trough the GUI (syntax cracking?) would make things easier

1 Like