User Dashboard: Remove Labels Per Street Table

[jonfroehlich]

The 'Labels per Street' table seems unimportant and not useful in the user dashboard. I think we should remove it. Note: user dashboard here is not an admin interface, it is available for all registered users to track some basic stats about their auditing behavior. See below.

@Soben713 @manaswis. Thoughts?

[misaugstad]

I agree, it does not really feel useful. One user suggest replacing labels per street with labels per mission. Still not sure that it would be all that useful, but I definitely prefer it to per street.

Also possibly a column for total and/or labels per mile? Who wants to do addition or division in their head? :)

[chishankar]

Has there been any final decisions on this? Or should I play around with it and see what looks/feels better?

[jonfroehlich]

I think switching it out to labels per mission would be better. It's a low priority.

Also, the daily contributions line graph (also viewable in the screenshot above), visualizes 'audits'--however, the end user has no notion of what this means. An 'audit' is completely opaque to them and is used in the backend for our own data structures and tracking. So, this should likely be missions (even though @manaswis pushes back every time I want to use missions as a metric, it is the metric that end users are most familiar with and it is the most user friendly imo).

[misaugstad]

In the code's current state, it is not immediately obvious which labels go with which missions. We can make inferences, but we can't say with certainty. There are a bunch of issues like this that will be easier once we change how missions are defined in the database (issue #1130)

[jonfroehlich]

Yah, we need to wait on this one until after we're done re-architecting the backend.

[jonfroehlich]

And there is a larger question, in general, about how to best design this user dashboard, what the key focal points should be to emphasize, and what the ROI is to the user.

[misaugstad]

Heyo, backend has been re-architect-ed and making a labels per mission graph should now be very easy! :)

[jonfroehlich]

Re-doing the user dashboard in general would be another good assignment and would include, first, thinking about strategies to increase user engagement using behavioral economics and other incentive structures, and second, thinking about how to operationalize those in our interface (e.g., social leaderboards, badges, etc.).

Some potential papers to look at here (from a Google Scholar search, haven't looked at them):

• Prestopnik, Nathan R., and Jian Tang. "Points, stories, worlds, and diegesis: Comparing player experiences in two citizen science games." Computers in Human Behavior 52 (2015): 492-506.

• Eveleigh, A., Jennett, C., Lynn, S., & Cox, A. L. (2013, October). “I want to be a Captain! I want to be a Captain!”: Gamification in the Old Weather Citizen Science Project. In Proceedings of the first international conference on gameful design, research, and applications (pp. 79-82). ACM.

• Bowser, A., Hansen, D., He, Y., Boston, C., Reid, M., Gunnell, L., & Preece, J. (2013, October). Using gamification to inspire new citizen science volunteers. In Proceedings of the first international conference on gameful design, research, and applications (pp. 18-25). ACM.

• Iacovides, I., Jennett, C., Cornish-Trestrail, C., & Cox, A. L. (2013, April). Do games attract or sustain engagement in citizen science?: a study of volunteer motivations. In CHI'13 Extended Abstracts on Human Factors in Computing Systems (pp. 1101-1106). ACM.

• Wiggins, Andrea, and Kevin Crowston. "From conservation to crowdsourcing: A typology of citizen science." System Sciences (HICSS), 2011 44th Hawaii international conference on. IEEE, 2011.

[paarig]

@misaugstad @jonfroehlich After looking at this thread and the related back-end rearchitecting task and after extensively diving into the codebase and understanding the existing design, I have come to a conclusion on how I believe the solution to this problem should be designed. My plan is to:

• Add three new API endpoints: one endpoint to get a list of the missions for a specific user, another endpoint to get all the labels for a specific mission, and another endpoint to get all the labels for all the missions for a specific user. These endpoints will all be GET requests. From a database level, the first endpoint will find all missions that correspond to a given user_id in the mission table and sort them by date (oldest to most recent). The second endpoint will find at the labels in the label table that correspond to a given mission_id. The third endpoint will not directly touch the database layer, rather using the two previous endpoints to get the desired information. While creating three endpoints for one task may seem redundant, I believe this will improve the modularity and extensibility of the code as the first two endpoints can be combined together to execute the third endpoint. This will lead to changes to the MissionController.scala, UserProfileController.scala, and routes file.
• Manipulate the existing initializeSubmittedTasks method in the Progress.js file to hit the new endpoint rather than the old contribution/tasks endpoint and make any changes to ensure the data load is processed properly and inserted into elements with the id task-contribution-table using the HTML DOM.

Please let me know if this approach is sound and/or if you have any questions about the design. Thanks!

[jonfroehlich]

Seems fine to me. I'm less concerned with the technical details (which is what your post focused on--which is fine) and more concerned with the user experience (visual design, load times, and why we are displaying what we are displaying in the way we are displaying it)

[paarig]

@jonfroehlich I was thinking of keeping the UI similar by using the same table layout used previously. In the future, we may need to redesign the whole dashboard/user reward experience, though that appears to be outside the scope of this particular issue.

[jonfroehlich]

Ok!

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Paari Gopal notifications@github.com wrote:

@jonfroehlich I was thinking of keeping the UI similar by using the same table layout used previously. In the future, we may need to redesign the whole dashboard/user reward experience, though that appears to be outside the scope of this particular issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[misaugstad]

the first endpoint will find all missions that correspond to a given user_id in the mission table and sort them by date (oldest to most recent). The second endpoint will find at the labels in the label table that correspond to a given mission_id

I think this should actually be only one endpoint. Although your design suggestion is more modular, it will result in us querying the database once for every mission for the user. It will be much more efficient if we do it in one query/function (similar to how the table is filled right now for audits).

Also, if there is any code that is no longer being used anywhere (like the /contribution/tasks endpoint and the associated back-end functions), could you delete those? :)

[paarig]

@misaugstad Sounds like a plan

[paarig]

@jonfroehlich @misaugstad Been working on this task and have a question: should we include the onboarding mission (my initial assumption is no) and should we include incomplete missions (my initial assumption is yes)?

[paarig]

@jonfroehlich @misaugstad Please let me know for your thoughts on this new table. I thought it might be best to include some sort of marker like mission number, mission type, etc. to give the user a clear distinction between missions that occur on the same day.

[jonfroehlich]

Looks good! Tough call on whether to include tutorial labels in the table. I lean towards yes as we want people to feel like they accomplished something early on in system.

Sent from my iPhone

On Dec 23, 2018, at 12:11 AM, Paari Gopal notifications@github.com wrote:

@jonfroehlich @misaugstad Please let me know for your thoughts on this new table. I thought it might be best to include some sort of marker like mission number, mission type, etc. to give the user a clear distinction between missions that occur on the same day.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[misaugstad]

I thought it might be best to include some sort of marker like mission number, mission type, etc. to give the user a clear distinction between missions that occur on the same day.

I agree, I'm good with using "mission number". That way someone can look at their mission list and see "oh, I did finished 23 missions!".

should we include the onboarding mission (my initial assumption is no)

It is user facing, so let's go ahead and include it!

should we include incomplete missions (my initial assumption is yes)?

Yep go for it.

Please let me know for your thoughts on this new table.

For the Date column, are you using the mission start time or mission end time? I don't think it matters too much, but I would vote end time. Not sure what to do for incomplete missions? Should we use the start date? The current date? Should we say "incomplete"?

[paarig]

@misaugstad We are currently using mission start time for the Date column, though I think end time makes more sense. I am thinking if the user has not yet completed the mission, we can display the String "in progress" or something along those lines to indicate a mission that is not yet completed since we don't have an established end date yet.

[misaugstad]

Nice, I like "in progress".

[misaugstad]

Closing via PR #1369