localdata / localdata-mobile-web Goto Github PK

In the vanguard survey, some of the conditional questions aren't getting cleared.

Will test locally and attempt to reproduce + fix.

The app now loads, as do completed parcels in the viewport, but parcel outlines do not load.

Occasionally, the "Get started" box (#home-container) will reappear, unstyled. It looks like something is causing the app to reissue the api.getSurveyFromSlug call when that happens. So potentially, the app cache manager is reinitializing, which then causes us to show the home container.

We can measure the height of the window, and if it's above a certain size, let's make the map bigger. We need to make sure that doesn't negatively effect retina iPhones, though.

If a user has uploaded an image in response to a survey question they cannot currently delete or cancel the image before submitting the survey.

I set up a barebones test to see how many shapes it takes to slow down Leaflet on mobile browsers. Tap the "add features" text to add 100 features.

Test device: Samsung Admire; 800mhz processor, 512mb ram, Android 2.3, MetroWeb Browser (basically a rebranded standard Android Webkit-based Browser)

Around 800 objects, responsiveness starts to slow. At this point, the map also becomes unresponsive for longer periods as shapes are being drawn.

At1000, there's a significant degradation in interaction. The map takes way longer to respond to gestures. Zooming is difficult and no feedback is given for delay.

We should aim for a maximum of 600 objects on the screen. We'll have to find a better way to give teams field overviews (eg tiles that expire and regenerate regularly).

That way it doesn't push to the second line if we also have the add a point button.

"Creating parallel sets of responses for each parcel is confusing and could really mess up data."

Options for dealing with parcels that already have :

• Edit the data (PUT)
• Replace the data (DELETE and POST?)

Some groups will want to update the data -- aka keep the old results, and add new results. This way they can get comparative data over time. We haven't yet built out the interface to support this, and aren't likely to in the short term. My vote is to default to replacing the data (technically the easiest), and then do edit, and then do multiple entries.

In the future, we could add an option to the survey: "only allow one entry per parcel"

Users who accidentally hit Enter while in a free text field may prematurely/inadvertently submit all the survey responses. Require the user to manually click the "Submit answers" button.

Free text responses and images are currently at the bottom of the survey. These should appear in the order entered to reflect the logical flow of the survey, since sometimes a free text question is a follow-up to another questions.

Per LocalData/localdata-api#58

Try Hammertime.

We need a hard offline mode. The user will indicate that they have connectivity before going into the field, and the app will cache data for rendering the map and parcels. The app will store entries locally, as with soft offline mode. When the user has connectivity again, they will indicate that, and the app will post the entries to the API.

We should evaluate PouchDB, which seems to have much more activity these days than Lawnchair, and which already has node-style error handling.

• Can we easily store different sets of data (multiple collections/tables)?
• Does it increase our minified code size by much?
• Can we support all of our platforms?

Alert the survey user.

Scroll to the offending question.

See Vanguard-Parcel-Survey -> Structure -> Appears VOD for an example. Sub-question "Vacant property details:" will not hide.

To reproduce: push a new build. Refresh the app on mobile. The app will load, and you can get started. Shortly after, the whole page will refresh and take you back to the login screen.

Happens on iOS and Android. Is this an appcache issue?

Subsequent loads from cache are fine.

We're seeing file uploads that look like this:

http://locald.s3.amazonaws.com/upload-beta/c7155230-5b88-11e3-a27d-efc86addc8cf/2013-12-2-2608-w-63rd-st.Blobc1e6effe2c18453b92a5ae6e6a307357

It looks like the blob is being attached to the filename for some reason. Not sure if the server or the mobile client is the culprit. Only seen on one Android so far.

Make sure it uses the numerical keypad

Per LocalData/localdata-api#58

Seems to be browser/OS-specific. This did not work on Windows & IE—you had to click on a portion of the parcel not beneath the blue circle representing the approximate location to select it. We did not do more detailed browser compatibility testing.

On 3g, I get a "load timeout for modules: main" error when loading mobile. Native Browser, Android 2.3.4

I think it's the .scrollto()

The survey manager would like to be able to go out and see results for a parcel. The ability to make corrections would be nice, but an additional record could be added.

Does this need to be available only to managers, or to all users? Former would make data privacy easier (the manager can be expected to enter a password)

There are a number of ways we can implement this depending on the type of date.

A year might be best entered using only the numerical keypad.

We can also do free text / semi-structured for longer dates. Type-ahead would quickly narrow down months while keeping the touch targets large and context switching to a miminum

If the network is slow when we request the completed responses, we can see some flickering on screen. Under the hood, we're kicking some entries out of the completedParcelIds object and bringing in replacements for those entries. If the connection is slow, we'll render the green styles in between those steps.

If we're a little more sophisticated about tracking the completed parcels, then we can probably avoid this.

Also, so much overloading.

If you submit a result for a parcel using IE on Windows RT (or whatever it's called nowadays), the parcel doesn't change color. The result is recorded and shows up on other browsers.

I've gotten reports that on some iPhones, the "Loading..." message doesn't disappear. Users are able to enter their name and hit "Get started", but at that point the loading message appears and doesn't go away. Looks like this might be a bug (race condition?) with the surveyPromise (starting around line 50 in app.js)

Start using the generic base features API by default, instead of the parcels API. We need to tweak to refer to the "short name" or "long name" instead of the address. Similar for the ID.

Ideally we should stop referring to the base objects as "parcels" in the code, but that's not urgent.

The base layer sometimes has problems. For example, a property may have the wrong street name in the parcel layer. Surveyors should be able to flag those.

Aka it should get focus by default. Can we do this with JS?

We should warn loudly or require confirmation if we try to deploy code that has uncommitted changes (i.e., the version string will have _custom at the end).

But don't accidentally use the street map when there is a satellite image available.

Looks like there have been some updates / fixes to Lawnchair since our last update.

The tablet is hard to use in the sun on bright days. Can we change the design or add a cover to make it more readable?

http://leafletjs.com/reference.html#tilelayer-reusetiles

Because answers aren't cleared, survey responses my be accidentally assigned to the wrong property if the user accidentally clicks on the map.

If two or more radio buttons have selected: true, they will both render as selected, even though that's not how radio buttons work.