Client Application Discussion

[owen]

Below is a copy of the conversation between @matthias and I regarding the client side application for ClimateGains.

@owen

If we are going for a standalone interface (not one tied to signal or other third party applications) - which I recommend, the safer route would be to do a progressive web app that, as you said can then be compiled to a native mobile application using a framework such as Ionic (https://ionicframework.com) or Tauri / Electron as you mentioned, although I’m less familiar with those two last tools I don’t think it’s too much of a stretch.

@matthias

My thinking as well. Ionic / Tauri / Electron does not really matter and can even be switched later. Just mentioned Tauri because my brother made good experiences with it. It produces super small apps, as it relies on the system-installed Webkit component instead of shipping its own.

@owen

What is your general timeframe for the backend and how do you see the front end development of the application in relation to that timeframe?

@matthias

Since there is not exactly plenty of time for this project, backend and frontend will have to be developed in parallel over the runtime of the project. We’ll figure out a way how you can start with frontend development more or less immediately, way before the backend is ready. This can work when defining the API interface between the two first, and they you can write your part against a dummy API implementation that only serves static responses.

@owen

Are we prioritising a mobile native app or a responsive web interface?

@matthias

I don’t get the question. We seem to agree that the fronten will be implemented with web technologies (HTML, JS) and eventually packaged into an app via Ionic, Tauri or the like. That would mean we don’t prioritise a mobile native app, since that in my mind would mean “all Java, using Android system APIs” or even better “all C++, using Android NDK”. The problem with that is that getting a nice design implemented exactly as specified takes a lot of effort with Android system widgets … web tech is much more flexible for that, and has been your tool of choice with great success to make well-designed software, so let’s stick to that?

Or are you asking if “that software using web tech” should be structured as a single-page application internally rather than using a page-and-response structure?

@owen

Since it is a mobile centric app the question pertains more to how much desktop browser functionality there will be (I’m guessing account management and an overview of funding / approvals will be expected, but video recording and location access won’t) - how much desktop functionality are we aiming for / where we draw the line between the two.

@owen

What are your thoughts on user account management and onboarding - which authentification process for logging in from the app, verifying email addresses and phone numbers, managing user preferences? Would be good to know which direction you’re leaning for this.

@matthias

As far as I understand, this is already implemented in the UNDP backend that we intend to use. So we’d stick to what they have and use, and your frontend would access it via an API (which already exists).

@owen

Workflow: what tools aside from Github and this platform may we need to collaborate (on common assets such as UI elements)? Figma seems like a good solution for this and perhaps you aren’t fussed one way or the other, but would like to know your thoughts.

@matthias

I was going to ask you the same. So, since you like it and Nadia likes it as well, let’s use Figma.

My only concern is that a lot of the work done in Figma will be lost in the sense that it (probably) cannot be taken over as is into your JS development process. So if you find anything to improve that situation, such as a Vue library to prototype UIs, or to generate UIs from Figma screens, let me know.

About tools in more general: I propose to use Github issues (incl. the “Milestone” and “Project” features there) to distribute and organize the work. It worked well for tat purpose in my past projects. And when we do design work, let’s stick to open source software and open formats and include the source files in the Git repo; that would be most compatible with the Prototype Fund mode of operation, which requires all results to be open source. Would probably mean, using Inkscape (SVG format) for vector graphics, and GIMP (XCF format) for raster graphics. No Photoshop, Illustrator or the like, since its exports to open formats are generally very poor.

@owen

As an aside - for video encoding and hosting, Mux (http://mux.com) has worked very well for me as an all in one service with a good API. It may not fit with your intentions if we want to host these videos on our own servers (plus as you said bandwidth / storage space will likely be a non-issue), but thought it was worth mentioning.

@matthias

Thanks, I’ll have a look. May be relevant for the backend side. Your frontend will have to cope with recording video while there is no network access, and upload it later when there is access. Tauri has ways to access Android APIs and own native code (in Java or C++) for such purposes, and we’ll probably have to collaborate closely to get that stuff right. I have no good architecture for that part in mind so far, so any pointers and inspirations are welcome at this stage Have done some Android native app development in the past, so we should be able to figure something out.

cc/ @nadia @matthias