Review von RADAR 8.0 - Review im wachsen, zum jetzigen Zeitpunkt noch nicht vollständig

von HELI Retzek,  Mai 2002

da die MacRep als PowerTool für " normal-Ordinationen" seit mehr als 5 Jahren keine wesentlichen Entwicklungsschritte gemacht hat, Radar im Gegensatz dazu sein Programm stabil, dynamisch und extensiv entwickelt, hab ich mir jetzt (Jänner 2002) auch noch eine Lizenz von Radar gekauft. Ich benutze beide Programme zum Lernen und Nachschlagen, in der Praxis, beim Patienten wegen der Notwendigkeit mit dem Complete Repertory zu arbeiten (siehe Review Complete Rep vs Synthesis) und der mangelhaften Navigations-Möglichkeit von Radar immer noch ausschliesslich MacRep.

1. die " Kundenbetreuung" von Dr. Hettich, den ich bezüglich des Programmes angesprochen habe, ist perfekt, absolut empfehlenswert, kann sich durchaus mit Cornelia Marent messen, die bisher für mich TOP of the TOP war!

Reaktionszeiten von Stunden auf eine Mail, Dr. Hettich hält Probleme in Evidenz, kümmert sich prompt und unaufdringlich. Der von mir empfohlener Ansprechpartner unter: http://www.radar-service.de

2. die Kundenbetreuung der Programmierer bzw. Developer in Belgien ist super! Bekam am Samstag morgen bereits eine Antwort auf eine Mail vom Freitag nacht (Philippe.Santantonio@archibel.com), und zwar direkt vom Chefprogrammierer!

3. die Kundenbetreuung des 24h Services - geleitet von Jean Claude Spelte - ist nach Aussagen von XXX genial. zB: ein BUG im Repertory Varianten-Editor brachte uns beiden (XXX und mir, die viele Additons einfügen und die Traumprüfungen abdrehen - und daher dieses Tool einsetzen) das Programm zum Abstürzen. XXX hat Dienstag vormittag lang mit der Help-Line / Jean Claude telefoniert, zu Mittag hat XXX von Jean Claude bereits das Update des Varianten-Editors gemailt bekommen, der diesmal Bug-Free lief (im Vergleich bei MacRep: Version 5.0 bis 5.6 waren über 4 Jahre ohne irgendeinen technischen Fortschritt im Programm nur Bugfixes bzw. Functions-Fix, sodass die bereits offerierten Funktionen das erfüllten was sie versprachen)

Die Datenbank hinter dem Programm

Das Programm RADAR ist mittlerweile in einigem, v.a. im noch offenen und nur teilweise ausgeschöpften Potential der zugrundeliegenden Datenbank meinem altehrwürdigen MacRep, welches ich mittlerweile seit der Version 3.0 am PC verwende (aktuelle Version 5.6), um Jahre voraus: 

ich meine, dass dies v.a. dem Faktum zuzuschreiben ist, dass die RADAR Developer eine kontinuierlich weiterentwickelte professionelle Datenbank-Struktur von http://www.faircom.com/ als Datenbasis für RADAR verwenden. Faircoms CTREE - Datenbanken werden u.a. in grossen Banken, bei Finanzdienstleistern und in anderen kritischen Bereichen verwendet, in denen mit riesigen Datensammlungen und " kritischen Daten" gearbeitet wird, 

Wer sich das Lizenz-Modell von Faircom ansieht wird entdecken, dass hier pro User vom Entwickler eine weitere jährliche Lizenzgebühr bezahlt werden muss, zB US$ 5000 für 2500 Lizenzen. Dies ist gleichbedeutend mit laufenden, anfallenden Kosten für die Firma RADAR, nicht selbstverständlich trotzdem diese sehr professionelle Lösung einzusetzen, die das problemlose Einbinden von Multimedia-Daten u.a. ermöglicht.

diese (externe) Datenbank-Lösung ist sicher optimal und ermöglicht es, dass jede " RUBRIK" als Objekt im Programm dargestellt wird, sodass jeder Rubrik beliebige Anmerkungen, Querverweise, Fotos, Videos, Sound-Files, usw zugeordnet werden können.

Dies kann sehr einfach in einem " Kontex-Dialog" geändert werden. Der Folgende Screen - Cut zeigt den Kontex-Dialog, über den sowohl Arzneimittel, Querverweise, Synonyme, Haupt-Synonyme, Notiz zum Symptom, Radar-Notiz zum Symptom (kann vom Benutzer nicht geändert werden), Notiz zum Autor, Radar Notiz zum Autor, Multimedia-Objekte, Konzepte (=Themen-Rubriken) leicht und einfach geändert, ergänzt, editiert usw werden kann.

Hinweis für die Programmierer von Radar: die Farbgestaltung des Dialogs könnte gefälliger sein, sodass sich der Dialog besser vom Hintergrund abhebt, die Beschriftung der Buttons ist nicht optimal und wirkt unschön. Vor allem fehlt eine " Sichern & Close" Funktion, sodass jedesmal mindestens 2 Buttons gedrückt werden müssen um eine einzelne Eingabe zu sichern und den Dialog zu schliessen - was dem " Oft Benutzer" dieser Funktion bald auf die Nerven geht.

diese Funktion verdient 8 von 10 Punkten, Abzüge wegen der schwachen optischen Gestaltung und der fehlenden Save & Close Funktion, die sich bei öfterem Rubriken-Editieren schmerzhaft bemerkbar macht.

MacRep hat ja ein Jahrzehnt länger am Buckel, wird ausschliesslich am MAC entwickelt (und nur in einem Mac-PC - Interpreter am PC als " Virtuelles MacProgramm" ausgeführt) und muss sich wohl zunehmend mit seiner uralten, eingeschränkten, selbstgestrickten Datenbanklösung, die anno 1990 hyper, heute allerdings altvaterisch wirkt, herumschlagen.

Nicht nur die Rubrik ist " als objekt" programmiert, auch die einzelnen Arznein in der Rubrik sind derartig angelegt. Daher können zu einer Arznei beliebig viele Autoren-Indizes zugefügt werden, wobei die Autoren-Indizierung nicht RADAR, sondern Frederik Schroyens SYNTHESIS zugeordnet werden muss.

Hier ist für " Repertoriums-Bearbeiter" einer der grössten Pluspunkte von RADAR: das genial die Rubriken-Arznei-Eingaben unterstützende Konzept:

Zufügen bzw Editieren von Arzneimittel

Dieser Abschnitt ist einer der grossen Pluspunkte von Radar. Durchdacht und so einfach in der Bedienung, dass es völlig unverständlich erscheint, dass dieser Abschnitt in MacRep bisher nicht adäquat ausprogrammiert worden ist.

Nachdem man eine Rubrik gewählt hat, öffnet man den " Arzneimittel-Dialog" [Dialog ist der Programmiertechnische Ausdruck für ein " Hilfsfenster" bzw " Hilfsformular" ], dieser ist noch mit dem Namen des zuletzt eingegebenen Mittels besetzt, was eine grosse Hilfe ist, wenn man eine Arznei in 5 oder mehr Rubriken zufügen möchte (NON MacRep, dort muss jedesmal dieselbe Arznei neu eingetippt werden)

Nachdem man die Arznei mit 3-4 Tastenanschlägen gewählt hat und ENTER drückt, öffnet sich sofort der AUTOREN - DIALOG

wobei ebenso elegant, und zwar entweder mit der bekannten Abkürzung des Werkes des Autors oder mit dem vollen Namen die genaue Quelle des Autors angegeben werden kann. (NON MacRep, genaue Schwachpuntkbeschreibung dort). 

Sehr vorteilhaft ist die Lösung mit den Autorenindizes im Synthesis gewählt, denn es ist tatsächlich ganz klar, wo der Nachtrag herstammt. Im Complete von Roger van Zandvoort kann dies nur bedingt nachvollzogen werden, da für die meisten Autoren nur ein einziger Autoren-Index vorhanden ist und man bei sehr vielen der Nachträgen den Nachtrag nicht kontrollieren kann. Bei der grossen Zahl der nicht - überprüfbaren Nachträge im Complete/Mind gibt das dem Complete/Mind eine grosse Unsicherheit, XXX YYY wird hier gesondert einen Artikel über die vielen Referenz-Fehler im Complete schreiben.

Für mich, der beständig das Repertorium erweitert bzw. korrigiert ist dies eine glänzende, sehr hilfreiche und optimal in der Bedienbarkeit gelöste Funktionalität in Radar! 

Nachteil von Radar: es können Autoren nur bedingt zugefügt werden, die Autoren-Datenbank ist nicht selbst erweiterbar - man muss aus 60 " vorgefertigten" Autorenkürzeln wählen (Aut1 ... Aut 60) um neue Autoren zuzufügen.

Dafür 7 von 10 Punkten, Abzug wegen der fehlenden Möglichkeit die Aut1 ... Aut60 mit Text / Autor-Namen zu belegen, denn nach einigen Monaten erinnert man sich nicht mehr, wer jetzt Aut15 ist, und den irgendwo notierten Zettel hat man verschmissen oder das File vergessen, wo das steht.

• Vorschlag für die Autoren von Radar oder für Rep-Änderer: einfach eine Repertoriums-Rubrik " Autoren" unter Allgemeines anlegen, in denen der Benutzer über eine spezielle Funktion die Autoren wie einen Querverweiss eintragen und Nachschlagen kann, direkt im Repertoriumsfenster. Das ist sehr rasch programmiert und funktional, so können dann die extra-Autorenindizes des Benutzers auch automatisch bei Updates über das Logfile mitgenommen werden.

Wie umständlich und hilflos scheint im Vergleich dagegen MacRep, wo die Funktion Remedy-Additon seit 8 Jahren unverändert benutzer-unfreundlich gestaltet ist. Siehe dazu die Review von MacRep/Arzneimittel-Editieren

Der Reperoriums-Bildschirm

genial das Konzept, den Bildschirm des Repertoriums voll " objekt-orientiert" zu gestalten. Ein Doppelklick auf eine Rubrik öffnet ein " Konzept-Fenster"

Die Repertoriums-Updates

mein Freund XXX YYY hat mit grosser Akribie und Zeitaufwand viele Rubriken " nachgeschlagen" in allen entsprechenden Quellen, die " Rubriken überarbeitet" , wie er meint. 

Da die Repertorisationen, die aufgrund seiner " überarbeiteten Rubriken" mehrmals ein anderes (nämlich ein erfolgreiches) Ergebnis erbracht haben, als mit meinem CompleteRepertory/MacRep, wollte ich unbedingt auf seine Nachträge zurückgreifen können, dies war der eigentliche Grund mir selber eine Radar-Installation zu kaufen. Ich bekam Radar 8.1 mit Synthesis 8.1 geliefert. XXXs Version war jedoch noch Radar 7.01 mit der entsprechenden Synthesis Version.

Also musste ich die Nachträge von der Version 7.01 in die Version 8.1 übernehmen.

Allgemeine Bemerkungen:

Prinzipiell ist diese " Nachtragsgestaltung" - durch " DAT-Datei" und durch " Text" Datein weniger durchsichtig für den einfachen Benutzer gestaltet als in MacRep, bei dem nur eine einzige Datei, nämlich eine Text-Datei vorhanden ist. Dies ist vermutlich eher Geschmacks-Sache des Profis, da der einfache Benutzer dieses Duale (=redundante) System sowieso nicht durchschauen wird, an sich ist die DAT-Datei das weniger Fehleranfällige System, da es direkt vom Datenbank-System (CTREE+) kommt, die Radar-Programmierer haben dem wohl nicht ganz getraut und sich noch zusätzlich eine Textversion gestaltet. Die Ausführung dieser Textversion gefällt mir ausserordentlich, da sie ganz klar und deutlich die Vorgehensweise protokolliert, dies ist in MacRep viel viel umständlicher und daher fehleranfälliger gelöst

zB: ein Ausschnitt aus einer derartigen Text-Datei:

---------------------------------------------------------------------------------------------------------
Ergänzen eines Autors oder eines Arzneimittels: phos. 2 [ptk1] (46823/0) Lg. 0

Abdomen 
Pankreas Beschwerden des

Operation Nummer: 14730 Datum: 07/08/2001 Uhrzeit: 09:20:01 Operand: 0
---------------------------------------------------------------------------------------------------------
Ergänzen eines Autors oder eines Arzneimittels: spong. 1 [ptk1] (46823/0) Lg. 0

Abdomen 
Pankreas Beschwerden des

Operation Nummer: 14731 Datum: 07/08/2001 Uhrzeit: 09:20:08 Operand: 0
---------------------------------------------------------------------------------------------------------
Verändern des Grades des Arzneimittel und des Autors: spong. 2 [ptk1] statt spong. 1 [ptk1] (46823/0) Lg. 0

Abdomen 
Pankreas Beschwerden des

Operation Nummer: 14732 Datum: 07/08/2001 Uhrzeit: 09:20:11 Operand: 0
---------------------------------------------------------------------------------------------------------

also wunderschön gestaltet, klar und durchsichtig, nur die UHRZEIT stimmt nicht, ich habe diese Einträge um 21h und nicht um 9h gemacht, hier wurde keine 24h Uhr gewählt.

Im Vergleich dazu siehe RepChanges-Datei von MacRepertory

Das " Repertoriums-Hilfsprogram"

eine externe Krücke um Repertorien mit Nachträgen zu gestalten. Das Programm ist eher ältlich, heutzutage darf man sich eine von " Assistenten" geleitetes Vorgehensweise erwarten, die mit div. begleitenden Hilfetexten erklärt, was hier eigentlich gemacht wird, sodass Fehlbedienungen und dadurch verursachte Datenverluste nicht vorkommen. Prinzipiell ist 

Nun: ich habe die TXT-Datei von XXX in meinem RADAR durchlaufen lassen, das hat gut und gern 1h gedauert und hier ist das ergebnis:

also, 14.824 Veränderungen von XXX wurden übertragen

Hier die Entsprechende Auswertung-Datei

                                                                                      Anzahl      Fehlerfr          Fehler

Verändern des Grades des Arzneimittel un        2834              2523                311

Löschen eines Autors oder eines Arzneimi          764                626                138

Ergänzen eines Autors oder eines Arzneim      10230              8958              1272

Editieren einer Notiz                                              440                440                    0

Editieren eines Querverweises                                  0                    0                    0

Editieren der Synonyme zu den Symptomen               0                    0                    0

Verändern des Textes eines Symptoms                    71                  71                    0

Hinzufügen eines Symptoms der gleichen E          311                303                    8

Hinzufügen eines Symptoms als Unterrubri          164                160                    4

Löschen eines Symptoms                                              10                  10                    0

Symptom bewegen                                                              0                    0                    0

Symptom schneiden                                                          0                    0                    0

Symptome zusammenfassen                                              0                    0                    0

Multimedia Objekt erstellen                                      0                    0                    0

Multimedia Objekt entfernen                                      0                    0                    0

Symptom einem Konzept hinzufügen                            0                    0                    0

Symptom vom Konzept entfernen                                  0                    0                    0

Change marker                                                                  0                    0                    0

TOTAL                                                                          14824            13091              1733

Wenn man sich die 1733 Fehlermeldungen ansieht, erkennt man, dass die meisten Fehler daher stammen, dass im RADAR 8.0 Nachträge von Autoren bzw. Arznein bereits vorhanden sind, die von XXX in bestimmten Rubriken " nachgetragen" wurden.

Übrig bleiben: 444 Fehler, die absolut nicht eingebaut werden konnten. Eine Liste mit den Möglichen Fehlermeldungen findet man nicht im Programm oder im Report, sondern im leider unvollständigen Manual zu diesem Programm, welches nur einen Bruchteil der Menü-Optionen dokumentiert und anscheinend sehr  rasch und oberflächlich runtergeklopft worden ist.

Man findet dann die speziellen Fehler, in dem man zB in  Winword die Datei ..... mit BEARBEITEN/SUCHEN den Suchdialog öffnet, dann den folgenden Text suchen " zum Symptom nicht gefunden" eingibt

dann zum ersten Auftreten dieses Fehlers hüpft, den Fehler analysiert

zB beim Obigen SCREEN-Cut sieht man, dass er OPIUM eintragen wollte mit Autor " h" aber nix eintragen konnte, vermutlich weil die Rubrik Gemüt - Furchtlos einfach nicht gefunden wurde oder so,

jedenfalls muss/kann man diesen Fehler im RADAR selber korrigieren

und mit der Tastenkombination SHIFT-F4 wird in Winword zum nächsten Vorkommen des Fehlers gehüpft.

Schlüsselsymptome

ähnlich wie in MacRep, aber eigentlich - dank des objekt-orientierten Rep-Fensters praktischer gelöst, man kann eine beliebige Arznei aus dem Rep-Fenster anwählen

und auf das Schlüssel-Symbol ziehen (in MacRep geht das nur aus der Graphik heraus), es öffnet sich dann eine entsprechende Keynote-Datei (Hering, Boericke, eigene, Radar ...), jedenfalls jene, die die Arznei auch enthält (ansonsten die voreingestellte).

Das oben gezeigte Keynote-Fenster ist optisch nicht ansprechend, ich würde mir dazu folgende Änderungen wünschen.

1. RTF-able (die Möglichkeit die Abschnitte durch unterschiedliche Font/Farb/Attribut-Formate besser Struktur anzeigen zu lassen, intermediär kann ja der Quelltext durchaus im reinen Text-Format bleiben)

2. Linker Rand etwas grösser (3-5mm), sodass der Text etwas abgerückt ist vom Rand

3. Dialog-Farbe nicht in weiss, sondern in Grau, sodass das Textfeld besser raussticht.

4. Listbox oder Combobox mit den Arzneimittellehren, in denen die Arznei vorhanden ist

ich hab schnell so ein Layout generiert um zu zeigen, was ich damit meine: 

es hat mich etwa 4 Minuten gekostet, dieses Beispiel hier zu programmieren (wohlgemerkt, das ist ja nur die Oberfläche, nicht das programmatische Fleisch dahinter). Mit diesem LAYOUT macht die Arbeit doppelt Spass und man kann konzentrierter lesen, vergleichen Sie mit dem obigen Bild

die Datenbank scheint Objekt-Orientiert programmiert bzw - wie ich mittlerweile rausgefunden habe, wird ein Externes professionelles Datnbank
- beliebige Anmerkungen, 
- Varianten der Repertorien, 
- eine professionelle Struktur um das Rep zu ändern und diese Änderungen auch mitzunehmen, 
- erstklassiges Screen-Design des Repertoriums.

Schwächen sind noch deutlich in der Benutzbarkeit für Power-User (hier liegt MacRep noch vorne), allerdings - da grundlegend die wichtigsten Möglichkeiten bereits ausprogrammiert sind, sicher in kurzer Zeit geändert oder sogar übertroffen.

Die " grossen" Entwürfe des Programmes, nämlich die objekt-orientierte Repertoriums-Datenbank, der Objekt-orientiert gestaltete Bildschirm 

(Klick auf die Arznei bringt Quelle usw. zur Ansicht, Klick auf das Symptom öffnet eine Eigenschaften-Dialog in dem ich von " Themen" , über Anmerkungen, über Bilder u.a. Multimedia-Objekte alles einstellen kann)
  u.a. sind vorbildlich - Gratulation !

zu Synthesis kann ich mich noch nicht äussern. 
Grundsätzlich konnten wir die ganzen Krebs-Fälle in den Kursen von Dr. Spinedi nicht mit Synthesis lösen - 

interessanterweise aufgrund dezitierter Nachträge in den Körper-Regionen des Repertoriums 

(die Spindi/Hee-Gruppe hat hier gute ARbeit für Roger van Zandvoorts Complete Repertory geleistet).

Schwächen von Radar, die es für mich in der POWER-USER Praxis unhandlich erscheinen lassen sind absolut die schwache  Navigation im Repertorium-Fenster.
Um vernünftig arbeiten zu können kommt man von einem Top-Down Approach (immer von der Kapitelüberschrift ausgehend sich den Rubrikenbaum runterhangelnd) nicht umhin.

Wie elegant ist hier im Vergleich die Lösung von MacRep, wo ich innerhalb einer Rubriken Ebene durch Tasteneingabe eine Rubrik anspringen kann, durch die Pfeile links und rechts eine Ebene rein oder raus gehe, schliesslich ein Symptom mit der Enter-Taste übernehme. 

Hier muss RADAR noch nachziehen, die Navigationist eindeutig die grösste Schwäche dieses ansonsten so fortgeschrittenen Programmes.

Ausserdem glänzt RADAR durch die auffallende Abwesenheit wichtiger Kbd-Shortcuts. Es ist zB nicht möglich einfach mit der Tastatur die Anzeige von Arznein ein/auszuschalten - man muss immer über das Menü und die " Voreinstellung" gehen. 

Es zeigt sich also: RADAR wird von Top-Programmierer mit wenig Rückmeldung (von Computerfähigen Usern) aus der echten Homöopathen Praxis und wenig Einsicht in die Praxis-Nöte hergestellt. MACREP wieder wird von Homöopathen mit genialen Ideen aber ohne viel Verständnis für den einer Idee zugrundeliegenden Programmier-Aufwand erstellt - sodass völlig unwichtige aber programmiertechnisch sehr aufwendige Features eingebaut wurden, aber rasch (in wenigen Stunden) programmierte Unterstützung wesentlicher Features einfach nicht durchgeführt wird - mit der Begründung des hohen Programmieraufwandes.

Das ewige Problem: der " normale" User ist nicht gut genug im Computer-Handling bewandert, weiss meist nicht was eigentlich möglich und zu erwarten wäre, kennt nicht mal die vorhandenen Features eines Programmes, dadurch bekommen die Programmierer zuwenig Praxisorientierte Rückmeldung.

Langfristig erwarte ich mir jedoch von dieser dynamischen Gruppe  von RADAR noch grosse Impulse 

Arzneimittel-Ergänzung bei MacRep

English Review of RADAR 8.0 - with special comparison to MacRep

I wrote this review in the hope, that the MacRep & Radar Developers would stumble over it and take some of my hints serious. It appears to me that both developer groups have little feedback from programming expierienced homeopaths that can give qualified input regarding improvments for the real, daily praxis. 

I am convinced by my personal expierience as a computer-teacher, that the Computer-Lay will always accept what is present, just nag if something is obviously buggy, but not question conceptual weaknesses - because he, the lay, is happy already to have finally mastered the difficult task of starting the programm. With the exception of Massimo Mangelavory and a few youngsters in his study group every homeopath I met so far belongs to the Computer-lay. Thus " Beta-Testing" by " Teachers" or other expierienced homeopaths will not necessarily reflect shortcomings of programs in daily praxis, so do the average reviews.

As time goes by I will publish here a " detailled wish list" for each of the programms regarding practicability in daily praxis.  This page is to the present date NOT FINISHED (5/02)

In Radar you klick on whatever on the screen and the source appears. 

Multimedia-Integration, the ease to add NOTES to a rubric 
(I put in entire Cases solved via this rubric), 
a great way of making additions and changes to the repertory 

Just try to add 100 remedies in MacReps - Addition Window :

I really admire Roger van Zandvoort having worked so much with such a poor tool (in the Windows environment, I dont know the MacIntosh environment though)

This " Repertory-Remedy-Addition-Dialog" is especially annoying, as it needed hardly 5h of programmers time to become an efficent and usable tool: 

Remedy-Addition-Window: just add the ability to put the mouse aside and work entirely with keyboard shortcuts, change  the poor " MacIntosh" Edit-Line to some more extended Object that also supports " Delete" - not just " Backspace" and closes the Dialog un-wanted with the HOME or END key, 
make sure that an unwanted RETURN-Key during ADDITON of remedies does not automatically cancel 5min work without asking back, 
add the Index to Authors-Numbers in a normal Drop-Down-List, so that not everytime one has to look up the Author Number in some clumsy external program ...., all that would be programmed within 2-4 hours, and legions of homeopaths would save years of time alltogether. Just imagine the time it took to create " Scatter-Graphs" and others that are useless in the daily praxis, while each time I make an addition I get annoyed.

There is such a striking Mismatch between great research abilities, great development into the research tools of MacRep (just look at the various graphics - many of them are great for a seminar, for teaching but completely useless in a real-life daily praxis, 

while the most basic necessities of daily work stays unchanged over the years 

From Version 5.0 to Version 5.6 - the last 5 years - was virtually no advance of the basic features but purely bug removal.

David Warkentin actually invites competitors to reap the market. I am scared to see the MacIntosh way-of-life again 

(this great Computer nowadays has 3-5% of the entire computer market) 

  - and now try the same task in Radar:  add a 100 remedies from different authors to the repertory: what a pleasure in comparison!

BUT: in daily-live-busy-praxis Radar 8.0 still falls seriously short regarding some important things, most of all the striking lack of a easy to use [=fast, easy] NAVIGATION in the repertory.

It was hard to believe that the top-down (always starting from chapter) approach is the only way to go fast to a rubrik in Radar, after having installed the program I was searching for hours in tutorials & help files how to navigate, because I simply couldnt belief that such a superb Repertory-Desktop is so poor to be used!

No Kbd-Shortcut to blend subrubrics, remedies, authors away or back in, 

even more: if you blend out the subrubrics (via the Menu) there is not even a hint in the repertory window that a rubric contains sub-rubrics!!! 

Well - as you are not shown that a rubric does contain some subrubrics it may make sense  that there is no way to go a level deeper into the rubric tree within the normal repertory window !!!!

How could that happen ??!!!! Who is responsible for this?!  Was there ever a feedback from s.o. having to use the program in a praxis that has to take care of more than 3 clients per day ?

To my humble opinion: 

Quite obvious in Radar seems the situation that the programmers dont work in a praxis and have little feedback from homeopaths, that are capable to express necessary features in a way that the programmer understands, 

while - to the contrary - 

in MacRep the Developer does not code (programm).  So the Developer, the high spirited and genious David Warkentin is only partially aware about how much coding time (=money) some little, practical changes need.

As his great visions are very time consuming to program (MacRep is excellent and uncompared as research tool !!!), and David does not hard-code, every little change in the program seems to be evaluated as very time consuming (=money) programming task, just as time consuming as the great research abilities must have been.

There also seems to be a serious difference in the usability of the Mac vs PC variant of MacRep, as my criticism is has been refused by Mac-Users.

Regarding Navigation in Repertory
How easy and elegant - in comparison to Radar - is Repertory-Navigation solved in MacRep, where I can search a rubric on the same level of the repertory (in one chapter) without leaving it, wether I show subrubrics or blend them out.

The present way of Navigation within the Repertory of RADAR is much too clumsy to use the program beside the patient as I can do it with MacRep. 

Furthermore there is a striking absence of keyboard shortcuts in Radar, uncommon for a Windows based development. 

BUT: But these features are rather easy to be added to the program, which, by its principle layout (" object oriented approach" ) is much more advanced and extensible (from my perspective as a programmer) as MacRep. 

Furthermore:
the reaction time of the support is unmatched. Writing an email to the developer (Philippe.Santantonio@archibel.com) on friday evening, I get an competent answer on Saturday morning ! .

Also: Dr. Wolfgang Hettich as sales representant was extremely helpful, and competent, highly recommended.

Urs Maurer über Archibel

Email vom 7. Juni 2002