NW Scheduler/Publisher - Updates, Support, and Suggestions

[NJasper]

Yes, that's definitely possible. The advantage of the app is that the entire organizational structure of the municipality is already in place. You can then check off exactly who has already been visited and what their status is. All data is centrally synchronized and available for appointed brothers. This way, you can be sure you've contacted everyone.

[NJasper]

5 hours ago, foghorn said:

Wow! You have invested a lot of work into that app already. Looks really nice. And yes, of course, we can borrow ideas from our brothers! isn't that what we're for??😉

 

Your earlier comments about lack of internet capability in early days after a disaster are definitely on target. In one recent disaster here, only one cell tower remained operational for the whole town. My understanding is that you want your app to collect needed disaster info off-line and upload it later. That would definitely be awesome if you could do it.

 

In an actual disaster, a brother might be assigned to visit 6-8 homes on day #1. He would collect info, take a few photos at each home and move to the next. So, trying to think how to do this... would your app have a DB table for this purpose, with a row for each home? Then a couple pages to walk him through the data entry? That would have many advantages and eliminate a couple bottlenecks and potential error sources.

Yes, that's definitely possible. The advantage of the app is that the entire congregation structure, including all responsibilities, is already present. So you can check off who has been visited and inventoried. All data is centrally synchronized and available to appointed brothers. I previously developed a kanban screen that visualizes the status of this. I'll use that here as well.

[NJasper]

This is what I mean by the kanban board. This should also be possible here.

[foghorn]

7 hours ago, NJasper said:

So you can check off who has been visited and inventoried.

     Yes, that is definitely one of the most important functions of any disaster response tool: make sure no one is missed! As for Kanban board idea: that works really well in disaster response. I introduced Trello kanban to our disaster relief team in 2018. They took to it right away and used it effectively. We decided not to pursue it further though, because of its public nature.

     What you have demonstrated in your sample screens looks VERY powerful and useful. What you did on your Maintenance screen could easily be adapted for disaster stabilization tasks. If you don't mind a quick question: will it be multi-user? Suppose the LDC team decides to use your system. Some of the oversight brothers may not be from your congregation or even from your town. Will some part of your system be available to them? Can several use the system simultaneously?

[NJasper]

39 minutes ago, foghorn said:

   will it be multi-user? Suppose the LDC team decides to use your system. Some of the oversight brothers may not be from your congregation or even from your town. Will some part of your system be available to them? Can several use the system simultaneously?

Yes, the system is designed with multi-user use in mind. Furthermore, it's possible to define access rights per user. This means that others from outside the congregation can access specific parts of the system that are relevant to them. The idea is that a CO can gain real-time insight into congregation data, but this can, of course, be expanded. 

 

I developed it using DOTNET MAUI (https://dotnet.microsoft.com/en-us/apps/maui). This allows you to build native cross-platform desktop and mobile apps with a single codebase. It compiles natively for Android, iOS, macOS, and Windows, and it works on Windows, tablets, and mobile phones.

 

The architecture is that all data is stored in a local database (SQLite). Using event sourcing, changes are placed in an outbox event store. These events are synchronized across all devices when an internet connection is available.

Edited Friday at 03:49 PM by NJasper

[NJasper]

The application is built not only for multiple platforms (such as Android, iOS, and Windows), but also for multiple device types, including phones and tablets.

The architecture is based on a single shared codebase with one central page controller. This controller handles all page-level events, such as button clicks and list selections. As a result, the functional logic is centralized and not duplicated across platforms or device types.

In the constructor of each page, the application determines which layout should be rendered:

• Desktop layout:
  Uses the full screen width and displays a side menu on the right-hand side. This layout is optimized for larger screens.

• Mobile layout:
  Stacks content vertically, allowing users to scroll naturally. This layout is optimized for smaller screens such as smartphones.

These are not separate applications. They are adaptive UI variants within the same application. The functionality remains identical across all devices; only the presentation layer adjusts based on screen size and form factor.

A different architectural approach was taken by NWS. They developed:

• A dedicated Windows desktop application NWS

• A separate mobile application built with Flutter using Dart, NWS Mobile and is not supporting tablets

This results in multiple distinct applications, potentially with differences in supported features and behavior.

In contrast, BARUCH uses a single unified application with one shared codebase. Both desktop and mobile versions expose exactly the same functionality, because they are fundamentally the same program. The only difference lies in the responsive layout layer.

[NJasper]

I also created a reporting module, so I can generate all kinds of reports. It's also possible to generate a PDF from Visit Report.

[foghorn]

4 hours ago, NJasper said:

The architecture is that all data is stored in a local database (SQLite). Using event sourcing, changes are placed in an outbox event store. These events are synchronized across all devices when an internet connection is available.

    Most impressive, my brother. It seems you have thought of everything. Looking at your VisualStudio layout tells  me you are quite an advanced developer - I am confident your system will work well.  Keep me in mind when you start Beta testing!😊 

    I assume your congregation is currently using NWS and NWP. Adopting your new system should be an easy task. May Jehovah bless your efforts, and may all your brothers be receptive to new things!

[Eryk]

@NJasper
May I suggest you start a new thread for you application, please. I think it deserves a place of its own ;-)

[Tonis]

More and More Brothers, have the Same issue with NW Publisher. Any ideas?

[NJasper]

On 2/13/2026 at 10:39 PM, Eryk said:

@NJasper
May I suggest you start a new thread for you application, please. I think it deserves a place of its own 😉

I will start a new thread dedicated specifically to the development of the Agape-Apps projects. To keep things properly separated, I’ve created a new account with a different email address for this purpose. I am currently waiting for the administrator to approve that account, and once it is approved, I will open the new thread there.

 

My intention with this new thread is to build Baruch together with input from the community. I have been following this forum for quite some time and I regularly take note of the suggestions and requests that are shared here — including those from brothers such as Jonathan (East Anglia). These insights are very valuable to me.

 

Since I live in the Netherlands, I am mostly familiar with arrangements and practices in the local congregations here. However, I have noticed that there are worldwide arrangements and regional differences that I am not always aware of. I would very much like to incorporate those as well, and that is one of the main reasons I need your input.

 

The foundation of the application is in English, so cultural settings (such as regional formats and conventions) play an important role. For example, I have recently resolved the date and time configuration challenges, and in the new thread I will explain in detail how this was handled. I have also found a solution for the major version-management challenges related to NWS, and I will explain that thoroughly as well.

 

For the development of the publisher app, I am using a “build-in-public” approach. This means I will share weekly YouTube videos — both on social media and here on the forum — where I transparently explain the progress, design decisions, and functional- and technical implementation of the app. 

 

This approach allows me to continuously process and implement the feedback I receive during development. Because I am building in public and sharing regular updates, suggestions can be incorporated step by step instead of waiting until everything is finished. That way, the application can grow in the right direction from the very beginning — shaped by real-world use, practical needs, and the collective experience of the community.

 

It is certainly an exciting time. At the moment, I am still a one-man army, but I sincerely hope to collaborate with brothers and sisters who would like to support and contribute to the project. I look forward to starting the new thread and to working together.

[Cruzer]

7 hours ago, Tonis said:

More and More Brothers, have the Same issue with NW Publisher. Any ideas?

 

For our congregation at least, by selecting "Disconnect" and starting over has solved this for a few of our publishers.

[cdk.h5c]

8 hours ago, Tonis said:

More and More Brothers, have the Same issue with NW Publisher. Any ideas?

We had that as well (only some publishers had this problem). 
Usually an Admin has to open NWS Desktop, go to “App-Persons”, select the Person which can’t connect and press the “refresh person” button. 
 

if this fails he could try “reset PIN”. The personal pin changes but you could connect with the new PIN afterwards.

[Marky]

This has happened to us when a publisher starts using a new device.

1) Ask the publisher to uninstall the NWP from the old device.
2) Make sure you give them the Person PIN from "App Persons" and NOT the Person ID in "App Devices." The numbers can look very similar.
3) If it still doesn't work, what Daniel just posted has always worked for us. In "App Persons" highlight the publisher and click "Reset PIN." Wait a few minutes for the system to populate the new PIN and then it should definitely work for the publisher.