Need to tweak width and height to match the pointer icon.

Per UI/UX spec, the bottom bar with settings button, day/night button and end button should autohide during navigation and then appear when the user touches the screen.

The license agreement is a hosted PDF file that launches in a browser on Android 5.0 and above and on iOS. On Android 4.4.2 and below, the file is downloaded, but default apps on the device can not open it.
The short url of
http://esriurl.com/labseula
points to
http://www.esri.com/~/media/Files/Pdfs/legal/pdfs/mla_e204_e300/english

The app includes code that logs trek information [timestamp, pos_lat, pos_long, pos_dir, klat, klong, az_to, dist_to, degrees_off] for analysis post travel.
This information should be saved to a sqlite file that a user can copy of the device for their own use.

For version 1.0 a user can be directed to manually change logging setting to 'true'.

Future improvements include:

• UI on settings page to turn on/off logging and to clear the database
• ability to send data from device via email

Related to #19, In the settings tab radio button choices are show with check boxes.

Radio button should look like radio buttons.

It counterintuitive to use opposite appearances for check boxes and radio buttons when compared to most apps.

'End' does not look like a button and is not intuitive.

The UI needs to be considerate of the target audience of field workers that work with gloves and are familiar with applications that have buttons that look like buttons.

Buttons must look like buttons.
Buttons such as this should be large enough to press press with gloves on.

@marikavertzonis

For example, requesting not to see the warning screen doesn't set the correct flag in Android. Works in iOS.

Round checkbox style is confusing as that appearance is normally associated with radio buttons.

e.g. A user coming from Survey123 would see the radio button and think its multiple choice.

Check boxes should look like check boxes.

This is evident as the 'End' button isn't visible which means the startNavigation() method hasn't been called.

This related to #35 as well I think.

• features complete
• Testing complete
• apps submitted to stores
• [x ] app released in apple app store
• app released in google play store
• make app available as sample in AppStudio
• move repo to public facing github/Esri
• add to labs.esri.com
• make marketplace listing available
• geonet blog released

Currently view doesn't scroll and so settings get cut off of certain devices.

Navigation appears to not start after the app is called from another application. Though the end button appears and coordinates show up in Settings view.

Upon retuning back from settings view, navigation (the arrow starts turning) appears to start.

From: Scott Sandusky [email protected]
Date: Saturday, 1 October 2016 at 9:07 AM
To: Elvin Slavik [email protected], Jayson Ward [email protected], Marika Vertzonis [email protected]
Subject: Trek2There - final disclaimer text

Hi Team,
Here’s the final disclaimer text for us to use. Thanks!

Do not attempt to use this directional information unless you are at a complete stop. Travel safely and use common sense when using Trek2There. Trek2There is not to be used for terrain avoidance as direction and distance information does not consider traveling around physical barriers such as cliffs, water bodies, roadways, moving vehicles, buildings, etc. Do not follow any travel suggestions that appear to be hazardous, unsafe, or illegal. Trek2There is provided on an “As-Is” basis. You assume all risk of using the Trek2There app. Please refer to the license agreement for further details.

When there are no coordinates entered on settings and user returns to Navigation View direction arrow and distance indicators should be hidden and replaced with a message.

Day night mode, and subsequently the icons that represent it (sun and moon) are an gross simplicifcation of the tools needs. It really is a contrast switch. It dosnt need to be night time to need the 'night' setting. See #22 (comment) for more discussion.

The main point of this issue is to review the icon of the Sun. It looks like the Settings tool. Whilst coming up with an alternative icon, consider it as a contrast switch and not day versus night.

Replace settings icon and move End button to bottom right.

Predictive filtering algorithms should be used to improve navigation and arrival mathematics. Consider Kalman filtering to improve arrival https://en.wikipedia.org/wiki/Kalman_filter

In Sep 26 usability testing, I found user keep following the arrow even if it is grayed out.

Need a new graphic to represent this state. For example, a question mark icon.

Add save button to top right that user would press to 'accept' changes to lat / long values.

If not pressed, then changes to lat / long are not saved on back button click and return to Navigation View.

Color:
R: 51
G: 128
B: 51

Sizing:
Needs to be slightly smaller.

Particularly when stopping or starting, the direction arrow does bounce around.
Moving at a steady pace seems to help the arrow rotate smoothly.

More effort is required to improve the arrow behavior, including

• Arrival maths - #3
• Location accuracy indicator could help communicate why the arrow might be bouncing around - #16

Is using the default, should be com.esri.trek2there

Testing with Cedar Tree 4 device (Android 4.2.2) and the display flips from portrait to landscape too easily. Did NOT happen on other test devices (various iOS and Android) - @IsmaelInRedlands in #13 you describe this happening - what device model and operating system combo was this on?

When arrow is grayed out, it should be replaced with another graphic so user doesn't follow it.

Test devices that did this:

• Cedar tree 4, Android 4.4.2
• iPad 2, iOS 10.0.1

When I launch Trek2There from another app (in this case Survey123) on these devices i don't see the distance or arrow start to move for minutes. Tapping the settings button and then the back button straight away without changing the coordinates, APPEARS to speed up seeing the distance... but it just might be the time that has lapse is the same as if i had waited.

http://x-callback-url.com/ describes an existing standard used by many other apps we should follow.
[scheme]://[host]/[action]?[x-callback parameters]&[action parameters]
This specification accommodates a number of scenarios, including being able to send back success or failure results.

We also have similar (but not quite the same) app links in use by Survey123, Collector and Navigator. As Trek2There is designed to be a companion app to the other Esri apps, its app link scheme should match that of the other Esri apps. The Trekl2there app scheme is described here:

https://github.com/ArcGIS/Trek2There/wiki/App-links-in-Trek2There

Right now, an app link successfully launches Trek2There with the destination location, but upon arrival, there is no callback. This part is still to be competed.

Move day / night toggle option to settings view.

On Windows (tested with 1.0.172) the callback function launches a new instance of the referring app, rather than bringing focus to the already open app.
In my example i used Survey123 to launch Trek2There. When i click end, a new instance of Survey123 is launched.

Also if you are in Survey123 and Trek2There is already open, if you click an app link, a new instance of Trek2There is launched. This was tested as a part of #39. On iOS and Android having Trek2There already opened is a workaround for navigation not starting straight away. That workaround doesn't work on Windows.

Strong user feedback for a bearing label on the direction arrow has been received. This is to allow for Trek2There to be used in compliment to conventional physical compass use in the field for navigation.

The workflow would be the user identifies a location to navigate too, Trek2There provides the distance and bearing values. The user puts the electronic device safely back in their bag (this preserves battery life while also keeping the device safe while tramping through thick bush), and uses a physical compass to navigate to the bearing. Trek2There would be pulled out intermittently to check the distance and bearing values.

Remove small arrow, but leave outer circle.

Entering long and lat values require a minus sign, and on some Android devices the default keyboard doesn't have one.
Some model Samsung and LG keyboards suffer from this, but we've seen defaults on Sony, Cedar Tree, Nexus, some Samsung with the minus sign.

Downloading a Google keyboard fixes the issue.

However, if this does pose an an ongoing issue, should consider adding a custom keyboard to the app.

User feedback has strongly indicated the need to launch Trek2There directly from Collector when the user selects an existing Collector point or location. This would then pass the coordinate values from Collector to Trek2There and allow for navigation to the point. When the user arrives at the point the Collector app re-opens.

Just a handful of comments on 1.0.58 since I will not be able to attend today's review meeting:

• After I set the target location, I see a yellow dialog telling me 'Travel direction not recognized'. I think this dialog should not tell me about a problem, but about a solution. For example, if the problem is that my device is not being held horizontally: tell me I need to hold device horizontally. If azimuth cannot be calculated because I am not moving, tell me I need to move etc.
• I was expecting the arrow to point to the direction of the target even if in stationary mode. Kind of like the compass in my phone is able to tell my azimuth even if am not moving.
• In general, it seems to me like the arrow is showing erratic direction as I move. Testing around Esri Campus.
• There is a tiny blue arrow on top of the circle which never moves. I am not sure what is the meaning of this arrow. In the BeeLine app they use a couple of small circles to provide fixed points in the UX. It seems more appropriate to me. I suggest we only have ONE arrow in this app.
• Qt Sensor includes capability to tell the tilt of the device. I think this could be useful (when available). For example, if I have my phone vertically, then it will be hard for us to get the user's Azimuth. The app should probably tell me that I need to hold it somewhat horizontally for the arrow to be accurate.
• The moon icon is cool. The sun icon is way too similar to settings,

I tested the app today to get to a customer's office. Some quick comments:

• First of all, the app got me where I wanted to go. So overall, it did its job. The comments below are just enhancements.
• I tested it twice:
  • From my hotel to the customer's office. Distance 1300m
  • From customer's office to the Esri Portland Office 600m
• Remember Distance Units: It would be nice if the app would remember my distance unit choices. I like to work in metric system, but it will always reset itself to imperial everytime I start the app.
• Landscape/Portrait mode switching: When you use this app, I typically hold the device flat in my hand like I were using a compass. In this flat position, the app was jumping between landscape and portrait mode as I walked. It was annoying. It seems to me like supporting only portrait in a mobile phone would be reasonable. If using a tablet we may want to go landscape only.
• Start moving!: The Travel Direction not recognized dialog is meaningless. I would suggest we change it to Start Moving.
• I found the arrow jumping in different directions while I walked. Once can tell that the arrow is not correct for small periods of time. It seems to be related to how this app is calculating my direction based on my path. It would seem to me like the device may be sending locations that are off by a few meters, substantially changing the direction of travel.
• I do not understand the purpose of the new option to show or hide the outer arrow. Well, I know what it does (shows and hides the outer arrow and the circle), but I just do not know why I would want to turn it on and off. I am playing dumb here because I think the question from a user would be fair. It is not obvious what the meaning of that would be.
• Really liked the callback function functionality.

Please use the iOS app icon in the box folder instead of the transparent one. This icon will look good on both Android and iOS devices.

There is a need to set destination not only in Decimal degrees (Latitude/Longitude) but also in Meters.

A critical contributing factor to arrival detection and some of the observations in #13 is the horizontalAccuracy being reported by the location sensor.

The horizontal accuracy should somehow be displayed to the user.

This could either as an absolute value as reported by the sensor -

e.g. For the distance to destination 123 m ± 10 m

or a graphical representation such as signal strength

e.g.

The highest bar would be a location <= 10 m
The lowest bar would be > 100m

On some Android devices position.directionValid must return true so the statusMessage isn't shown when navigation first starts in order to inform the user to move. This isn't an issue on iOS.

See comment in NavigationView code > https://github.com/Esri/Trek2There/blob/master/NavigationView.qml#L496

Add a standard about dialog/page

Qt Sensor includes capability to tell the tilt of the device. I think this could be useful (when available). For example, if I have my phone vertically, then it will be hard for us to get the user's Azimuth. The app should probably tell me that I need to hold it somewhat horizontally for the arrow to be accurate.

The Trek2There item in labs.esri.com should link to: https://marketplace.arcgis.com/listing.html?id=a1a3caec68694eaf8b6e0c25f0657275 Currently it is pointing to snap2data.

Metrics are not being sent by Android devices.

As I understand right now, the app is collecting metrics using hockey. Once we get close to final we need to decide if we still need to collect metrics of usage/crash via hockey or some other service. If yes then:

1. It should be stated as such in the About page. Need to be explicit about what is being collected and what is the intention (i.e. are you tracking me vs. we are using it to understand app usage)
2. An option to opt-out should be provided in the settings page
3. Needs to be run by Legal

cc: @ScottSand @IsmaelInRedlands @defiantgoat

Set the position source environment variables to use navigation mode if available on the device.

This should improve some of the behaviour observed in #13

Please add the following text at the end of "Disclaimer" text and "About" page as requested by @nitinsbajaj

Trek2There is an Esri Labs project and not an official Esri product. Trek2There is provided on an as-is-basis and you assume all risks associated with using this app. Please refer to the license agreement for further details.

Ensure that they are numerical values.

I created a simple app to easily create Trek2There custom URL Schemes from a web browser. Something like this would be useful for people to quickly get started with the app.

https://arcgis.github.io/Trek2There/Trek2ThereWebLauncher.html

Scott: May be something like this would be useful for the blog post:
1- Install the app
2- Open this URL, point to your destination and launch Trek2There by simply clicking on the map

I can add very quickly some basic functionality to search for an address

@ScottSand

Implemented.
Thanks to @juliepowell for the fix!

Sometimes when the application is open and night mode has been saved as a preference in the settings, day mode will still be in effect on the SettingsView and when day mode is then checked on the NavigationView, night mode is visible on the SettingsView.