Openhab-addons: [Administrational UI] Deprecate Paper UI for OH 2.5

[davidgraeff]

Paper UI has many shortcomings that lead to

• increased required support on the community board
• force people to use DSL text files

I know that a unified UI is being worked on for OH3. But OH3 might be end of this year earliest. And the concepts and the web-ui team are not yet formed.

I hereby propose and like to discuss the possibility of replacing Paper UI for OH2.5 already
with https://davidgraeff.github.io/paperui-ng/ (repository: https://github.com/davidgraeff/paperui-ng)
and to remove the current dashboard as well (as that would then be incorporated in this UI).

Status of paperui-ng

• By end of this weekend it will be fully functional.
• It has some OH3 visions included in the code-base. Those will be shown based on feature detection however. paperui-ng is fully compatible to the OH 2.4 REST interface.

Some additional REST endpoints will help however, that are planned for a unified UI anyways:

• List installed UIs (like Grafana, Nod-Red and so on) that are currently shown on the dashboard, generated server side.
• Scheduled-tasks

Almost all of the maintenance screen requires additional or modified REST endpoints. So that page would probably look a bit different for a pure OH2.4/5. But again those REST endpoints would be required for a future unified UI as well:

• Easy log access (I have a websocket interface in mind)
• Services: Extended status (like the Thing status)
• OSGI bundle list and a simple start,stop,restart option.
  Super easy to generate, we just need to expose such a list via REST.

I have a detailed list of shortcomings of the current REST interface here: https://github.com/davidgraeff/paperui-ng/blob/master/assets/roadmap.md

Impact on other areas

• Documentation: If the proposal is accepted, I would voluntarily adapt all documentation pages that talk about or feature Paper UI.
• Maintenance of paperui-ng: There is already an overview like developer documentation in place.
  
  
  
  • I will do my best to document the project more, write some how-to's (how to add another page to... etc), document the scss style structure and the different js bundles.
  
  
  • I have commented most my js files with JSDoc, so those bundles will probably get a nice looking generated doc page (maybe via https://esdoc.org/). Most js bundles contain web-components (oh-codeeditor, oh-context-help, oh-github-issues etc). So those can be re-used by a future UI. Especially if they are well-documented, I guess.
  
  

Concerns and FAQ

• But we can't change the UI now and then again for OH3: I tend to agree, but also strongly disagree. OH3 is a new product. So we can change whatever we want, and also the UI again.
  
  
  
  • For the OH2 product line, there will be a usable admin interface at least though, that is easier to maintain.
  
  
  • The new interface has a beginners guide + tutorial section included: The required support in the community forum will rapidly decrease and people can finally start to think of cool things to do instead of fiddling with currently existing shortcomings.
  
  
  • Support for ALL features of the current REST API, and probably also some REST endpoints that are currently only planned but do not exist yet (but will for OH2.5).
  
  

Cheers, David

[lolodomo]

Why replacing ? Just add it as a new UI and let the user decide what to use.
After a period of tests, if no feature is missing compared to Paper UI+dashboard and the app is stable and appreciated by most of users, we could make it the new default but still keeping old UIs.

I take a look to the demo and it looks promising.

[davidgraeff]

@lolodomo I would agree, but at the moment there is an initiate going on to reduce the currently available UIs. And if I'm just adding another UI, maintainers are very likely to not even considering it. My proposal is therefore aiming at fully replacing Paper UI.

[MHerbst]

I generally agree with @lolodomo . This would give everybody the chance to test the new UI in real life with the chance to go back easily to the old Paper UI if there are any issues with the new UI. But I would limit the lifetime of the old UI. E.g. 2.5 will contain both UIs and 2.6 only the new UI.

@davidgraeff The new UI really looks good but I would like to have the chance to get rid of most of the animations. They are nice if you see them for the first time, but after some time they are annoying.

[lolodomo]

Step 0 would be a test jar so that we can test the new UI.

If there is no more maintenance for Paper UI, this has to be clearly mentioned in documentation but not a valid reason to suppress it immediately from the distribution, while it is working well and used by thousands of users.

Basic UI was a replacement of Classic UI but Classic UI was not removed. Few users probably still prefer Classic UI to Basic UI.

[davidgraeff]

rid of most of the animations

I'm still experimenting. Some animations have a purpose, some others are pure aesthetic. You are talking about the page change fading, I guess? (I don't consider the index/home animations as a problem. This page is seen only once. The pro user will set the option "Show me maintenance as start page")

Step 0 would be a test jar so that we can test the new UI.

Actually... I like to change how Web UIs are embedded into OH as well. There is no reason for a pure html+js+css application to have a jar bundle.

I'm building an extensionservice at the moment, which polls npmjs for "openhab-ui" categorized packages. Those will appear as install-able like the current marketplace extensions.

If there is no more maintenance for Paper UI, this has to be clearly mentioned

It has been mentioned on several occasions. But we cannot add that to the documentation for obvious reasons. How does it look like if you download openHAB as a newcomer and the most prominent UI has the tag "deprecated".

while it is working well

That's the point. It does not work well. Most users are giving up in frustration after a time with Paper UI. Please see all the comments in the community board. This is kind of urgent actually. Because with Alexa etc you need to be able to tag your items. Paper UI can't do that. With HaBot you need to semantically tag (i.e. item meta-data) your items. Paper UI can't do that. If you want to use the experimental rule engine: Paper UI pretends to support that, but you can't connect inputs/outputs and the javascript embedded editor is a plain 3 line height input box and so on.
Paper UI is not sufficient anymore and nobody is maintaining it.

Basic UI was a replacement of Classic UI but Classic UI was not removed. Few users probably still prefer Classic UI to Basic UI.

I never understood that. Have one UI and support themes. But that's another topic.

I propose: Find me one user that works with joy with Paper UI and I we will ADD this one (providing alternatives). If we can't find a user, we REPLACE Paper UI.

[MHerbst]

I'm building an extensionservice at the moment, which polls npmjs for "openhab-ui" categorized packages. Those will appear as install-able like the current marketplace extensions.

Please correct me if I am wrong: as far as I know, npm requires a node.js installation. If this would mean that node.js would be required for openHAB only to install some add-ons then I would call this "overkill". I would not want to install this node.js stuff on a productive environment on a Raspberry.

[davidgraeff]

Please correct me if I am wrong: as far as I know, npm requires a node.js installation. If this would mean that node.js would be required for openHAB only to install some add-ons then I would call this "overkill". I would not want to install this node.js stuff on a productive environment on a Raspberry.

npm itself is a js application that is true. But I'm not building up on npm. I'm requesting the repository via API and download within java.

[nibblerrick]

Because with Alexa etc you need to be able to tag your items. Paper UI can't do that.
That's a big point. I begun with alexa & homekit relatively early in OH2, so I expected some quirks and I used textfiles, so I can tag easily. Not a problem for me.
But it is just really strange, you use paperUI, then you read somewhere tagging, you don't find in in paperUI, you may have habmin installed, there are "tags", you can't edit them and in the end you should use the rest-API to add tags (the what? <- from a new user's perspective) or use textfiles.
And there are many more users with alexa, googlehome or homekit out there today.

[davidgraeff]

FYI: This issue is attached to the wrong repository as soon as https://github.com/openhab/openhab2-addons/pull/4923 has been merged.

[kaikreuzer]

I agree with @lolodomo and @MHerbst: IF we are considering this UI, it would have to be an addition, but not a replacement - we cannot remove Paper UI from the distro from 2.x.

I stated my opinion already here: "Imho we should not make any fundamental changes to openHAB 2" Removing or replacing the Paper UI clearly is a fundamental change and a lot of documentation that exists out there on the Internet (and even published in books on "openHAB 2") would be broken.

We have around 100 pending PRs for new bindings and those should be merged for 2.x - that's really what all maintainers (especially here in this repo) should help to achieve.

New UIs will also require new concepts on the REST API, in the core framework and at many other places. Such a project easily gets huge and I don't see that a minor version change from 2.4 to 2.5 should have that. openHAB 3 signals to the user that it likely is a bigger change to 2.x (and as such it is much more a marketing version than anything else) and we should really combine all efforts to getting this done.

[davidgraeff]

I have no problem with this being an addition, and not a replacement.

But Kai, you cannot force contributors (which happen to be maintainers) to only do PR reviews here and not work on openhab-core or UIs. We can have a 1000 bindings, if the user experience is bad, people are moving to Home Assistant and other solutions.

At the moment you DO force people to use .thing and .item files however. And even worse, those are not migrate-able to a pure UI version at the moment.

I would like to use OH now and not only for OH3, especially because there is no roadmap on when we can start to break things in openhab-core. And I have spend around 110h (according to stats) in the community forum to support users with MQTT and other bindings of mine, mostly, I repeat, mostly, because of the .thing and .item file syntax. The average Joe user doesn't want to use those files.... he must use them currently. Personally I have started to not respond on any of those questions anymore.

New UIs will also require new concepts on the REST API

Definitely, yes. But I'm only requiring additions for this project.

Such a project easily gets huge

This project is finished.
All required REST Apis are documented and I plan on adding those to the core.

It feels like OH3 is seen as the holy grail. Many useful additions can be done without revolutionary (aka breaking) steps though.

[kaikreuzer]

I can only repeat: "3" is marketing, meaning users can expect new stuff, while 2 means that people get stability and stuff they expect being on version 2.

I already mentioned last month that we should work NOW on new features and improvements. And I don't have an issue if we provide openHAB 3 early access builds by next week, so everyone who does wants to benefit from the new features is able to use it.

[davidgraeff]

early access builds by next week

Oh. Sounds good. OH 2.5M2 is required before that can happen, I assume? (There were at least a few people that needed to downgrade from OH2.5M1 to OH2.4 because of issues.)

Then I drop this Issue now and just make a normal PR to the -webui repo at some point.