-
Notifications
You must be signed in to change notification settings - Fork 157
Mobile App
menewman edited this page Aug 10, 2014
·
15 revisions
NOTE: Some of this is out of date due to other decisions made 9/10 Aug 2014. Someone who knows the project as a whole well needs to review it @shoobe01
- Create app icons and splash screens
- Create home landing page layout
- Volunteer button
- Upcoming list
- History list
- Add collapsed appbar With login/logout button
- Create checkin page layout
- Create nearby list (may not be possible with current data)
- Create all disasters list
- Create disaster checkin detail page
- I’m here/I’m leaving button
- Planned start
- End
- Date picker
- Hook up app bars
- Data model
- Connect to azure service to get data for upcoming and history
- Connect to azure service to get all disasters/nearby disasters
- Login/Register
- Create login page and settings: If not logged in, show login page
- create register page (consider webview/oauth)
- create settings/logout page
- Consider create a mobile service for easier integration with crisis checkin data
- Fire toast/live tile changes when there are new crises
This should all be documented in code, but it may be needed by others.
- Currently, the Android app has an intent filter that lets it pick up the following custom URI: "crisischeckin://CrisisCheckinMobile.Android". It should be possible to send additional information through the query string (e.g., "crisischeckin://CrisisCheckinMobile.Android?disaster=13" to send a disaster ID of 13), but support for using this data will need to be added to the activity in MainActivity.cs. (Some code for this has been stubbed out already in
OnNewIntent().) For more information about this in general, see the links on this page under the "Custom URI Schemes" section. - It's probably worth looking into picking a better scheme/host/query name than the one specified above, because 1) it would be nice if the URI were short and easy to type (e.g., in SMS), 2) it's probably best not to use the word "disaster" in something that's end-user visible, and 3) it would be nice if the URI also matched the website (given that the scheme is replaced with http). None of those changes should be very difficult, however--configure this in the attributes of MainActivity.cs in the Android project.
- The ISaveAndLoad interface in our PCL is implemented by SaveAndLoad_Droid, SaveAndLoad_iOS, and SaveAndLoad_WinPhone. The Android/iOS versions should work, but the Windows Phone version has yet to actually be implemented. Details for how to do this can be found at this guide for reading files in Xamarin.Forms. This will be necessary for serializing anything (e.g., settings) to local storage.
- (@menewman 10 Aug 2014)
Things that are future, ideas, out of scope for now, etc. Slot these in later, or something.
- NOT sure how the UI would work, so ideas below are just strawmen.
- When the user has made a change, do something minor like a toast when it is saved successfully maybe.
- When not saved, inform them. Not a lot. Not a giant dialog, but something. An icon in the corner spinning and spinning and spinning. Or a bar that slides up and says saving, then eventually: Could not save.
- Any need for manually re-synching? Might be good to be able to tell the app to stop, and to restart, when coverage is back.
- TRY to make the data trials very efficient. Don't waste power.
- (@shoobe01 10 Aug 2014)
- It is expected (the Aug 2014 client plan) that Coordinators will invite volunteers to the specific Disaster by linked email or SMS. This will be an encoded URL which will launch the mobile application and (via a custom URI) link directly to the Disaster page.
- Make the code sent include not just raw keyvalues for the Disaster but another value for the Coordinator (and suitably encoded also I assume). Log the opened state with a Disaster Committment, including the keyvalue used whe custom URIs are the method that opened the Disaster page.
- Later, when gathered data is analyzed, volunteers can be associated with Coordinators. A tree of individuals can be built with no additional manual entry.
- (@shoobe01 10 Aug 2014)
- Whenever LBS is used to record the users' location automatically, it will pass high-precision coordinates (probably lat/long). However, accuracy of GNSS (GPS, GLONASS, etc.) varies widely, and coarse location (cell, sector, multilateration) is quite likely to be used for many locations, and could be off by several miles.
- Note that this is available. In Android, it is available by getAccuracy()
- DO carefully note what this means, and interpret the data for the consumer of the information. For Android, the getAccuracy value is CEP R68 in meters. There is a 68% chance the target is within the circle, whose radius is measured in meters. This is not obvious, at all.
- (@shoobe01 10 Aug 2014)
- Decimal Lat/Long is automatically created by many systems and is able to be imported into common tools like Google Maps. However, it is not very commonly used by any actual human end users or legacy systems.
- Many many others must be offered to allow it to work with local authorities, legacy digital GIS systems and legacy paper maps.
- There are (IIRC) 60-100 coordinate systems you'll have to support. I might also be good to support datum (many of those also).
- (@shoobe01 10 Aug 2014)
- There are 700 million users of email. There are 5 BILLION SMS users. And, trending that way. Even in the US, numerous "digital natives" only use email when required to, so may not check regularly, or even forget their authentication credentials so require reset.
- In austere environments, SMS is vastly more reliable and lower power than data, so SMS based contact can be used more effectively.
- SO: SMS should be supported (alongside email) as an identifying credential. The username can be a phone number or email address, and only one is required, but both may be entered at profile creation.
- (@shoobe01 10 Aug 2014)
- The mobile app is being designed (and maybe built if we got to it, but unlikely) with a single name field.
- This should be propogated into the datastore and all other front ends.
- There is no value in two fields, as the data is not validated or otherwise used.
- What with titles (doctors, esp.), complex names to differentiate individuals (middle names, generational titles), regional or cultural variations (labels for fields, which name to display first), this avoids all issues. Users enter the name they wish to be known and addressed as, in their conventional order.
- (@shoobe01 10 Aug 2014)
Since this is likely to be used in environments with poor and intermittent mobile coverage, data may not be available. Other methods to get updates might be useful. All these only really matter once the app gets to the point it does things like hands out work assignments. Still good to plan on it.
- SMS response: Sign up for a spot in like at the DMV here (yes, real place. You'll make someone mad if you do this, but no one we know). Play with the responses available. This might be a useful backup, by providing this integral to the SMS notifications. If the app is not updating, the user can respond to get more or different info, accept the work, change their status, etc.
- Load data via SMS: Yes, SMS is still 160 characters long, but clever encoding schemes and multipart messages could allow updating small bits of the database, slowly, over a series of SMS messages. Attaching the data to a link would allow the app to absorb it via the custom URI scheme. The end result would be easier to read than a series of text messages, and would be saved to the app so it could be dealt with as usual.
- Danger: MMS (attaching images and other files to a text message) will turn the /entire message/ into a data-delivered message. Nothing goes over the SMS channel. So, don't do that.
- (@shoobe01 10 Aug 2014)
This is stuff we should do, but really are not going to get to this weekend
- Do not mask password fields. Ever. Certainly not on account creation. Also not on signon. Really.
- Okay, if you must, have a toggle to allow hiding the password, if say someone plugs in their phone to demo it. There is no other reason in the real world, many cases of big, lawyer-laden companies using this. DO default to visible.
- For end users with the mobile app, I'd not encourage use of a password so much. People will sign on every few years when they get a new phone and will certainly have forgotten (also, website will generally auto signon with browser remembering). Instead, just have them use their identifier (phone or email) and work every signon like a recovery. Send them a code, they use that to get in.
- Yes! Use Custom URI to link this to the right place in the app without typing, and for some SMS clients it'll automatically launch the app even!
- (@shoobe01 10 Aug 2014)
This is done near the end of day 2, so things may be missing, or mis-remembered. These are decisions to not do stuff, or not do stuff now.
- Location services. Originally thought it was in scope for logging location when user arrives, etc. but clearly not enough time to do it.
- Assigning of actual tasks. Designed a flow which would switch the Disaster page to a more detailed status page for end users. The thought was to send details about the task (what to do, location, etc.) and the user would accept or reject it, to emulate the taking of the piece of paper and confirm it was received.
- Find disasters by location. No such data available. But a map on the first screen would look nice and inviting for those users, and demo well to the press.
- Contact Coordinator. To solve issues, report problems etc. Probably just not needed as collated reporting is good enough.
- Travel information. No real need to gather info that the volunteer is traveling, where they are before they get to the site, etc.
- Send app to others. Decope, cannot recall why.
- My Disasters. A dashboard (not a complex one, just a list). First descoped because most people work one, then merged with the Disaster List page as a minor status on each one allows users to see if they have committed to others in the future.
- (@shoobe01 10 Aug 2014)