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 18 hours ago 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 ;-)