jawrainey/gabbermobile

Xamarin Gabber mobile applications with native UIs

Gabber Mobile

Gabber mobile applications written in Xamarin using native Android and iOS UIs and shared codebase via PCL.

Project Structure

Path	Info
/Gabber.Android	The Gabber Android mobile application codebase
/Gabber.iOS	The Gabber iOS mobile application codebase
/Gabber.PCL	Shared codebase between Android/iOS, i.e. RESTClient, Database, Localisation, and DI

Running locally

Open Gabber.sln with Visual Studio and install the package dependencies. To use a local version of the GabberAPI update BaseAddress in RESTClient to either use your local IP (as it runs on 0.0.0.0:5000) or create an ngrok tunnel to expose the API.

gabbermobile's Issues

Replace the About option in the menu with Settings

From the settings page, the user should be able to view and update their:

1. Profile information (name/email)
2. View more details on the project (essentially the current about screen)
3. Change the language of the mobile application
4. Logout (finally)

Choose preferred language of communication when registering

When sending emails to users or when they browse the website, we must be able to communicate with them in their native or preferred language, which will require

1. Retrieving a list of supported languages from the API, and displaying this to the user on the registration page
2. Send the selected choose to the API when creating a new user.

Blocked by #3

Change the project metadata when the language of the app changes

Gabber currently supports six languages, and chooses the language based on the preference of the users device, and there will be an option in the future to change language of the entire application from the settings menu (#3). All mobile content is stored in string resources, however, as content about a project is dynamic, it does not currently change depending on language set.

Changes to the API (#5) will ensure that data sent represents the project content in all languages configured by the project. Therefore, if the language is changed from English to Russian, then all projects with Russian content configured for the project would show it, otherwise the default project text will be shown.

Implementation Details

Data sent from GetProjects will be changed such that all written content (title, description, topics) will be contained in a content dictionary where each item has a key representing by a language code (en, ru, it) that can be used to lookup the relevant content. Knowing the supported language codes depends on API#2.

This is blocked by API#2 and #5 as the users preferred language may determine the language set.

Capture location during a conversation

This will filter conversations on the website and help visualise (potentially on the website in the future) the spread of conversations, etc.

In terms of where this is captured within the mobile application, ideally this would be captured when choosing the language (#8), with an auto-complete form that populates a location based on GPS that you can autocorrect (to postcode level) if something is wrong with GPS.

Move from Firebase Crash Reporting to Crashlytics

Crash Reporting will become inaccessible on September 8th 2018, which means we should move to Crashlytics, however, the Xamarin dev team are currently working on the Android bindings (see 428). The iOS are available NuGet, so we should move to those sooner to understand how these libraries have changed and how to configure Crashlytics appropriately.

Provide more context on the projects page

Currently, the first page a user sees when they open Gabber is a list of project titles as cards, which does not explain what the project is about or what they could discuss when recording a conversation for that project.

Instead, the interface should change to include (1) the project description, (2) the project topics, and (3) the project image. The title of the project and image would appear as a card (and list of cards) as it currently does in the application, however, if the card is clicked an expandable list/dropdown would show the description and discussion topics. This would also mean that a button should be added after the topics where the user can begin to prepare to record their conversation; by putting the button at the end, this forces all users to read the description and topics (or at least scroll past it).

Double tap on iOS uploads multiple of the same session

To reproduce:

1. Create a conversation
2. Do not click 'upload' in the summary dialog box that appears after recording a conversation.
3. Rapidly tap the conversation card. You will receive multiple notifications that this conversation has successfully uploaded.

Ask for language spoken during recorded conversation

As conversations could be recorded in any language, it is best to ask prior to the conversation to understand which language is spoken. This is required as despite the preferred language being in French and the devices language being in Arabic, the user may record their conversation in English.

Currently, the plan is to have a drop-down of supported languages either before the recording screen, or at the top of the recording screen (with a nice animation that shows the topics thereafter). This will also require sending a new attribute to the upload endpoint.

This data will then be used on the website to filter content based on the users preferred language.

(Blocked by Mobile#6)

Update user preferences

From the 'Settings' page (#3), the user should be able to update their account details and language preference, which will require making a PUT request to /auth/register/

This is linked with Web#3 and API#3

Capture demographics before registering or adding a participant

This would include:

• Which National Society are they a member of?
• Their role in the Red Cross Red Crescent
• Their Gender
• Their age

Logo Design Contribution

Hi,

I want to make a contribution to GabberMobile. As a designer for GabberMobile I can design a logo. And I can say it 's a good idea in my mind.

Do you want me to do that?

Simplify the consent process

Currently, to record a conversation the user must view five screens before viewing the screen where they can begin to record their conversation. While understanding what is being consented to is critical, this complex flow has retracted from what we inspire for in Gabber -- a lightweight way to record structured conversations.

That said, this process could be significantly simplified by reducing the text required and by merging both the research consent and conversation consent pages, and removes the summary page (given it would now be one screen). I suggest the follow changes:

1. The current Research Consent text could be removed and a link pointing to the research statement on website added alongside the check-box ("All participants understand...").
2. Reduce the three-paragraphs in "Conversation consent" to one or add a "view more..." option to dropdown to expand and show the other paragraphs if desired.
3. At the bottom of the "Conversation consent", have a short description for who has access, then list only the three option titles. Show the related description if a drop-down item is pressed, or have an "i" icon that when pressed shows a popup that contains the description (like when using OAuth).
4. Remove the summary as it's unnecessary with just a one-step consent process.
5. Remove the debrief as a popup or show a dismissible popup instead.

Note: Changes to this would also require changes to translated text.

At the same time, the following should be made clear (as suggested by Sara):

When in ‘Consent’ it is not clear that the administrator can also hear the conversation