Optional Type-Tags for Code and Category Memos

[maninthemiddle01]

Is your feature request related to a problem? Please describe.

QualCoder already differentiates several memo containers visually and structurally: annotations appear inline in the text, document/case memos have their own dedicated field, and journal entries are kept separate. However, memos attached to codes and categories currently serve multiple methodologically distinct functions while looking visually identical in the code tree (all shown with the same "M" indicator).

Following Kuckartz (2018, p. 175), memos attached to codes/categories can fulfill at least three different roles:

• Code-Memos — definitional rules specifying when a code applies (e.g., "Apply only when the speaker explicitly references X")
• Theorie-Memos — analytical reflections and emerging hypotheses (e.g., "This category may relate to concept Y")
• Linguistische Memos — observations about language use, metaphors, or register (e.g., "Speakers consistently use military metaphors here")

Because these are visually indistinguishable in the code tree, the researcher must open each memo individually to determine its function. This adds cognitive load in larger projects and makes it harder to navigate between "rules to follow during coding" and "thoughts to explore during analysis."

Note: Document memos and annotations are deliberately excluded from this request, because they already have their own structural/visual separation in QualCoder.

Describe the solution you'd like

Add an optional "Type" selector when creating or editing a code or category memo. The selected type would display a small icon next to the memo indicator in the code tree and in the right-hand memo pane.

Suggested default types:

Type	Purpose	Icon suggestions
Code-Memo (Definition/Rule)	When does this code apply?	📋 clipboard · 🏷️ Tag
Theorie-Memo	Analytical reflection / hypothesis	💡 Lightbulb · 🧠 Brain · 🔬 Microscope
Linguistisches Memo	Notes on language, metaphor, register	💬 Speech bubble · 🗣️ Speaking head · 🔤 ABC
(Untyped — default)	Current behavior	M (unchanged)

Design principles:

• Opt-in and backward compatible: existing memos default to "untyped" and continue to look exactly as they do now.
• Minimal data model change: a single nullable column (e.g., memo_type TEXT NULL) on the relevant memo table is sufficient.
• Scope-limited: applies only to code and category memos, since those are the only containers where one UI element carries multiple distinct methodological functions.
• Native icons preferred: while emojis are listed above as visual shorthand, Qt's built-in icon set or simple letter-badges (D / T / L) would render more consistently across operating systems and look more professional in exports.

Optional follow-ups (not required for the initial implementation, but enabled by it):

• Filter the code tree to show only memos of a given type
• Include the memo type as a column in memo report exports

Describe alternatives you've considered

• Text prefixes (e.g., "DEF: …", "THEO: …") in the memo body — works but clutters the memo text and provides no immediate visual recognition in the code tree.
• Separate memo fields per type — would be far more invasive, break backward compatibility, and conflict with QualCoder's existing memo architecture.
• Doing nothing / convention only — viable for solo projects but creates problems in team coding, where consistent recognition of "rule memos" vs. "theory memos" matters for inter-coder reliability.

Additional context

This feature would be most valuable in the code tree and the right-hand memo pane, where the researcher most often scans across many codes at once and needs to distinguish "rules to follow" from "thoughts to explore" at a glance.

Reference:
Kuckartz, U. (2018). Qualitative Inhaltsanalyse. Methoden, Praxis, Computerunterstützung (p. 175). Beltz Verlagsgruppe. ISBN 9783779946830.

[qwertygc]

There are many different ways to use the software. I’m concerned that implementing this might make one approach more rigid than others.

[ccbogel]

I am not sure about a lot of this but I feel this approach might work best, with extra programming, to show only those 'Headings' you need to see:
Text prefixes (e.g., "DEF: …", "THEO: …") in the memo body — works but clutters the memo text and provides no immediate visual recognition in the code tree.

[Salomon-Mazatlan]

Hello everyone,

Perhaps this could be included as part of the Memo Manager discussion:
#1263

It might be useful to add templates to the memo editor, or an option for headings/sections, as well as the ability to insert dates, coded segments, references, and hyperlinks to other elements (files, memos, etc.).

One of the main challenges with trying to establish fixed memo types is that these writing tools are rarely used in a uniform way. Within the same memo space, users often combine different kinds of content: reflections, analytical notes, personal observations, methodological comments, and more. Ultimately, the structure of a memo is defined by each researcher according to their own analytical needs.

[kaixxx]

I'm also skeptical about baking one methodological paradigm about memo types into the software like this.

However, your suggestion, @maninthemiddle01, points to a much more fundamental issue: Currently, we can only have one memo per code or category, not multiple. As you have shown, this is a serious restriction, as different code memos can serve different purposes. Allowing for multiple memos attached to a code would require some architectural changes in the database. So, it's not a quick fix, but should address this at some point. (We have discussed this before I think.)