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.
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.
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.
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