Really impressive. 
I definitely like the new look and especially the new “Maintenance” section and the enhanded Add-Ons.
1 Like
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
Could you post your ideas and issues with screenshots to the GitHub issue list please, thanks 
And yes I like to replicate some karaf webconsole features, e.g. use the rest interface of that service.
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?
You are in a Webbrowser, the natural habitat of “tabs” 
use two sessions and the textual mode. Or did I misread you?
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.
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
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.
Looks nice.
These days I don’t work with paper UI, I work completely with text file, wil that still be possible?
See the discussion link in the first post 
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.
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
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
1 Like
I’m liking the starting point. Looks very good. Thank you!
Yes that’s a more fitting term.
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
habmin is not discontinued, only Paper UI. I suggest a clear separation of concerns:
- Paper UI: Administrative tasks, configurations, addons, manage Things, Items and Rules.
- Habmin: Floorplan, Sitemaps etc
- Habpanel, Android App, iOS App: Control interfaces
There is no official or community decision yet, but if its going my way, the old textual configuration syntax will vanish completely. (Import tool will exist then of course)
1 Like
Sounds logic, thanks for clarifying!
@David_Graeff - excellent design study, I love that I’m able to play with it and see how it will affect my (and other users’) usage of the Paper UI. I appreciate how much effort you’ve put into this! Here is my take/comments on it from using it for only a few minutes:
- Agree with @5iver about item/thing display (I also have hundreds of each); would like to see more filtering options as well…
- Would like to see a “dark theme” - the current PaperUI is hard on the eyes in the evening
- YAML also hurts my eyes (and brain)
but I’m OK with it for light usage like item/thing configuration (less so for rules, where I prefer the Rules DSL, which is in my personal opinion the number 1 advantage we have over Home Assistant). - I appreciate the use of a VSCode control for the textual configuration (e.g. for familiarity with my current daily use), but will it allow the inclusion of the awesome openHAB extension from @kubawolanin? Or any other extensions/code helpers like VSCode does? Also, see my point #2 (dark theme)
- Would like to see Zwave-specific functionality built in/carried over from Habmin (mesh/device viewer, controller reset, network heal, etc…), so it’s a one-stop-shop for all my configuration (the integrated log viewer is already a great step towards that).
- As @5iver mentioned, there is a lot of wasted screen real estate on higher resolutions. I use an ultrawide monitor, at a resolution of 2560x1080, and would love to see the middle column extend to fill the screen (perhaps even add another column to the grid views, so more things/items/rules are visible on the screen at the same time).
In all, I love the functionality and improvements over the current PaperUI, it’s a huge step forward! Thanks for taking this on and allowing us users participate in the design process!
1 Like