# Viability for this? Touch screen login/out project

**URL:** <https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966>\
**Category:** General\
**Created:** [26 June 2024 09:17 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966 "2024-06-26T09:17:19Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [26 June 2024 13:59 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/21 "2024-06-26T13:59:11Z")

</div>

> [@TotallyInformation](#):
>
> OMG! Is that really how it works? Do they assume that there is one one person with the same birth date registered at the surgery! Or do they throw up a list of names

I think it's more likely that the tablet has some knowledge of who has an appointment that day. possibly that hour. and can keep asking questions till there is only one possible answer.  
I have never seen a list of names, nor have I ever had to press "No".  
I suspect that if I did press "No" it would say "You do not have an appointment. If you have a medical emergency please go home and dial 999"

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [26 June 2024 14:01 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/22 "2024-06-26T14:01:25Z")

</div>

> [@jbudd](#):
>
> I think it's more likely that the tablet has some knowledge of who has an appointment that day. possibly that hour. and can keep asking questions till there is only one possible answer.

😀 I certainly hope so. Though knowing some of the GP system vendors, nothing would surprise me any more.

> [@jbudd](#):
>
> I suspect that if I did press "No" it would say "You do not have an appointment. If you have a medical emergency please go home and dial 999"

🤣 or maybe "Please book an appointment using the NHS App"

---

<div class="post-metadata">

**Author:** ![ghayne](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ghayne/32/39_2.png) [@ghayne](https://discourse.nodered.org/u/ghayne)\
**Post date:** [26 June 2024 14:02 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/23 "2024-06-26T14:02:47Z")

</div>

Give each member a keyring RFID tag.

---

<div class="post-metadata">

**Author:** ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd)\
**Post date:** [26 June 2024 14:09 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/24 "2024-06-26T14:09:14Z")

</div>

> [@ghayne](#):
>
> a keyring RFID tag.

Edit: adjusted for hot climates.  
I would have a very _very_ low tolerance of some sodding machine bleeping and flashing lights at me if I wave my keys at it wrongly. Especially if there's a pint of ~~warm ale~~ cold lager waiting with my name on it.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 07:50 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/25 "2024-06-27T07:50:20Z")

</div>

Thanks all.

# Another BIG ISSUE I now have!

For the sake of it, let's say we need only the person's name.  
First and Last as there are a lot of people with the same first name.

Big problem for me if I am going to _Offer_ this as an option.

## Why?

Well, let's say we have a _data base_ with the people's names.

```auto
Fred Flintstone
Barney Rubble
Wilma Flinstone
Betty Rubble
Bambam Rubble
Pebbles Flintstone

```

(No, I have no imagination)

# All the names would be stored in a database!

The names appear as _buttons_ on the screen, as adding text to `buttons` is easy.  
I just said buttons in two ways. That's because I'm not sure that will work.  
See below.

## Though I fear it won't be that easy.

Let's say we have a long list of people attending.  
They will appear as a list of _buttons_ that scrolls once the screen is full.  
They would be sorted in alphabetical order. Not the order in which they arrived.

So a BIG PROBLEM I see is how to sort the list of names each time a new one is added.

And another BIG PROBLEM is how to _update_ the names available when new members are added?

To _Log out_ they press their name on the list.  
Though I am not sure if that should be DOUBLE press.  
To get around accidental pressing when scrolling.  
(Not sure yet)

# Summary of new _Problems_

- Create a list of names from a dynamic database for when people log in.
- Sort the list of people alphabetically on the screen when new people come in and others leave.

New thought - just talking here.  
When people leave for that day, rather than deleting their name:  
Mark them as departed.

This way if you want to know if someone was _here_ and you can't find them, you can look in the list and see they have departed. (Or not so you know to keep looking for them)

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 June 2024 10:01 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/26 "2024-06-27T10:01:07Z")

</div>

For people signing in/out:

Depending on how long that list is, you may need to split it - maybe 2 levels, first name level and then filtered to first name/last name. Not a problem though if the possible list is manageable (which it probably won't be if it goes over \>1 screen).

Or use an on-screen keyboard and dynamically filter as people start to enter their name. This is how most UI's would do it.

* * *

> [@Trying\_to\_learn](#):
>
> Create a list of names from a dynamic database for when people log in.

So you have a master reference list of members? People register their presence so they are copied to the "live" data and when they leave, they are removed from the live db.

The live data can simply live in the browser if you only need a single device. Just some JSON should be fine. Send in/out notifications to Node-RED so that you can keep records for management information.

> [@Trying\_to\_learn](#):
>
> Sort the list of people alphabetically on the screen when new people come in and others leave.

If your live data is an in-memory array (JSON), then sorting is a single line of JS.

The tricky part is dynamically changing the UI. And that depends on what "helper" library you will be using. Will you be using D1, D2 or UIBUILDER?

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 10:08 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/27 "2024-06-27T10:08:47Z")

</div>

Ok, I made a mess of the explanation.

The `database` is the full list of members. (Not changed daily) It is from where the list of available names is ..... sourced.

For the sake of simplifying it, I'll say the search is done for their first name.

So when they go to sign in - from my example - _Fred_ will press the `F` key.  
All the members names (first) starting with `F` will be listed - alphabetically.

They see `Fred Flintstone`. Press that button, and they are then _signed in_.

I'll stop that part here.

Sorting: Great.

WRT which dashboard..... I - on my machines - am on the original one.  
I have no experience with either of the others.

I'd guess D2 may be better/easier?

Clearer?

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 10:25 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/28 "2024-06-27T10:25:54Z")

</div>

Ok, to help with the example, I'll give a better list of names:

```auto
Andrew Black
Andrew Jones
Chris Jones
Chris Smith
Garry Patterson
Greg Lenton
Harry Hudini
Larry Lounglizzard
Peter Jackson
Xavier Alba

```

(Yeah, I need to get better at making names. But this is at least a bit better than the original one I posted.)

So if Andrew comes in, when he presses `A` he will see the two Andrews listed and press his one.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 June 2024 11:13 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/29 "2024-06-27T11:13:26Z")

</div>

> [@Trying\_to\_learn](#):
>
> The `database` is the full list of members

Assuming that the members list isn't millions of people 😁, I would dump a copy of it to the browser every morning or on page reload. I have a page that gets a list of at least 18,000 people entries - I load it from a CSV as it happens (using Node-RED of course) - on page load, it is read and sent to the browser. Once in the browser, it takes around 1.4 seconds to turn it into the live data (it gets restructured from a flat form to a multi-layer object which is a pretty heavy process) and then it builds the full list in the UI. So that's a LOT of front-end processing! Yours should be much easier AND you won't need to worry about UI load performance since you can simply do it automatically each morning.

> [@Trying\_to\_learn](#):
>
> I'd guess D2 may be better/easier?

Weeeeeeellll - would you really expect me to say that! I personally think you would be better off using UIBUILDER to create your bespoke web UI without the need for all of the Dashboard overheads. BUT, I recognise that would require some learning on your part. BUT, you will certainly be having to do that anyway in switching from D1 to D2 so why not use UIBUILDER where you will mostly be learning how to use modern HTML rather than being restricted to a single framework. 🙂

But the choice is yours. Either UIBUILDER or D2. D1 is end of life.

> [@Trying\_to\_learn](#):
>
> So if Andrew comes in, when he presses `A` he will see the two Andrews listed and press his one.

Yup, I get it. All very straight forward. BUT, not, I think, standard D2 stuff so in any case, you would be creating custom stuff. In my personal view this is easier to do in UIBUILDER than with D2 who's main aim is to make simple dashboards trivial. UIBUILDER's main aim is to help build data-driven custom UI's.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 11:52 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/30 "2024-06-27T11:52:11Z")

</div>

Yeah, I kinda forgot that the entire list needs to be.....

Well, hang on.

I really have no idea on the mechanics of how this bit works.

_NEW DAY_ Things are reset.  
The member list is - round figure - 150 people.  
That's a _data base_ and is loaded into NR.  
There is a _RUB_ for me there, but I'll get back to that later. It isn't critical, but is problematic at this point as I see things.

A list is _held_ by the program.  
Person 1 comes in and taps the `log in` button.  
`26` buttons appear - and some others, but for the sake of keeping to the task at hand......

They press the letter for the first one of their first name.

All members with the first name starting with that letter are displayed.  
(Things get complicated here)  
There wouldn't be more than 10 people with the same first name.  
In this case TEN _buttons_ are displayed with all the names. First / Last.  
They tap that _button_ and they are marked as `in`.  
The screen wipes and then displays a _list_ of `in` members and they are the only one shown.

Second person comes in.  
Repeat of most of what I already said.

They click their name.  
The screen is wiped and the list is recreated and displayed. (Sorted)  
All names are _buttons_ so the people marked as `in` can click again and become `out`.

When they click their name again, they are marked as `out`. Their name stays on the list.  
This is wiped/reset at mid-night.  
_Stuff_ could be done with names still marked as `in` at the end of each day.

I shall concede (admit?) that UI\_Builder may be the way to go.  
But that is _ontop_ of the dashboard - or a complete replacement of?  
Sorry, again: I've been happy with the toys I have and this is something which has got my interest.

Other stuff would be logged also - but hidden from the user - like time/date of `in` and `out`.  
Maybe show the `out` time to help people looking for someone who's gone _home_.  
Did they _just_ leave, or did they go a while back?

Alas I'm probably going to have to make a test run of it and I don't have any machine with a either `dashboard 2.0` or `ui builder` free.

That's going to be fun for me working that problem out.  
Sorry, my problem.  
Shall have to see if I can dig up an older machine - NUC - and get it up to date with `ui-builder`.  
But it would only have a VERY EARLY version of NR on it.  
Like 1.x or maybe even earlier. `0.9`?

Are the _functions_ I mentioned within the scope of `ui-builder`?

- Getting a list and making each line it's own button
- Allowing change of text displayed in said _button_  
(Refreshing of screen is ok.)

There are other things needed, like _who is in charge that day_ button.  
And maybe a menu for admin stuff.

## Oh, back to the problem I mentioned way back:

The main list would be stored on an external machine.  
That way _admin_ can add/remove members and this propagates to this machine.  
So it would/could be a network mount and a `watch` for if/when the file is edited.  
Is that possible?  
And - alas - it would be probably not much more complicated than a CSV file. ☹  
`JOSN` is asking too much of the powers that be.  
Though it would probably have a lot more information than just names.  
But that could be filtered out (parsed?) when the file is read. Yes?

Logging would be needed too.  
Unsure of the specifics. But things like daily numbers attending. Names maybe needed.

I'll stop here.  
Thanks.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 June 2024 12:43 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/31 "2024-06-27T12:43:25Z")

</div>

> [@Trying\_to\_learn](#):
>
> I shall consed (admit?) that UI\_Builder may be the way to go.  
> But that is _ontop_ of the dashboard - or a complete replacement of?  
> Sorry, again: I've been happy with the toys I have and this is something which has got my interest.

Well, as this is effectively a stand-alone system, the only impediment to using a different "toy" is the learning aspect. And that probably comes down to any desire (or lack thereof) to learn something new and whether you think that learning VueJS as a single, specific framework or UIBUILDER as an entry to learning W3C standards-based web app building is more useful to you. 🙂

Either tool is a valid approach. But I don't believe even D2 will give you a lot of help and so you are likely to still need a fair bit of bespoke code. Personally I find UIBUILDER easier to do at least simple bespoke stuff than I do VueJS. Because you don't really need the help that VueJS gives. Frameworks like Vue are good for really complex web apps or maybe where you have a team of people working on a web app.

But to directly answer your question - UIBUILDER can and does work ALONGSIDE both D1 and D2. Having an _integrated_ page using a mixture is bit more complex but in this case, your new page is a stand-alone page anyway.

> [@Trying\_to\_learn](#):
>
> Alas I'm probably going to have to make a test run of it and I don't have any machine with a either `dashboard 2.0` or `ui builder` free.

That is not a problem. UIBUILDER can be installed and won't impact ANYTHING. It adds some overhead of course but not a lot. You can, indeed have UIBUILDER, D1 and D2 all installed on a single instance of Node-RED with no problems.

> [@Trying\_to\_learn](#):
>
> Other stuff would be logged also - but hidden from the user - like time/date of `in` and `out`.  
> Maybe show the `out` time to help people looking for someone who's gone _home_.  
> Did they _just_ leave, or did they go a while back?

OK, so don't forget to keep the Node-RED and the browser parts separate in your head. D1/D2/UIBUILDER all deliver data to the _browser_ where processing happens separately from what happens in Node-RED which is on the _server_.

If you follow a UIBUILDER path, you are able to create a web app that can be (if you want) COMPLETELY separated from any other web app (e.g. one for management information).

So you will likely add a uibuilder node to your Node-RED flows that will deliver the page for the members. You dump the master data to it and let the browser do the processing. But you add a simple function to your buttons so that user in/out button presses are send back to Node-RED for other processing. UIBUILDER's client library has simple functions for doing that.

YOU then have the choice as to whether you put your management information processing onto the same UI as your in/out OR put it onto different page(s), using another uibuilder node. You have all the relevant data in Node-RED (on the server) and so can process it wherever you want, send it and/or store it as desired.

> [@Trying\_to\_learn](#):
>
> Shall have to see if I can dig up an older machine - NUC - and get it up to date with `ui-builder`.

Or simply run up another instance of Node-RED! If you really want to keep this separate.

> [@Trying\_to\_learn](#):
>
> But it would only have a VERY EARLY version of NR on it.  
> Like 1.x or maybe even earlier. `0.9`?

You certainly don't want that. You need current versions of everything.

> [@Trying\_to\_learn](#):
>
> Are the _functions_ I mentioned within the scope of `ui-builder`?
> 
> - Getting a list and making each line it's own button
> - Allowing change of text displayed in said _button_  
> (Refreshing of screen is ok.)

Absolutely. Or, more accurately, they are in the scope of HTML, CSS and Javascript and may be helped/made simpler with uibuilder 🙂

In fact, UIBUILDER will give you several options for doing this. UIBUILDER's no-code nodes have both a list element (just send it an array) and a way to easily update any on-page element such as a button. For the updates, all you need to do is to make sure that every button has an `id` attribute that uniquely identifies it.

So you _could_ run all the processing from Node-RED and might not even need any front-end code. Though that would increase the dependency of networking between the tablet and the server (assuming they are separate devices). Given the preference for tablets to going into a low-power mode and cutting off comms, my own approach would be to minimise that and simply minimise the comms doing more processing in the front-end. But the point is that UIBUILDER gives you the flexibility to do it the way you want. I'd be happy to work through some of the options with you as you home in on a preferred solution.

> [@Trying\_to\_learn](#):
>
> There are other things needed, like _who is in charge that day_ button.  
> And maybe a menu for admin stuff.

Which again could be part of the same page or on a different page via a different uibuilder node if you want. With the advantage being that different people could connect to the management page(s) and would not need to be bothered with the in/out page.

> [@Trying\_to\_learn](#):
>
> So it would/could be a network mount and a `watch` for if/when the file is edited.  
> Is that possible?

Absolutely. On the understanding that you are running Node-RED on a network that has access to the data. Node-RED manages the DATA, UIBUILDER manages the communication between Node-RED and the browser.

The data can be file-based or a DB or some mix. Node-RED provides the interconnectivity.

> [@Trying\_to\_learn](#):
>
> And - alas - it would be probably not much more complicated than a CSV file.

Absolutely no problem. As mentioned, I already use Node-RED and UIBUILDER to process big CSV files from work such as a dump of our 18,000 staff details. Seriously, this is pretty trivial. And I can help you with some recommended 3rd-party libraries for processing tabular CSV data should you want to do the filtering and/or reshaping of the data _either_ in Node-RED _or_ in the browser.

> [@Trying\_to\_learn](#):
>
> Logging would be needed too.

Yup, Node-RED will take care of that as well.

> [@Trying\_to\_learn](#):
>
> But things like daily numbers attending. Names maybe needed.

You will have the data in Node-RED if you follow the process I outlined before. So processing, storage, logging not a problem. And display of that management information simple enough, either to a different page (could even be a D2 dashboard!) or to the same page but hidden from normal view behind a menu, all straight-forward enough.

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [27 June 2024 18:07 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/32 "2024-06-27T18:07:11Z")

</div>

I think that you should consider taking a step back and look at Australia's privacy laws around storing & processing personal data first, and then build your framework around it.

For example;

> [@Trying\_to\_learn](#):
>
> ...there wouldn't be more than 10 people with the same first name.  
> In this case TEN _buttons_ are displayed with all the names. First / Last

In the UK, you would not be able to do this, because you would be exposing personal information (First/Last names) of members, to others.  
It's a long since I had anything to do with GDPR, so there may be exceptions, or workarounds, but it's worth exploring legal options before spending too much time on system design.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 June 2024 19:53 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/33 "2024-06-27T19:53:49Z")

</div>

> [@Paul-Reed](#):
>
> In the UK, you would not be able to do this, because you would be exposing personal information (First/Last names) of members, to other members.

Whilst checking the law is always a good idea. 🙂 In most cases, you would indeed be able to do this since not only should members have signed up and therefore agreed to some level of data sharing, just the names are not considered privileged information in the context of a signing in/out "book" which is, after all, not exposed to the Internet.

However, you absolutely should ensure that the terms and conditions of membership include some minor level of record keeping.

I'm not an expert on Oz law but to the best of my knowledge, their privacy laws are not that different to ours. I'm not an expert on UK law either, but I do know a fair bit about UK privacy, Information Governance and the use of sensitive data. 🙂

So assuming this is a "private" club in that it requires members to sign up, you are likely well covered already. If in doubt, also put up a sign for a few weeks before implementation telling people what is proposed and giving people a way to object if needed.

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [27 June 2024 20:41 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/34 "2024-06-27T20:41:22Z")

</div>

> [@TotallyInformation](#):
>
> assuming this is a "private" club

Andrew has not mentioned it being a 'private' club with no unauthorized access, so we really don't know much about it's status, and that's why I suggested doing the research first to find out what exceptions/workarounds there are in Oz law, before spending time on system design.

This is a quick guide for UK small clubs/societies, which raises a few things to consider, but Oz compliance may be different.

> **[GDPR Compliance Guide for Small Clubs and Societies | DataGuard](https://www.dataguard.co.uk/blog/gdpr-for-small-clubs-and-societies)**
>
> Discover how GDPR applies to small clubs and societies. Learn how to ensure compliance and protect your organization. Read more now!

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 20:58 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/35 "2024-06-27T20:58:50Z")

</div>

Well, there is (now) a big board with all the member's names (first/last) and we all wear our name tag when attending.

So seeing other names when signing in isn't really a problem for privacy, as all the names are visible anyway.

But, point taken.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [27 June 2024 21:01 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/36 "2024-06-27T21:01:24Z")

</div>

@TotallyInformation  
Thanks very much for that reply.

I'll dig up the other NUC I hope soon and get to updating/installing the stuff this afternoon.

So if I run another version of NR - keeping the status quo on the machine - all I'd do is make a new `.node-red` directory (say `.new_node-red`) in the `home` directory and run the install script from there - yes?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 June 2024 21:16 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/37 "2024-06-27T21:16:54Z")

</div>

> [@Trying\_to\_learn](#):
>
> So if I run another version of NR - keeping the status quo on the machine - all I'd do is make a new `.node-red` directory (say `.new_node-red`) in the `home` directory and run the install script from there - yes?

You can call it what you want, you provide the folder as a parameter to the startup.

If you want to run the same version of Node-RED, that's all you need. If you want to use a different version of Node-RED, you can use my alternate installer or install manually to a new folder.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [28 June 2024 06:10 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/38 "2024-06-28T06:10:04Z")

</div>

Oops,

If you say I can run ..... `ui-builder` on top of the `dashboard` then there isn't a problem.

I'm about to start the journey down this now.

---

<div class="post-metadata">

**Author:** ![mudwalker](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@mudwalker](https://discourse.nodered.org/u/mudwalker)\
**Post date:** [28 June 2024 09:05 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/39 "2024-06-28T09:05:07Z")

</div>

Hi Andrew,

I have Dashboard 1.0, Dashboard 2.0 and UIBUILDER all running in the same installations of Node-RED 3.1.9 both on an RPI4 and an Ubuntu 22.04 Laptop.

I have had no conflicts with any of the flows/web pages I run in parallel.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [28 June 2024 09:08 UTC](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966/40 "2024-06-28T09:08:59Z")

</div>

Thanks.

I'm in the process of updating an _old_ NUC from 18.04 to 24.04. At the last stage now. But it is slow going.

Would it be ok to ask you for help with the concept of how to do things with `uibuilder`?

Just that as much as other people have helped to now, I don't want to abuse their help.  
That's meant in a kind way.

As I have 0% understanding of how to use `uibuilder` and I believe it may be a bit of a challenge.  
Only based on most things I take on are way above me. 😉

[Previous page](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966.md?page=1)

[Next page](https://discourse.nodered.org/t/viability-for-this-touch-screen-login-out-project/88966.md?page=3)