ATLAS.ti 26 Project Cloud eignet sich für die Zusammenarbeit einer Forschungsgruppe nur bei geräteübergreifender Fortsetzung und nicht für das gleichzeitige Bearbeiten desselben Projekts. Für Echtzeit-Codierung ist ATLAS.ti Web die passendere Route; für Desktop-Analysen, Projektzusammenführung und Intercoder-Prüfungen braucht die Gruppe ein eindeutiges Hauptprojekt mit kontrollierter Verteilung und anschließendem Merge.
Dieser Leitfaden richtet sich an Forschungsleiter, die Regeln für Hauptprojekt, Zugriffsrechte und Abgabe festlegen müssen. Er hilft außerdem Studierenden und Codierern beim Wechsel zwischen Mac und Windows sowie Hochschul-IT-Teams bei der Bewertung von Lizenz, Datenspeicherung und Remote-Mac-Betrieb.
Stand der Prüfung: zuletzt aktualisiert am 07.09.2026. Die Angaben wurden gegen das offizielle ATLAS.ti-26-Mac-Handbuch, die Hinweise zu Project Cloud, Project Transfer, Team Work, Projektzusammenführung und Lizenzaktivierung geprüft.
[ SECTION_01 ] Entscheidungsrahmen für vier Arbeitswege
Die vier Wege lösen unterschiedliche Probleme. Project Cloud ist kein gemeinsamer Editor. ATLAS.ti Web ist auf browserbasierte Zusammenarbeit ausgerichtet, darf aber nicht automatisch als nahtlose Fortsetzung eines Desktop-Cloud-Projekts behandelt werden. Ein Projektmerge gehört in einen kontrollierten Desktop-Prozess. Ein Remote Mac ist dagegen eine Bereitstellungsoption für die Mac-Desktop-Version, nicht automatisch eine Kollaborationsfunktion.
| Arbeitsweg | Geeignet für | Zentrale Grenze | Freigabe, wenn |
|---|---|---|---|
| Project Cloud | Einzelne Person arbeitet abwechselnd auf Mac und Windows | Zwei Geräte dürfen dasselbe Projekt nicht gleichzeitig bearbeiten | Vor Beginn ist die aktuelle Version geladen und nach der Sitzung hochgeladen |
| ATLAS.ti Web | Echtzeitnahe Zusammenarbeit im Browser | Desktop-Projekte und Web-Projekte sind derzeit nicht gegenseitig sichtbar | Die Analyse vollständig in der Web-Umgebung geplant ist |
| Desktop-Verteilung und Projektmerge | Getrennte Codierung, Intercoder-Prüfung und kontrollierte Zusammenführung | Parallele Kopien müssen sauber benannt und technisch unterschieden werden | Ein Testmerge ohne doppelte Dokumente und mit erkennbaren Benutzeridentitäten gelingt |
| Remote Mac | Mac-Desktop-Analyse ohne Kauf eines lokalen Mac | Netzwerk, Lizenz, Datenschutz und Sitzungsbereinigung müssen separat geprüft werden | Ein anonymisiertes Musterprojekt vollständig bearbeitet und exportiert werden kann |
Die offizielle Dokumentation führt Project Cloud weiterhin als Beta-Funktion. Sie beschreibt außerdem ausdrücklich, dass nicht zwei Geräte gleichzeitig dasselbe Cloud-Projekt bearbeiten sollen. Diese Grenze ist für eine Forschungsgruppe wichtiger als die bequeme Synchronisation: Eine aktualisierte Datei ist nicht dasselbe wie ein gemeinsam bearbeiteter Projektzustand. Die offizielle Project-Cloud-Dokumentation sollte deshalb Bestandteil jeder internen Arbeitsanweisung sein.
[ SECTION_02 ] Einzelne Weiterarbeit zwischen Mac und Windows
Kann Project Cloud für den Wechsel zwischen Mac und Windows verwendet werden? Ja, wenn nur eine Person zur selben Zeit am Projekt arbeitet und jede Sitzung mit einer klaren Versionsübergabe beginnt und endet.
Project Cloud speichert eine lokale Projektkopie und synchronisiert den Projektstatus über die Cloud-Funktion. Vor dem Arbeitsbeginn muss die Person prüfen, ob eine neuere Version verfügbar ist. Nach der Bearbeitung muss sie die eigene Version wieder hochladen. Die zweite Arbeitsstation darf währenddessen nicht parallel an derselben Projektkopie arbeiten. Die genauen Hinweise zu Upload, Download und Versionsstatus stehen im offiziellen ATLAS.ti-26-Mac-Handbuch.
Der minimale Abnahmetest besteht aus einem kleinen, vollständig anonymisierten Projekt:
- Das Hauptprojekt auf dem ersten Gerät öffnen.
- Einen eindeutig benannten Testcode oder eine Testmemo ergänzen.
- Das Projekt schließen und den Upload vollständig abschließen.
- Auf dem zweiten Gerät den Versionshinweis prüfen.
- Die aktuelle Projektversion herunterladen und die Änderung kontrollieren.
- Eine zweite Änderung vornehmen, erneut hochladen und anschließend wieder auf dem ersten Gerät prüfen.
Besteht dieser Ablauf, ist die Route für persönliche Gerätewechsel geeignet. Die Forschungsgruppe sollte dafür trotzdem eine kurze Sitzungsregel festlegen: „Eine Person bearbeitet, eine Version ist aktiv, Upload ist vor der Übergabe abgeschlossen.“
Was geschieht, wenn beide Geräte nicht hochgeladene Änderungen enthalten? Die Bearbeitung muss sofort angehalten werden. Es sollte nicht weiter codiert und nicht versucht werden, durch wiederholtes Öffnen eine Version zu erzwingen. Zuerst wird die letzte gemeinsame Versionsbasis identifiziert. Danach werden die nicht hochgeladenen Änderungen gesichert und getrennt bewertet. Erst wenn feststeht, welche Version das Hauptprojekt bildet, darf die Arbeit fortgesetzt werden.
Für eine Mac-Windows-Gruppe ist diese Regel besonders wichtig, weil ein scheinbar kleiner Wechsel des Geräts die Projektbasis verändert. Wer eine Cloud-Kopie als Mehrbenutzerinstanz behandelt, riskiert unklare Codierstände, überschriebenen Fortschritt oder eine spätere Zusammenführung ohne nachvollziehbare Herkunft.
[ SECTION_03 ] Asynchrone Arbeit mit unabhängigen Projektkopien
Bei einer kleinen Forschungsgruppe kann jeder Codierer eine eigene Arbeitskopie erhalten. Das ist jedoch eine verteilte Arbeitsweise, kein gemeinsames Live-Projekt. Die Kopien müssen deshalb organisatorisch wie kontrollierte Lieferobjekte behandelt werden.
Vor dem Versand wird ein eindeutiges Hauptprojekt festgelegt. Der Dateiname sollte mindestens Projektkennung, Codiererkennung und Abgabestand enthalten. Die konkrete Namenskonvention ist Sache der Gruppe; entscheidend ist, dass eine Kopie nicht versehentlich wieder als Hauptprojekt ausgegeben wird. Zusätzlich werden Arbeitszeitraum, Materialumfang und Rückgabeweg dokumentiert.
Die erste Runde sollte nur mit anonymisierten oder pseudonymisierten Materialien stattfinden. Sie muss den gesamten Weg abbilden:
- Material aus dem Hauptprojekt auswählen.
- Eine Arbeitskopie an einen Codierer ausgeben.
- Codierung und Memos in dieser Kopie durchführen.
- Die Kopie unverändert zurückgeben.
- Rückgabe gegen die erwartete Projektkennung prüfen.
- Eine Testzusammenführung durchführen.
- Das Ergebnis und den Prüfbericht archivieren.
Als Bestehensbedingung gilt nicht, dass alle Kopien „automatisch“ zusammenfinden. Bestehen heißt vielmehr: Die Gruppe kann jede Codierung einer Person zuordnen, Dokumente werden nicht doppelt übernommen, und Abweichungen bleiben sichtbar. Die offizielle Beschreibung der Team-Arbeitsabläufe bildet dafür die bessere Grundlage als eine informelle Dateiablage.
Benutzerkonten sind dabei nicht nur eine Komfortfunktion. Wenn mehrere Personen denselben Zugang verwenden, kann die spätere Zuordnung von Codierungen, Kommentaren und Änderungen unklar werden. Die Hinweise zur Verwaltung von Benutzeridentitäten sollten daher mit dem Datenschutz- und Rollenmodell der Hochschule abgeglichen werden.
[ SECTION_04 ] Echtzeit-Codierung und ATLAS.ti Web
Ist gleichzeitiges Bearbeiten desselben Project-Cloud-Projekts möglich? Nach dem derzeit geprüften offiziellen Stand ist Project Cloud dafür nicht vorgesehen. Es darf nicht als Mehrbenutzereditor eingesetzt werden.
Wenn mehrere Personen gleichzeitig codieren, kommentieren oder Dokumente besprechen müssen, sollte die Gruppe zunächst prüfen, ob der gesamte Arbeitsablauf in ATLAS.ti Web stattfinden kann. Das ist eine andere Route als ein Desktop-Cloud-Projekt. Die offizielle Dokumentation weist darauf hin, dass Desktop-Project-Cloud-Projekte und ATLAS.ti-Web-Projekte derzeit nicht gegenseitig sichtbar sind. Ein Web-Projekt sollte deshalb nicht als automatisch synchronisierte Fortsetzung eines Desktop-Projekts eingeplant werden.
Kann ein ATLAS.ti-Web-Projekt direkt in der Desktop-Version weiterbearbeitet werden? Die Gruppe sollte davon nicht ausgehen. Sichtbarkeit, Import, Export und mögliche Formatänderungen müssen mit einem Musterprojekt geprüft werden. Dafür werden keine echten Interviewdaten verwendet. Der Test muss mindestens ein Dokument, einen Code, ein Memo und einen Export enthalten.
Der Ablauf für die Entscheidung lautet:
- Ein anonymisiertes Web-Testprojekt mit repräsentativen Elementen anlegen.
- Prüfen, welche Inhalte exportiert werden können.
- Den Export in einer Desktop-Testumgebung öffnen.
- Änderungen an Dokument, Code und Memo vornehmen.
- Das Ergebnis wieder in Richtung Web prüfen.
- Unterschiede dokumentieren und die gewünschte Route festlegen.
Wenn die Forschungsgruppe Desktop-spezifische Analysefunktionen benötigt, ist ein gemischter Echtzeitprozess riskant. In diesem Fall ist eine phasenweise Übergabe besser: Web für eine klar abgegrenzte gemeinsame Arbeitsphase, Desktop für einen kontrollierten Analyse- und Auswertungsabschnitt. Das verhindert, dass zwei Umgebungen gleichzeitig als angeblich identische Projektquelle behandelt werden.
[ SECTION_05 ] Intercoder-Prüfung und Projektmerge
Eine Intercoder-Prüfung beginnt nicht mit beliebigen Einzelkopien. Alle Codierer müssen aus einer gemeinsamen Projektbasis arbeiten. Dokumente, Codes und relevante Projektstrukturen werden vor der Verteilung festgelegt. Neue Dokumente oder persönliche Codesysteme in unabhängigen Dateien erschweren später die technische und methodische Bewertung.
Für einen Desktop-Merge wird ein Prüfprojekt angelegt. Es enthält keine Originaldaten, die nicht für den Test erforderlich sind. Die Gruppe kontrolliert dabei insbesondere:
- Sind die Codierer über ihre Benutzeridentitäten unterscheidbar?
- Bleiben Dokument- und Code-IDs im Prozess nachvollziehbar?
- Werden identische Dokumente doppelt eingefügt?
- Werden Konflikte oder Abweichungen in einem Bericht sichtbar?
- Enthält das Ergebnis noch die Materialien, die für die Intercoder-Analyse notwendig sind?
Die offiziellen Hinweise zur Projektzusammenführung und zur Intercoder-Übereinstimmung sollten gemeinsam gelesen werden. Für die Mac-Umgebung ist zusätzlich die Beschreibung von Merge und Intercoder-Analyse relevant.
Wie lassen sich ATLAS.ti-Projekte nach der Codierung mehrerer Personen zusammenführen? Nicht durch das einfache Überschreiben des Hauptprojekts. Jede Arbeitskopie wird zunächst identifiziert, gesichert und in einem Testlauf zusammengeführt. Erst nach der Prüfung des Merge-Ergebnisses darf der Vorgang mit der formalen Projektversion wiederholt werden.
Der Abnahmepunkt ist erreicht, wenn keine Dokumente unerwartet doppelt erscheinen, die Codierer eindeutig erkennbar bleiben und die Auswertung mit den zusammengeführten Materialien reproduziert werden kann. Ein Merge ohne Konfliktbericht ist kein ausreichender Nachweis, wenn die Ausgangskopien falsch erstellt wurden.
[ SECTION_06 ] Sensible Interviews und große Mediendateien
Bei Interviewdaten entscheidet nicht allein die technische Funktion. Vor einem Upload müssen Ethikvotum, Datenklassifizierung, Einwilligung, Speicherort, Auftragsverarbeitung und mögliche grenzüberschreitende Verarbeitung geprüft werden. Dieser Artikel ersetzt keine rechtliche oder hochschulinterne Datenschutzprüfung.
Die Gruppe sollte zwischen Dateien innerhalb des Projekts und extern verknüpften Audio- oder Videodateien unterscheiden. Eine Projektkopie kann nach dem Gerätewechsel formal geöffnet werden, während ein externer Medienpfad auf dem zweiten Gerät nicht erreichbar ist. Deshalb wird mit anonymisierten Testdateien geprüft:
- Ist das Dokument vorhanden?
- Wird die Medienverknüpfung auf dem Zielgerät aufgelöst?
- Sind Berechtigungen und Speicherpfad weiterhin gültig?
- Funktioniert der Export ohne fehlende Anhänge?
- Kann die Gruppe die Originaldateien unverändert und schreibgeschützt aufbewahren?
Wenn Cloud-Speicherung nach der Hochschulrichtlinie nicht zulässig ist oder Medienverknüpfungen nicht stabil wiederhergestellt werden, bleibt das lokale Desktop-Projekt in einer kontrollierten Umgebung die sicherere Route. Project Cloud sollte dann nicht durch organisatorischen Druck zur Datenablage gemacht werden.
[ SECTION_07 ] Remote Mac für die Desktop-Abnahme
Wie lässt sich ATLAS.ti 26 auf einem Mac prüfen, wenn das Labor keinen Mac besitzt? Mit einem anonymisierten Musterprojekt auf einem Remote Mac. Dabei wird nicht sofort das formale Forschungsprojekt übertragen. Geprüft wird zunächst, ob der geplante Desktop-Ablauf vollständig funktioniert.
Die Abnahme erfolgt in mindestens diesen Schritten:
- Einen schreibgeschützten Originalstand und eine anonymisierte Arbeitskopie vorbereiten.
- Eine Remote-Mac-Sitzung mit der benötigten macOS-Desktopumgebung öffnen.
- ATLAS.ti 26 starten und die Lizenzaktivierung prüfen.
- Das Musterprojekt aus der vorgesehenen Quelle laden.
- Dokumente, Codes, Memos und eine kleine Analyse bearbeiten.
- Einen Export erzeugen und außerhalb der Sitzung kontrollieren.
- Das Projekt ordnungsgemäß schließen.
- Temporäre Kopien, Downloads und lokale Sitzungsreste entfernen.
- Prüfen, ob das Ergebnis auf der vorhandenen Windows- oder Linux-Umgebung wieder geöffnet werden kann.
Die Lizenzaktivierung ist vor dem formalen Einsatz zu klären; dafür gelten die Hinweise zur offiziellen Lizenzaktivierung. Auch die Systemanforderungen der Mac-Version müssen vor der Bereitstellung gegen die konkrete Umgebung geprüft werden.
Ein Remote Mac ist bestanden, wenn die Anwendung startet, das Konto berechtigt ist, das Projekt vollständig geladen wird, die geplante Desktop-Analyse funktioniert und der Export wieder in den bestehenden Forschungsprozess überführt werden kann. Netzwerkreaktion oder Bedienkomfort dürfen nicht als allgemeine Leistungswerte ausgegeben werden, solange keine standort- und konfigurationsbezogene Messung vorliegt.
Für eine zeitlich begrenzte Abnahme kann NOVAKVM eine mögliche Ergänzung sein. Für eine langfristige, ständig laufende Analyseumgebung sollten Forschungsgruppen dagegen Kauf, Hochschulgeräte, lokale Richtlinien und die erforderliche Verfügbarkeit separat vergleichen. Ein eigener Mac kann sinnvoller sein, wenn täglich über lange Zeiträume gearbeitet wird oder physische Anschlüsse erforderlich sind; eine Miete passt eher zu Tests, Übergangsphasen und einzelnen Projektabschnitten. Als weitere Alternative kann die Gruppe die Optionen für einen Mac mini für den eigenen Forschungsarbeitsplatz prüfen.
[ SECTION_08 ] Abnahmeliste für die Gruppenfreigabe
Die folgende Liste wird pro Route ausgefüllt. Ein nicht erfüllter Punkt bedeutet nicht automatisch, dass die gesamte Forschungssoftware ungeeignet ist. Er zeigt, dass die gewählte Arbeitsweise noch nicht freigegeben werden sollte.
- [ ] Ein einziges Hauptprojekt und eine verantwortliche Person sind benannt.
- [ ] Jede Arbeitskopie trägt eine eindeutige Projekt- und Codiererkennung.
- [ ] Für Project Cloud ist ausgeschlossen, dass zwei Geräte gleichzeitig dieselbe Projektversion bearbeiten.
- [ ] Vor jeder Sitzung wird der Versionsstatus geprüft.
- [ ] Nach jeder Sitzung ist der Upload abgeschlossen und dokumentiert.
- [ ] Bei zwei nicht hochgeladenen Versionen ist ein Stop- und Wiederherstellungsprozess festgelegt.
- [ ] Für ATLAS.ti Web wurde ein eigenes Musterprojekt geprüft.
- [ ] Web- und Desktop-Projekt werden nicht als automatisch sichtbare gemeinsame Quelle behandelt.
- [ ] Für den Desktop-Merge wurde ein anonymisierter Testlauf durchgeführt.
- [ ] Benutzeridentitäten bleiben nach der Zusammenführung erkennbar.
- [ ] Doppelte Dokumente und fehlende Dokumente wurden kontrolliert.
- [ ] Die Intercoder-Auswertung enthält alle erforderlichen Projektbestandteile.
- [ ] Ethikvotum, Datenklassifizierung und Speicherfreigabe sind vor dem Upload geprüft.
- [ ] Externe Audio- und Videolinks funktionieren auf einem zweiten Gerät.
- [ ] Ein schreibgeschützter Originalstand bleibt getrennt von Arbeitskopien erhalten.
- [ ] Lizenzaktivierung und Systemanforderungen wurden in der Zielumgebung geprüft.
- [ ] Ein Export kann in der vorhandenen Laborumgebung geöffnet und weiterverarbeitet werden.
- [ ] Remote-Sitzungsreste und temporäre Dateien werden nach der Prüfung entfernt.
[ SECTION_09 ] Freigabe nach Szenario
Die Entscheidung sollte an den Arbeitsablauf gebunden werden, nicht an die bloße Tatsache, dass ATLAS.ti 26 auf einem Gerät startet. Die folgende Bewertung dient als interne Orientierung. Sie ersetzt keine technische Prüfung mit dem eigenen Projekt.
| Szenario | Empfohlene Route | Bewertungsmaßstab | Stoppsignal |
|---|---|---|---|
| Eine Person wechselt zwischen Mac und Windows | Project Cloud | Aktuelle Version vor Beginn, Upload nach Ende, keine Parallelsitzung | Zwei Geräte enthalten nicht hochgeladene Änderungen |
| Kleine Gruppe codiert zeitversetzt | Desktop-Kopien und Merge | Hauptprojekt, eindeutige Identitäten, erfolgreicher Testmerge | Unklare Projektbasis oder doppelte Dokumente |
| Mehrere Personen arbeiten gleichzeitig | ATLAS.ti Web | Web-Musterprojekt und vollständiger Web-Workflow | Desktop-Funktionen werden zwingend benötigt, aber der Übergang ist ungeprüft |
| Intercoder-Übereinstimmung | Gemeinsame Basis plus Desktop-Merge | Codierer erkennbar, IDs und Auswertungsmaterial vollständig | Mitglieder erstellen unabhängige Dokument- oder Codesysteme |
| Sensible Interviews | Lokale oder ausdrücklich freigegebene Route | Hochschule genehmigt Speicher- und Übertragungsweg | Cloud- oder Medienpfad ist nicht freigegeben |
| Mac-Desktop-Analyse ohne lokales Gerät | Remote Mac | Start, Lizenz, Projekt, Analyse, Export und Bereinigung bestehen | Nur der Programmstart wurde geprüft |
Für eine Forschungsgruppe ist damit eine klare Reihenfolge möglich: Project Cloud wird für den persönlichen Gerätewechsel freigegeben, nicht für Live-Codierung. ATLAS.ti Web wird nur als eigenständiger Web-Prozess freigegeben, wenn dessen Funktionsumfang ausreicht. Desktop-Merge bleibt die kontrollierte Route für getrennte Codierung und Intercoder-Prüfung. Der Remote Mac ergänzt diese Wege dort, wo die Mac-Desktop-Version benötigt wird, aber kein lokales Gerät vorhanden ist.
Wenn ein Labor bisher ausschließlich Windows- oder Linux-Systeme besitzt, entstehen bei einer lokalen Mac-Anschaffung zusätzliche Kosten, Geräteverwaltung, Lizenzprüfung und Wartezeit bis zur vollständigen Abnahme. Ein Remote Mac vermeidet den Kauf für einen begrenzten Testzeitraum, ersetzt aber keine Datenschutzfreigabe und keine methodische Festlegung. Für eine einzelne Projektphase kann die zeitweise NOVAKVM-Umgebung deshalb die passendere Entscheidung sein: erst mit einem anonymisierten Projekt hochladen, codieren, zusammenführen und exportieren; danach entscheiden, ob eine dauerhafte lokale Bereitstellung wirtschaftlich und organisatorisch sinnvoll ist.