f4 Online Manual
Research in a team can be very enriching: different perspectives on the same material often produce new insights, and in larger projects the work can be divided up sensibly. f4 supports various forms of collaboration – from the joint analysis of individual texts to the exchange with other QDA programs.
When several people code the same text independently of each other, surprisingly different interpretations often arise. This diversity of perspectives is very valuable: it can uncover blind spots, open up new perspectives and significantly increase the quality of the analysis. The process of comparing and discussing different codings often leads to deeper insights than when one person works alone.
One person creates a project with all the texts to be analyzed (see chapter 3.2) and copies this project file several times via Finder or Windows Explorer (Ctrl+C/Ctrl+V for Windows, ⌘C/⌘V for Mac). Rename the copies, e.g. “Analysis_Ana.f4project”, “Analysis_Ben.f4project” and distribute them to all team members. This guarantees that everyone starts with exactly the same texts – this is absolutely crucial for merging later on.
Each person then opens their project file and creates a main code with their own name (click on the plus in the code list). All codes used are created as subcodes of this name code. This has the great advantage that you can later see at a glance who did which coding. In addition, each person should choose a different color for all codes (click on the color bar in front of the code) – this makes it much easier to distinguish between them.
Now each person reads for themselves, develops codes, writes memos and codes text passages. It is important that the work is truly independent – agreements during this phase would dilute the different perspectives. Save your project with a meaningful name, e.g. “Interview_Protest_Ana_2025-08-14.f4project”.
To compare the different views, a person opens their project and clicks on the project management icon in the toolbar (see section 1.3). There you select “Merge projects” and select the other project files. All memos, comments, codes and coding from the other projects are now imported. The personal codes and colors make it possible to distinguish the various contributions at a glance – and the differences are often astounding!
Now it’s getting exciting: Where does everyone agree? Where are the differences? These are discussed and transferred into a common interpretation. Codes can be deleted or merged (drag & drop of one code onto another), the code system can be reorganized and new categories can be created. It is important that all decisions are documented: For code decisions, move the mouse over the affected code, click on the three dots (menu icon) and select “Comment”. For text-related decisions, create a memo directly at the relevant text passage (select and Ctrl+M, see chapter 4.1).
Ana, Ben and Cem analyze “Interview A” on student protests. Ana focuses on emotional aspects and codes many passages as “frustration” or “hope”. Ben sees political dimensions and uses codes such as “institutional critique” or “understanding democracy”. Cem focuses on group dynamics with codes such as “solidarity” or “conflict”. After bringing them together, it becomes clear that all three levels are closely interwoven – a realization that would not have come about without the different perspectives.
For larger corpora, it makes sense to split the work. For example, if you have 12 interviews, each person can work on 3-4 of them. However, the prerequisite is that the code system is known to everyone and is largely stable. This way of working is particularly suitable for the later phases of a project, when the basic structure of the code has already been developed.
One person creates an initial project with the final code system including detailed code definitions in the comments. These definitions are crucial to ensure that everyone has the same understanding of a code. Then copy this project file via Finder (Mac) or Windows Explorer (Ctrl+C/Ctrl+V for Windows, ⌘C/⌘V for Mac) and rename the copies, e.g. “Project_Ana.f4project”, “Project_Ben.f4project”.
Each person opens their project file and only imports the assigned texts (see chapter 3.2). The other texts can be deleted from the text list (trash can symbol next to the respective text). Now each person can concentrate on coding their texts using the predefined code system. Text comments or memos can be created for new findings – this is important for later exchange.
At the end, all sub-projects are integrated into an overall project via “Merge projects”. New texts, codes and comments are added automatically. New or renamed codes, changed colors and different comments are exciting – these have to be viewed and decisions made, which are documented in the code comments.
To make code system changes comprehensible for everyone, create a main code “Project notes” (click on the plus in the code list). Move the mouse over this code, click on the three dots and select “Comment”. Document all changes here:
Changelog: 14.08.2025 - Ana: Code "Intrinsische Motivation" hinzugefügt 15.08.2025 - Ben: "Extrinsisch" umbenannt in "Externe Faktoren" 16.08.2025 - Cem: Neue Subcodes unter "Gruppenverhalten"
Often you have developed a well thought-out code system and want to make it available to others – but without revealing your own texts. There can be various reasons for this: Data protection, confidentiality or simply the desire to make work easier for others without sharing your own content. Or you would like to use the proven code system in a new project.
Copy your project file via Finder or Windows Explorer (Ctrl+C/Ctrl+V for Windows, ⌘C/⌘V for Mac) and rename the copy to something meaningful, e.g. “Codesystem_Interviews_2025-08-14.f4project”. Open this copy in f4 and delete all texts (trash can symbol for each text in the text list). Only codes, colors and the valuable code comments with definitions remain. You can now pass on this “empty” project file.
The other person can then import their own texts and immediately work with the proven code system. Alternatively, they can add the code system to their existing project via “Merge projects”. This way she benefits from your preparatory work without you having to reveal your texts.
REFI-QDA is an open standard for data exchange between various QDA programs such as f4, MAXQDA, ATLAS.ti or NVivo. This is particularly helpful if team members use different programs or if you want to switch to a different program. The standard was developed to solve the often frustrating compatibility problems between different software solutions.
Click on the export icon in the toolbar (see chapter 1.3) and select “REFI-QDA”. The resulting .qdpx file contains all texts (without formatting), codes with colors and comments, all codings, memos and comments as well as groups with comments. The .qdc format is also available for pure code systems without texts. The .qdc format is also available for pure code systems.
Use the REFI-QDA import of the respective target software. Although REFI-QDA is a uniform standard, different programs handle details differently. You should therefore check randomly after each import: Are all texts complete? Are the codes and colors right? Have codes been transmitted correctly? Are longer comments displayed in full? Display differences can occur, especially with longer code comments and text comments.
Not everything can be transferred: Text formatting is lost, coding within memos only works in f4, media file links have to be recreated, and program-specific functions such as variables in MAXQDA are not supported. Despite these limitations, REFI-QDA is a major step forward for collaboration between different QDA programs.
Good preparation makes the difference between success and frustration in teamwork. Use meaningful and dated file names such as “Protest_Ana_2025-08-14.f4project” – this helps enormously with later assignment. Set a different color for each person and document this somewhere. Leave the original texts unchanged, even if there are spelling mistakes – you can correct them together later. Make sure that everyone is using the same f4 version and copy all project files as a backup before merging (Ctrl+C/Ctrl+V for Windows, ⌘C/⌘V for Mac).
When merging, one person should take the lead and document all decisions. Proceed systematically: First merge all projects, then deal with conflicts. Record decisions on codes in code comments (mouse on code → three dots → comment) and text-related decisions as memos directly in the text.
After merging, you should check for completeness: Are the number of texts, codes and encodings correct? Randomly checks whether coding and comments have been transferred correctly. Save the finished merged project separately – you have invested a lot of work!
f4 automatically creates backup copies, which you can access via the menu icon → Backup copies (see chapter 1.3). For important team projects, you should also copy the project file manually before each major work step (Ctrl+C/Ctrl+V for Windows, ⌘C/⌘V for Mac). This allows you to return to a working state in an emergency if something goes wrong when merging.
