Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reusing a label to "code" a fragment should be easier #112

Closed
benel opened this issue Oct 21, 2021 · 4 comments
Closed

Reusing a label to "code" a fragment should be easier #112

benel opened this issue Oct 21, 2021 · 4 comments
Labels
Fix

Comments

@benel
Copy link
Member

benel commented Oct 21, 2021 

Type: Ergonomy fix
Difficulty: Medium

Current scenario

  1. The analyst types the exact name of an existing label (aka code).
  2. She confirms that she wants to reuse the existing label.

Suggested scenario

  1. The analyst can choose an existing label (or type a new one).
  2. If she has choosed to reuse an existing label, she don't have to confirm anything.
@benel benel added the Fix label Oct 21, 2021
@christophe-lejeune
Copy link
Member

This "fix" facilitates and fosters tagging/coding. From a pure QDA point of view, this seems desirable.

However, from the point of view of a person teaching qualitative research and reflexivity, this is questionable. CAQDAS facilitates tagging (though code-and-retrieve features). Software users often become overwhelmed with tags/codes. Some of them even turn away from software for this reason.

For some researchers (as Barney Glaser), this issue motivates to focus on writing memos (for him, codes "just occur in the analyst's head"). On the other end, Suzanne Friese maintains that tagging/coding helps the researcher (tagging for organizational reasons; coding for methodological ones).

Cassandre's architecture supports both strategies: either direct memoing or tagging/coding-cum-memoing. I am not opposed to disable the warning prompt, but we should be aware that it was introduced for good methodological reasons.

@benel
Copy link
Member Author

benel commented Nov 25, 2021

I am not opposed to disable the warning prompt, but we should be aware that it was introduced for good methodological reasons.

Hmm... OK... So is it a yes or a no? ;)

christophe-lejeune added a commit that referenced this issue Jul 25, 2022
@christophe-lejeune
FEATURE: Grounding an existing memo
8e0a720 
When the user fills the add/create input field, a list of existing memos is suggested (as #83 proposed), allowing to add the current memo among the groundings of the selected memo.

If the user requests an already existing grounding, s/he is prompted that it already exists. If the memo is already grounded, but on a different fragment/paragraph, the grounding is quietly updated.

This feature can contribute to smoother coding sessions, as @benel indicates (#112). That's why it is reserved to field memos and transcripts at this stage.
@christophe-lejeune
Copy link
Member

The requested behavior is implemented. As indicated in 8e0a720 commit message, it is currently reserved to field memos and transcripts. Do not hesitate to ask to expand it to other type of memos, if you think it is relevant.

@benel
Copy link
Member Author

benel commented Oct 27, 2022

Thank you very much for this ergonomy fix.

@benel benel closed this as completed Oct 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Fix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@benel @christophe-lejeune