Change the Default Panel Displayed on the RHS After Locking a Task to Better Synergise with Mapping/Validation Workflows and Increase the Likelihood of Task Comments Being Read (data-quality, UI/UX, Enhancement)

[Pseudorandom-Pseudonym]

The Problem

The current process following locking of a task is fundamentally flawed; you always start on the completion panel.

There are several problems which stem from this, on the highest level they are;

1. Contributors do not see/read task comments.
2. Validators do not go through a comprehensive validation process, and frequently appear to not respond to mappers’ questions and comments.
3. Both groups feel frustrated that their comments are not addressed/acknowledged which breaks down communication and community.

Context

Many discussions have been had and several issues have been opened in the past by different people, all trying to address a shared experience. My proposed solution is different than the previous ones, though I am not ruling out that it could be further improved. Recurring invalidation and task comments not being addressed are still issues, so I argue that the current measures are insufficient. I want to address the arguments made by @willemarcel for the default panel behaviour on issue #3740, before going further.

1. Let’s begin by assuming that the points made are entirely correct. The only user group mentioned are absolute beginners with no prior experience of tasking managers. Validation permissions are generally more restrictive than mapping permissions, therefore the argument does not justify why the default behaviour for a user locking a task for validation should be the same.
2. Where in the process is the user presumed to have read the task instructions? When I was a beginner I was constantly referencing the task instructions while mapping. An absolute beginner cannot be expected to map well if they never read the instructions, because they are likely staring with little to no knowledge/understanding of OSM. All tasks in a new project start life without a history, therefore I propose that the default for mappers should be to start on the instructions page, unless comments have been submitted, or they have enabled expert mode in the TM.
3. If a contributor thinks that the task is complete, and they see that the timer for the task and its ID number are still visible, do you not think they will look for a way to submit the task? A prompt could be added to the bottom of the instructions to direct them to the completion panel.
4. Even if it is true that the vast majority of new contributors would not know how to submit tasks if the completion panel wasn’t the one which initially opened upon locking a task, then how many times does it generally take for someone to learn how to submit a task? Could they not be shown the completion panel until they submit say at most their first 3 tasks on the TM? This would at least reduce the proportion of tasks that contributors submit without reading the instructions/comments.

Mappers not Reading Instructions nor Addressing Invalidation Comments

The problem of mappers not reading comments on previously invalidated tasks has been a theme for years now. A mapper starts on the completion panel, so a beginner may not even know to check for comments there, partially due to its name, but also because they see no comments underneath where they write theirs (unlike in other applications). When a task has no comments, starting mappers on the instruction panel will help them make higher quality contributions from the get go. Starting them on the history panel (especially of invalidated tasks) will ensure that they see that comments exist on the task. It is not possible to submit the task until the panel is changed to completion, so this functions as a pseudo confirmation of having read the task comments/instructions.

Fig.1. How Right hand panel appears when locking a task for mapping (specific task instructions may start closed)

It also teaches the contributor about the various aspects of the tasking manager e.g. what makes a good task comment; not just how to submit a task. In projects where imagery offset is required the contributors should provide the offset used to aid future contributors, though I sometimes forget to do this for subsequent tasks e.g. I lock the first task and read the instructions then provied the offset used, then I forget for the subsequent ones, becasue I have already set it. Seeing the instructions panel again directing the contributor to offset the imagery could remind me.

Validators not Checking Task History nor Addressing Task Comments

I also often see validators not responding to relevant task comments/questions (even on recently submitted tasks), however after doing more validation myself, I find that from time to time, I also forget to check for task comments, because the completion panel is selected by default. I need to remember to go out of my way, to do what in my opinion should be a standard task during validation. Task comments can provide insight into a contributors thoughts which is very beneficial when providing feedback.

Fig.2. How the right hand panel appears when locking 1 task for validation

I and hopefully other validators want to know and understand the context surrounding a project and task before doing anything to it. This also prompts the validator to check who made the contributions to provide targeted feedback. If the history is complex/extensive I like to check the changesets in OSMCha, but when I start on the completion panel it’s all too easy to just decide if a task should be finished, add comment(s), then click the big red button, only to realise that I haven’t checked for comments on the past several tasks.

Tasks can appear deceptively complete at an initial glance, though checking the instructions may very well change your mind. Sometimes another user mapped the task than the person that submitted it, so you may wish to address them in a feedback comment. Maybe they need some encouragement to say ‘you could have submitted that task it was completely well mapped’, but you may not be aware of that if you don’t check the history. A task may have been previously invalidated and checking the changesets to see if any changes were likely made could save you time and make validation easier.

Conclusion

I’m all for features which save time, but I’m inclined to believe that the current behaviour is a time sink on the whole. e.g. invalidating tasks for poor contributions, invalidating tasks again and again, and checking task history one by one is more time consuming than several when multitask validating etc. Not to mention the lost motivation, opportunities for skill development, and user interaction when contributors’ comments seem to just be cast into the void.

Yes, I am aware that contributors are shown the instructions on the left hand side before they even pick a task, however if they’re just clicking the big red button in the bottom right; they’re likely to miss it. Sure the history panel shows (in a red circle) how many actions have occurred, and mappers get a prompt about relevant task comments, but they’re likely more concerned with the data in the task area, and whether or not to submit the task as completely mapped. I use contributors’ handles when writing feedback comments, but that isn’t going to notify the following one(s).

Continual re-invalidation without contribution still occurs, therefore, the current prompts are not enough. Mappers outnumber validators by a significant margin which can sometimes lead to validators being stuck in a loop of invalidating the same tasks in the same validation session, if the project is active enough, rendering invalidation ineffective. What’s worse is that when multitask validating you get neither the red circle on the history tab, nor the prompt to check for relevant task comments, so it is all too easy to forget to check them.

Fig.3. How the right hand panel appears when locking 4 tasks for validation

It is my hope that this ticket demonstrates the ongoing issue faced by the contributor community and how this proposal would improve the experience of all contributors working via a tasking manager. Changing this default behaviour will not solve all of the problems listed entirely, as some of this is certainly the result of lack of skill/understanding, however I do think this will address them all systematically.

It will also make the skill issues significantly easier to identify, becasue the certainty of someone having read the comments and instructions is that much greater knowing that they are displayed by default, without requiring any additional logging/tracking of user activity, or asking someone if they read them. Having greater certainty regarding this metadata when validating can completely change your approach and efficacy when providing feedback. i.e. you will be more likely to focus on developing someone's skill rather than just telling them to read the instructions.

My proposal

Please change the default starting panels to the following;

• Contributor locks their first (few) tasks on the TM for MAPPING → Maybe completion panel.

• Contributor locks task with no comments for MAPPING → Instruction panel with prompt to submission panel at the bottom of the instructions by default.

• Contributor locks task with comments or invalidated task for MAPPING → History panel which could prompt to the instructions.

• Contributor with expert mode enabled locks task for MAPPING → Completion panel to allow for slightly faster clearing of empty tasks, though these ought to mostly be handled at the project creation stage.

• Contributor locks task(s) for VALIDATION → History panel.

Additional context

Related issues;
#3507
#3740
#4784
#5600
#5922
#6687
#6831

Validators discussing continual re-invalidation of tasks (not exhaustive);

https://hotosm.slack.com/archives/C4GLC45PY/p1710655078052569?thread_ts=1710555680.081259&cid=C4GLC45PY

https://hotosm.slack.com/archives/C4GLC45PY/p1592985199259000?thread_ts=1592921953.256800&cid=C4GLC45PY

https://hotosm.slack.com/archives/C4GLC45PY/p1687240760477259?thread_ts=1687220794.155849&cid=C4GLC45PY

https://hotosm.slack.com/archives/C4GLC45PY/p1743433967158079

https://hotosm.slack.com/archives/C4GLC45PY/p1665051119436249?thread_ts=1665049254.054759&cid=C4GLC45PY

Mapper with 3000 changesets (at the time) who started a thread in the validator channel of the HOT Slack unhappy that their task questions and comments were not addressed/ feedback not provided when requested;

https://hotosm.slack.com/archives/C4GLC45PY/p1561376913122700

Describe alternatives you've considered
Show a pop-up to mappers (who would have otherwise locked an invalidated task) directing them to view the task history and read the comments to get an idea of the likely work required, before locking. This could also simplify the task history by allowing contributors to make a more informed choice about the task they wish to lock. It would need to take into account splitting of tasks. i.e. if a task is split it no longer appears as invalidated, but a contributor should still see the message.

Others are not really altenatives, but more so suppliments e.g. adding an indicator for validators when there are comments on tasks selected for validation. Some of which are already outlined in existing issues like #4784.

If anyone has any other perspectives, info, ideas, wants to point out something I've missed etc., then by all means chip in. Any reactions to this issue showing support would be greatly appriciated.

[linear]

TECH-810

[Pseudorandom-Pseudonym]

P.S. Example task undergoing recurring invalidation 5 times Cross reference its history with the changesets.

View the changesets to see that no contribution to buildings occured until the 6th mapper locked and submitted it as mapped despite task comments outlining the issues and how to fix them, as well as mentions to contributors who locked the task

[Adrian-Shobrooke]

I don't understand why @willemarcel states that 'The Completion tab gives the context and teaches new users what they need to do'. The Completion tab gives no context and no instructions. Context is in mainly in the project description, teaching new users takes place in in the instructions (if they are good instructions) or training sessions and good mapathons. (And how many times have we seen poor instructions and poor mapathons?)

Having the Completion tab first lends no encouragement to review the other tabs. Shouldn't completion come at the end of the process, not the beginning? There is also a left to right reading bias in #3507, that the map comes first, then the completion. If this left to right order is fixed, map, instructions, comments, completion makes more sense to me. Completion at the end, not midway.

Perhaps comments should be separated out from the locking history. The locking history is not much use to a mapper. Default to written comment only with an option to included Locking history along the lines of the way the Task History is shown if selected directly from the task list. Doing this would tidy up what is presented to a mapper to aid completion.

The tab order does little to help new mappers complete tasks and I wonder how demotivating it must be for new mappers to have their tasks rejected because the TM does not show any information of what is still required?

I would also place the comment box before 'Is this task completely mapped?'. This would encourage mappers to write something to help the validators or subsequent mappers. Perhaps the completion question should be inactive/greyed out until a comment (minimum length?) is entered. This would not stop some from writing 'asdfasdf', but might encourage a little more responsibility or thought from mappers. If they are mapping a rejected task, they would start to understand the comment history when they have to add their own context.

Validators and mappers have given their time to create Github accounts to suggest several changes over the years as demonstrated by the issues raised, some repeatedly by different users. I am surprised that anyone thinks the status quo is working well. Perhaps it is for some. Yet some validators now fix up more mapping rather than invalidate it as they have ended up in the submit/invalidate cycle too often. I for one am not willing to waste my volunteer time in either fixing up large amounts of data OR get into the submit/invalidate cycle. Neither of those are ways to develop better mappers.

The whole history of not acting on the validator concerns as demonstrated by the Github issues linked above leads me to think that the validator time is not valued as much as the volume of time spent by new mappers and poor mapping.

I fully support the ideas and reasoning presented by @Pseudorandom-Pseudonym above. This is time well spent, I hope.

I can't support the status quo as it does not value my validation time. I enjoy most of the mapping enough not to undertake validation activities until I see a change in how validation activities are eased by the TM process. This is a shame as I won't be influencing mappers so much, but I won't have my volunteer time wasted by repeating myself.

[Pseudorandom-Pseudonym]

@Adrian-Shobrooke thank you very much for your support on this issue!

The reading direction idea is a fantastic way to implicitly guide contributors through a thorough process, this could be tied to the language a user has chosen so that both left to right, and right to left languages are catered for.

I don't understand why @willemarcel states that 'The Completion tab gives the context and teaches new users what they need to do'.

I'll share my understanding of what @willemarcel meant by this. To me this has to do with the task, yes, but not with the mapping. The user is able to see what they need to do to change the status of the task. I agree with him that the design of software should be intuitive, and inform and teach the user, however I think that the way the TM currently functions does not successfuly do this. It prioritises showing the user how to change the status of a task over informing them how to, or when a task is complete.

I wonder if this has always been the default TM behaviour and if there were any complaints or observations that contributors could not figure out how to submit tasks.

An often cited example of good intuitive design is the first level of super mario bros. where the player is incrementally introduced to new features as they progress, however the TM equivelant in this case would be starting the player at the flag pole, or maybe a pipe to the next world/level, then expecting them to backtrack to see all the other features rather than just going onto the next one.

Showing task comments (when present) would achieve this intuitive and incremental design, because contributors would gain an understanding of what makes a good task comment by being on the recieving end of them.

Ultimately it'd be best if contributors could just choose their prefered default in the settings, but making this change could encourage validators to invalidate as appropriate rather than believing that doing so is largely futile.

[ramyaragupathy]

@suzit-10 has a prototype ready with the agreed solution. He will be able to share it here for thougths.

Agreed solution:

• helper text in each tab indicating each tab's functionality
• history as default tab for validators
• instructions as default tab for mappers

[suzit-10]

As @ramyaragupathy mentioned, each tab includes a brief description and links to the other tabs at the top of the content as an information. This helps users understand the purpose of each tab and decide where to go to perform a specific action. We’re open to adding more details or updating the tab descriptions as needed.

[Adrian-Shobrooke]

Agreed solution:

• helper text in each tab indicating each tab's functionality
• history as default tab for validators
• instructions as default tab for mappers

Thank you for starting work on this.

I thought we also agreed that the 'history' tab would become the default tab to mappers viewing tasks with invalidated status?

This may be more important to the above features to help prevent the cycles of tasks being resubmitted 'complete' by new mappers with no additional work taking place.

[ramyaragupathy]

Instructions: Read the task guidelines and mapping steps before you begin.
History: View past mapping and validation activity, including comments.
Resources: Access reference materials, links, and supporting data.
Completion: Leave comments, unlock the task, and update its status.

@suzit-10 - please use the above helper text for implementation.

@Adrian-Shobrooke - understood, we will make sure to include that behaviour.

[Adrian-Shobrooke]

Thank you @ramyaragupathy . It was just the Comments in the History, not the full history of task locking etc.