Currently the title bar can be enabled or disabled from the dashboard site settings only and it affects all tabs.
Adding a new checkbox in the the Tab settings for title bar visibility would offer more flexibility to show or hide the title bar in selected tabs only.
That doesn't sound like a good UX to me. The frame of any UI should remain static otherwise it is rather confusing for users. Really, I'd think of Dashboard as an app in its own right so it has a theme and layout common across all tabs.
1 Like
Well to be honest that is a workaround to the fact that the title bar doesn't support any dashboard widgets.
And my UX contains a toolbar that is consistent across the tabs, but contains title, some navigation buttons, 2 gauges, etc..
Well, eventually, if your UI warrants it, you'll be better off hand-crafting something. Dashboard is great for getting going quickly and you can do some amazing things with it but it does bring a lot of contstraints.
I arrived here having the same request. My use-case is as follows:
I'm using Node-RED to run an immersive live game, not dissimilar to an escape room, and I've been delighted at how versatile and intuitive it's been to control the various hardware props. I now essentially want to present two distinct dashboard views of the system:
- one dashboard for the "gamesmaster", displaying a range of control elements. Since there's quite a few controls, I'd like to retain the title bar in order to navigate between several tabs.
- a secondary display for the players. This will be much simpler and not contain any buttons or other controls - just a few output nodes. I'd like this display to be full screen, with no title bar.
Now, I have found a way to do this by using a lot of conditional CSS hacking, but I'd love to know if there is a better way since it seems to me a not unreasonable use case.
I accept the previous comment that dashboard UIs should remain consistent, but I'm essentially trying to create two separate dashboard UIs, and I'm not quite sure how else to do that?
Dashboard is a single ui and single user interface I'm afraid. The best approach if you really want to stick with Dashboard may be to fire up a second instance of Node-RED.
Otherwise, there are alternative UI tools such as uibuilder which will let you do what you want at the expense of a little more front-end coding.
Thankyou for the reply - I appreciate it.
I will check out the uibuilder node - my "player" display is really very simple with just a handful of HTML/CSS elements, so having to hand-code it is not a problem. In fact, a plain vanilla template that avoids all the unnecessary libraries may be quite an advantage. Cheers!
No worries. The default template for uibuilder does load several libraries but you don't have to use them, just remove them from the html if not needed. Just leave in the uibuilderfe library which is the magic that lets your front-end communicated with Node-RED.
You get a simple event handler that lets you monitor for incoming messages and the ability to easily send messages back to Node-RED. There are 2 message channels, the main data channel and a control channel which lets you monitor for new connections and so on (amongst other things, this lets you send cached messages to new client connections).
If you want to use the default templates though, you get VueJS, bootstrap-vue and bootstrap which makes it trivial to produce nice-looking UI's without much boilerplate.
@TotallyInformation - Great, I've got uibuilder working perfectly! Thankyou. However, I have to admit I got a little bit confused by the workflow along the way. I'm not sure if this is the right place to do so, but seeing as it might come in useful for other users who come across this thread as I did, I wondered if I could pass on some feedback based on my experience as a new user?
I started by installing and examining the built-in default ui_builder node template, but that seemed to contain a bit too much detail for what I was after - I really just wanted a simple "display the contents of msg.payload in a div", and I'm not familiar with VueJS so some of the syntax looked unfamiliar. Then I discovered the "simple example" at https://flows.nodered.org/flow/bbe6803d9daebda5c991336cf4e5e3e0, which sounded perfect for my needs. But, for some reason when I imported the flow into my instance, although the workflow gets created successfully (i.e. the inject node retrieving quote of the day from a webservice etc), the contents of the index.html|.js|.cs do not - they seem to be created with exactly the same contents as I had in the original example.
Undeterred, I then manually edited the index.html|.js|.cs files to include the content which I extracted/deciphered from the "simple example" flow.json file. And success, it worked! Only, finally, I then decided I wanted to change the URL at which the page was published from "uib_simple" to "room_display" and, on doing that, I lost all my edits again 
Learning point is that it seems you need to choose the URL first before making any changes to your page?
I'm guessing this stems from the behaviour of the "Copy index.(html|css|js) from templates to this instance if they don't exist?" option, which I sort of understand having looked at the way that ui_builder stores in the file structure, but I just thought I'd mention that I found the behaviour a little confusing as a new user.
But the end result is great!
No. ....
Just joking of course. I always welcome feedback.
Yes, this has been a hard call. Whether to use the default template to showcase what can be done. Or whether to keep it minimalist.
In the first case, there has been something of an anticipation that uibuilder would more likely attract people who were passingly familiar with at least web development and so would appreciate the fast startup that the current template gives. I'm actually beginning to wonder whether this is a correct assumption.
The danger with having a minimalist template is that people wont "get" just how powerful uibuilder is and what it can do with minimal boilerplate.
Thoughts from people are certainly welcome.
Yes, when you create a new instance, you get the default template which you then edit. That is why newer examples - especially those that are included in the library, don't forget those - include comment nodes containing the front-end code.
Nope, you didn't lose them, they are still there! Just under the old name. Currently, when you rename a url, it doesn't rename the underlying source folder. To get them back, either add another instance and set it to the old name. Or open a connection to your server and edit the documents directly.
That is something that I need to highlight in the docs.
Also something I need to add to the To Do list for fixing in the future. Unfortunately, getting v2 out the door took a lot longer than I anticipated. Other enhancements had to go on the back-burner until that was done because v2 provides a lot sounder a foundation to work with.
Indeed. Thanks for that feedback, keep it coming! 
To summarise:
- I need to improve the documentation regarding renaming of URL's & what happens when you initially add a new instance.
- I need to see if I can handle the url name change somehow so that the underlying folder is also renamed.
- I want to see if there is any way to extend uibuilder to allow for multiple templates. Perhaps even including user custom ones. This would make it a lot easier for people to swap around. The base template would be selectable from the config panel. I've been thinking about this for a while.
The full to do list is here:
Or really minimalist: hint 
but it might help @alastaira
And yes, this stuff is crazy powerful, vue is fantastic stuff, but to "get" it, might take a bit of time.
Perfectly happy to accept that I may not be the intended target audience: it seems ui_builder might be intended for people trying to do something more complicated than the common ui dashboard; I'm actually trying to do something much simpler, but avoiding all the extra cruft it puts in. If the built-in HTTP in/template/response could serve dynamic content refreshed over websockets rather than static HTML that would actually suit me fine!
Anyway, it's working, so i'm happy 
No, that was never the only intent.
The intent was to enable more people to build data-driven UI's.
Yes, you are really just falling foul of my over-reach! I do mention in the documentation that you don't need any library other than uibuilderfe itself. It is perfectly possible to build simple interfaces manually and just using uibuilderfe to handle the comms.
The jQuery example is ideal for you once you strip out the bits that help you understand the control and send message flows. It doesn't get any simpler than that. As long as you can understant the uibuilder.onChange('msg', function('msg'){...}) part, you are golden.
That function will fire whenever your front-end receives a message from the matching uibuilder node in Node-RED. It gives you the full msg. That's it! You can do a lot more but really, that's the basics.
But sadly, it isn't that easy. Behind the scenes a LOT of work has to happen to make it all work correctly 100% of the time. There would be no point in burdening the http- nodes with all of that when it would only very occasionally be used.
You can, of course, use the http-in/-out, template and websocket nodes to do what you are asking for. But really, that makes for a much more complex flow (at least visually) than using just uibuilder since I've put a very large chunk of the required logic into a single, relatively 
easy to use node.
Anyway, glad you've now got your head around it and it only took about 24hrs, probably a fair bit less which isn't bad for now being in a position to create any manner of easy, data-driven UI's.
If you want to really simple you can just use built in http and websocket nodes - for example.. (but I'm talking really simple... )
But you still have to program in the websocket part to your own front-end code whereas uibuilderfe does that for you.
