SmartTrack has several audiences and purposes. It's visible goal to the user is a simple, location enabled visualization tool for equipment operators. 3D, plan sheets and cut-fill color planviews are all within a single tap of being visible. Also provided are indicators to the operator of his speeds and other metrics like cycle times as a way of measuring himself vs. himself and peers.

The secondary but less obvious users are the owners and managers of the construction company because while displaying the information the operator the program also collates and saves job performance information like tracks and subsequently cycle times.

SmartTrack's closest relative is SmartDirt with the newer 4.0 interface. It uses Plan, 3D, and sheet views but eliminates Measure and the camera.

• Minimize the need to configure. Especially by any one person. What we don't want is the need for some smart person to climb on machines to get the information or setup jobs, etc. Too many companies don't have that guy and he's way too busy anyway.
• Make the main path as smooth as possible. No visible login, use last file, startup in last known mode.

SmartTrack is designed for tablets running in landscape mode. It will most likely run on a phone but is not optimized for it. We will also accommodate portrait tablets.

SmartTrack will require a deferred uploader service, tracking, cycle line input. (This to be refined and amended)

The deferred upload service is an independent program that runs in the background when installed. It's initial purpose is to handle uploads regardless of whether the originating program is running. It will be a key to SmartTrack being able to upload tracks at any time the device is on. Features may include:

• A WiFi only setting that wait until the device has a wifi connection before uploading.
• It gives us a separate program to manipulate data when we need maximum memory. First example is rotating Samsung pictures based on EXIF data. They currently don't handle portrait correctly when uploaded as KMZ tracks.
• The ability to handle video at some point. The shear size of video means it isn't a viable option until we have the uploader.
• An Android AGTEK Access program. I'm not sure we'll have time to implement on the first release.

The action bar is for quick use of the most commonly used menu items. In SmartTrack the priority is

1. 3D/Plan - Toggles between 3D and cut/fill plan mode
2. Stop - This allows the user to designate stop points and label them. A stop comes off automatically after some consistent movement.
3. Cycle Line - Allows the user to tap in his cycle line. There's some thought that needs to go on here about conflicting cycle lines from management and the user.
4. Plan Sheets - This toggles plan sheets on/off. There's a bit of non-symmetry to this versus the 3D/Plan. I thought of putting this as a three-way toggle with 3D and cut/fill but the speed of switching between color and plans means it isn't practical. If we can do something about that then I may consider combining them.

1. File - for the more capable user to override the last file setting
2. View - for controlling the data shown on screen. This may be the time to modify our old view controller to be more like the layer control on SmartPlan.
3. Settings - This could end up being deeper than most android programs because there's a need to customize this product but we wish the opening screen to be very simple. Things like Cut/Fill display, the login, personalization to equipment, all go here.
4. Upload - this saves and uploads without our conventional dialog.
5. Exit - a dedicated exit method.

The left side of the screen has a pullout for the statistics measured by SmartTrack (try Google maps, or Evernote for a similar behaviour). The statistics shown are customizable by pressing and holding on the number cell. Pressing and holding on the numeric cell displays a list box of the available statistics. These settings are saved to be persistent. I'll put up a graphic of my expected interface as well as all the statistical measurements I can think of. The state of being visible or just a tab sticking out should be persistent.

Simply a measure of current speed based on GPS.

An option to show cut/fill. This is a preference. The danger of this is that the cut/fill number is based upon the two surfaces as they were taken off. Changes to the ground and autonomous location make this unlikely to be correct to much precision. If the machine being operated has MC, matching numbers is more of a chance than anything else. The default should be off for this feature.

Called out for consistency. The behavior is identical to all other smartsuite products and shows GPS status and allows panning when toggled off.

Using the progress line to show the filename (and mode when appropriate)when not in use for progress messages is the new 4.0 standard UI design

• Single Tap easy switching between planview, 3D view, Plan sheets
• View Control
• Northing/Easting, Station-Offset
• Highlight designated warning areas (Field anecdote: existing manhole covers, power lines). Highlight anything with a label called “Warning. Tap for any message”
• Continual Tracking
  • Limited trails (3 passes)
  • Cycle line entry - save with user track
  • Last Cycle time
  • Average Cycle time
  • Accumulated yards
  • Leaderboard? (shared, competitive measurement of project operators)
• Push Updates?
• Settings
  • Equipment ID and type
  • Yards per load
• OnScreen Speedometer
• Views
  • Shade Increment
  • Lines to view
• Push update from office? Update files work files remotely
• Read G-Ray, Internal GPS simultaneously for machines like excavators
• Google maps intent? For trucks, somehow passing information to Google Maps for traffic, route?
• Allowing user (foreman) to pass a recommended pass (advisory)?
• Use WIFI Direct (Bluetooth or the like) to allow Foreman to send info (haul paths, cycle lines, messages, files) or receive info (hauls, current numbers (this does not relieve the system upload capability) from SmartDirt expansion.

A user Stop feature that an operator can use to explain a delay.

Expansion to use tracking total stations with GPS position communication

Story 1 is about getting the interface on screen and functioning as well as the startup flow (minus the management generated pieces). At the end of Story 1 I want it to open the last file used and display it on screen relative to position. Not all of the menu items will work but they should be in place. I'd expect that 3D/Plan/Plansheets would work as well as rudimentary settings and exit. The Statistic view will display but just be place holder numbers. It will allow the user to choose what stats he wants although they aren't hooked up at this point.

SmartTrack is a departure from our normal Android flow. The primary user in this case is an operator who is usually not computer savvy and doesn't care much beyond getting his job done. Our goal is to provide information and encourage productivity with gamification (I be inventing a word to mean make it like a game). The minimum we hope the user does is turn it on and tap an icon. There's even a school of thought that we make the GPS data collection and upload a background service that starts when the tablet is turned on. We'll defer on that for now and assume that the operator will turn on the tablet and tap the icon.

Along the same them of of user interface simplification, in the end product we most likely will not have a login, key, or file interface in the main flow. They will still be possible to do each of them but it won't be in the main program flow unless absent. Here's examples:

We have to login to upload and to get a key. The difference will be that we attempt to login silently using stored authentication. For anything other than keys we also have to fail silently because often we will not be in range. My thought at this time is to have a Login tab in settings that displays the first time the program is used or if a key expires. We could also use the tab to give user feedback on connectivity success. The end goal is for the login to be neither seen nor heard unless absolutely necessary.

There's been no decision on how this is to be keyed. It could be a permanent device key or more likely a long term checkout (365 days). For early versions we can ask if the user wants to check in the key. In the final versions we will not ask if the user wants to check in the key. Instead it will be an option under authentication.

We will streamline from here. The login and keys will be one time events when the tablet is first loaded (prompted on first start and accessed via Setting menu from then on). The job file opened is the last one specified by the Management system (SmartDirt feature), or the last file loaded. The Management system choice does have the most priority but the user can override the file by choosing file from the menu.

Statistics tab A pull away side window displaying track statistics that is customizable by tapping any field. Tapping the field displays all possible statistics on a radio list.

Main screen - The main screen goal is simplicity in the view and hiding the program's depth.

Action Bar - Action bar items are:

• A toggle between 3D and planviews
• A stop button that allows the user to designate a stop, tag a reason (or speak?). This is a two state button. the current version where a user taps to begin a stop and a down version that shows it's engaged. Stop should immediately be engaged when the program is first started and disengage when movement is detected (work out a filter that detects real movement rather than just drift). Regardless of whether stop is engaged, we are still collecting data.
• Cycle Line entry - Cycle line entry is also a two state button. Pressing it the first time puts the program into the cycle entry mode. Pressing it a second time exits the mode.

Menu

This is where we actually track something and show the statistics. The primary part to this story is recording machine position with time stamps, keeping a variety of statistics on those positions (tracks) and displaying the tracks and those statistics. To generate some of the statistics we also need to be able to put in a cycle line.

Screen tracks are similar to Smartdirt visually but I don't think we want to show individual points. If we did need to show individual points I think they'd be a lot smaller. There's a little trial and error here on iterating to what looks good.

We don't plan on showing all the tracks onscreen at once although we should test how it behaves. Instead the default goal will be to show the last three cycles based on average time if a cycle line exists or the last 10 minutes if no cycle line exists. # of cycles shown should be under settings. (note to add it there).

Here's a quick pass at statistics after looking at Trackwork. There are some differences because Trackwork has an easy interface to clip off time at the start, ends, and middle of the track. The audience there is analyzing the track data. Our audience here is an operator. He most likely doesn't care to see warmup time on machine and is more likely to live in the now. Total time also can really screw up his numbers. We will collect all the data and report it, the difference will be on how and what we present to the operator.

• Moving hours(hours:minutes) - The amount of time the machine has been moving not the total time the GPS has been collecting data.
• Total hours (hours:minutes) - This is the amount of time the GPS is on and collecting data. The office does care that the machine is on and not moving but has a method of removing things like warmup from the
• Last Cycle (minutes:seconds) - The total time for the last completed cycle
• Avg Cycle (minutes:seconds) - The average time per cycle.
• Best Cycle (minutes:seconds) - The fastest time per cycle.
• Total Cycles - Starting value of 1. This is the number of times the machine crosses the haul line divided by two. A cycle line has to bisect the track twice ala' Trackwork
• Total CY - Total Cubic yards(meters) moved. Requires cycles and yards per machine specified to be non-zero.
• Avg Speed (##.#) - Uses moving hours for calculation, not total hours.
• Moving Minutes per Hour - This is the ratio moving time vs total time in an hour specified in minutes. I believe we need to support showing it but the problem is that the times spent warming up the machine can distort this although it's easy enough for the Trackwork user to cull the time range to give a corrected value.

The Statistics we show on a new install. The program remembers the last settings used after that.

Without Cycle Line

• Moving Hours
• Average Speed
• Moving Minutes per hour
• Total Cycles (this always starts at 1. It just never increases without a cycle line)
• Total Hours

With a Cycle Line includes all statistics of without a cycle line

• Moving Hours
• Last Cycle
• Avg. Cycle
• Best Cycle
• Total Cycles

The user is free to change these at any time and we will save the last settings they used regardless of cycle line presence.

Statistics are changed by tapping on the individual statistic cell. Tapping on the cell brings up a scrolling box. The current statistic is shown in blue text. Statistics already used show in Green. The colors do not preclude the items from being picked. (Note: The colored text is one way to show usage,current item. If this turns out to be difficult we can create other types of indicators.

Debate: In cases where the statistic depends upon a cycle line and one is not present, do we ask if they want to create a cycle line?

Cycle lines are the method in which cycles are counted. They are entered to cross the haul tracks twice. The main intended method of getting a cycle line to SmartTrack is from the management system. Failing that, the operator can enter one with the menu option. Typically cycle lines consist of 2 or 3 points but can be more. The usage goes like this:

1. The user taps the cycle line menu option. It displays as selected (needs graphic).
2. The user taps a single point and it displays. Another tap connects the two points with a line and updates the relevant statistics on the left. Pressing back removes the last point. Tapping the Cycle line menu option exits that mode.

We use the same editing as SmartDirt. Press and hold over the point to edit. Vibrate and place the box around that point that allows us to drag its position. Tap to end edit

You can have more than one cycle line and we use all to calculate the statistics. Adding is the same as entry described above and we do not replace the previous cycle line. A user can double his cycles by putting a cycle line across the tracks twice.

First thought is to press and hold on the line itself (not the points) and bring up an option to delete that line. Open to suggestions.

The statistics derived from the cycle line are based upon what we currently do in Trackwork. We need to look at the Trackwork code and implement our in a way that matches Trackwork. Please bring to our attention anything you see when looking at the at the code that doesn't look right so we can reexamine the method but the end goal is for consistency between the two programs.

Cycle Line precedence is also a question. In some cases the user will enter multiple cycle lines and if he crosses the same track with multiple cycle lines he will have erroneous statistics although the track data is fine. The more complicated case is when the management user puts in a cycle line and the user puts one in. In that case we should not use both but instead use the management cycle line. Unfortunately although I think this is a good general rule, it will probably require more thought. (Should we allow the operator to delete the Management line and use his own? It actually only hurts summary statistics and we could flag it to the mgmt user?)

Saving locally, automatically and often.

This story is about tying in with the Access Server both for key flow & tracks along with the ability to have data and settings pushed from other devices. We may doing something simple in an unreleased Java client to test this aspect of the server until SmartDirt and/or the desktop software can be extended.

Settings in SmartTrack are very different than the other Android programs. The chief reason for this is that we wish to submerge more interface like logins, keys, and even the File selection further below the main screen interface. I don't want operators accidentally choosing the file interface off the menu for example. The intention is to push this information from a management interface but not to completely preclude a smart operator like Donnie Lebon from having complete control.

I've reworked the File dialog to be better suited to tablets and landscape orientations. My best guess right now is it should be the default first screen when Settings is chosen from the menu. Key features are a more email like organization. In either local files or Access the tree list is expanded to show projects on the left and the corresponding files on the right. If I tap the Access line it collapses the Local project structure and expands the Access one. Also note that we still have menu three dots for this tab only. This is a big change obviously from our current file implementation.

Mostly like what we have now although we have no way of doing put me here (no pick). I don't know if it's required and have eliminated it for now. We might leave in the capability in Dev mode and turn on pick in those situations.

Preferences uses a similar method as file with the email like left hand side. The advantage is that we can scale this pretty easily as necessary and drop some little used functionality down even one more level. Some of this stuff may be automatically populated by the server or only chosen once (login). We need it accessible but don't really want operators messing with it by accident.

The first screen is screen controls They are:

• Show cut/fill number on screen - this controls the visibility of the cut/fill numbers. The default is off
• Track Cycles displayed - A full day of tracks makes it both hard to see and could present a problem drawing all of those tracks. By default we only show the last 3 cycles or the last 20 minutes (WAG) if no cycle line is entered. (It does make me wonder if I need a time control as well on the same line.)
• Display units - Although we know the units of the file we have measurements like mph that we display. Even if the job is in metric in the US, it's likely the operator is going to want mph instead of km/h

The second screen is the machine description. The controls are:

• Name - this is the friendly name of the machine.
• Type - Construction vehicles have different tracking characteristics both in measurement and track behaviour. Types I can think of right now are Compactor, Scraper, Excavator, Truck, Blade, Dozer, Paver. Having a type helps with setting up the proper analysis and in segregating volumes by vehicle type.
• Color - One of the previous issues was the lack of standardization of machine colors. It caused two problems. The first is that it was difficult to analyze more than a single day because the same machine may show as a different color. The second is that it makes it harder to quickly recognize patterns. This is the first step for standardization
• Average CY (M3) per cycle - a default number for approximating the volume of dirt moved per cycle
• Select from List - Queries the track server and displays a list of previously entered equipment. Simply and easy way to populate this tab.
• Scan Machine - Use bar code scanning to identify the machine from the server and populate this tab. I could easily see us having an option when the program is started to go automatically to a bar code scanning function. Not necessarily something we need in V 1.0.

The login screen has a single button, Deauthorize. What it does is prompt the user “Are you sure you wish to Deauthorize this device and exit the program?” Pressing yes attempts to checkin the key and upon success clears the user's login data including token. Upon success of both of those operations, the program exits. In cases where the key is not successfully checked in, display the following message and return to the same screen up on pressing Ok. “The device is unable to check in the key. Please verify you have internet connectivity and try again.”

After this done, any subsequent attempt to start SmartTrack will present the user with the standard login dialog identical to the first time it was set up. In the event the authentication token is invalid, the user deleted, or the password changed, the program should display the login dialog to give the user and opportunity to fix the problem.

The standard Key/Access Login. Hopefully this is setup as a longterm/onetime key and the only time a user would see it is on the very first time the program is opened or is the user/password is changed for some reason. Suppressing any login view that is not absolutely necessary on this program is desirable.

About is our standard about screen with whatever device ID we choose to use on the server in case of a mystery that needs solving.

One of the themes of this system besides low friction to implement is giving each of the users something and getting some simple sort of data in return. It's not unlike a database where the collective small inputs of many people yield a result that is greater than the input required. The users/consumers are:

• Operators - Get information and incentivizing statistics while providing tracks automatically with little additional effort on their part.
• Superintendents/Foreman - Designate the correct job for Operators, enter cycle lines, and potentially provide haul paths. In return they get hourly and daily statistics on job progress and machine performance.
• Management - Gets performance and job progress statistics
• Estimating - Provides takeoff files and analyzes progress. Gets real world insight into costs and potential progress payment documentation.

The above users and their data requirements creates a map of where data goes and what it flows from. The program/program elements are these:

• SmartTrack
  • Deferred uploader
• SmartDirt
• Earthwork 4D
• Trackwork
• Web? (eventually)

• Tracks (Lat, Long, Time, elevation?, compass reading, stops (time range, label)
• Cycle lines (coordinates (NE or LL?)
• Hourly statistics - Moving hours, total hours, avg cycle time, cycles, cy(m3)
• Cumulative statistics - Moving hours, total hours, avg cycle time, cycles, cy(m3)
• Device name, machine name/id, machine type, color,default capacity

• Job File to use
• Cycle line(s)
• Machine name, capacity
• Suggested haul route
• Warning Areas (encircled areas with a label of “Warning - *”)

SmartTrack itself does none of the actual uploading but instead passes that data to the deferred uploader service that runs at all times on the tablet.

This is derived from the SmartPlan Layer list. I may move it up to another story but it isn't a priority at this time. Eventually all of the SmartSuite products will get this interface for View. The main advantage of this style control is the user can see the effect of turning layers off and on for better feedback.

I believe the old Trackers supplied just Lat/Long/Time with a device ID and that's what is stored in the Track Server. We need to extend this based on some new capabilities of our devices. Some new information includes:

• Compass direction - This can't be mandatory but devices with a compass will add much more value to machinery like dozers that cut and back during operation.
• Cycle Lines used - While the end management user can overwrite or add a new cycle line, we'd like to capture cycle lines used.
• Statistical summaries of tracks. We store a track as a summary reference to the thousands of points that make up the day's work. By saving the cycle line used and the resulting statistics at an hourly granularity, the mobile user can get a reasonable snapshot of the day's activity. We may even be able to present some of this as a web page as well.
  • Moving Hours - hourly and total
  • Total Time
  • Work Minutes - hourly and daily total
  • Total Cycles - hourly and daily total
  • CY/M3 - Based on the default machine values - modifiable in reporting to account for conditions - hourly and total
  • Avg. Cycle time - hourly and total

SmartTrack is a single piece of a system to to provide operator information and measure jobsite performance. The pieces I can think of now are these:

• SmartTrack
• Deferred Uploader Service
• Movement/Activity Service
• Access Server
• Trackwork

• Viewing totals for job (simple Trackwork viewing)
• Pushing data to operator units
  • Suggested haul paths - Allow tapping in path or using a driven track to be pushed.
  • Cycle lines - Management cycle lines override operator entered cycle lines although I'd like to preserve both in the server.
  • warning areas
  • New file version