Sorry, aber das ist so nicht ganz richtig. Wenn wirklich eine „Mindmap“ gemeint ist - also das in weltweiten Marketing gehypte Etwas von Tony Buzan, dann ist diese streng hierarchisch (baumartig) aufgebaut. In einem (Informatik-)Baum gibt es z.B. keine Verbindungen zwischen Geschwisterknoten und es gibt immer eine Wurzel (bzw. „Zentralknoten“). Eine Mindmap ist insofern keinesfalls ausdrucksstärker als jede herkömmliche Gliederung und eine solche hat Papyrus mit der Inhaltsübersicht bereits. Die angebliche Nähe zum menschlichen Gehirn ist absoluter Marketing-Humbug. Es gibt wissenschaftliche, empirische Studien, die zeigen, dass semantische Netze (also assoziative Netze, keine Bäume!) ein valides Modell der menschlichen Kognition darstellen. (*)
Ich kenne Tinderbox - ein interessantes, wenn auch etwas barock anmutendes Programm; etwas teuer und verspielt allerdings. Mein Argument im Kontext von Papyrus: Ja vielleicht ist sowas wie Tinderbox zu sehr karpaltunnelsyndromschädigend, aber es besitzt zumindest einen echten Mehrwert gegenüber den gehypten Tony Buzanesquen „Mindmaps“.
Wenn es NUR um Diagramme, Flowcharts und grafische Netze geht (eigentlich ganz anderes Thema) ist OmniGraffle immer noch das Nonplusultra - Ich finde nicht, dass R.O.M hier unbedingt konkurrieren muss.
Ich stimme Dir auch zu, dass Zettel und Stift in vielen Dingen immer noch ideal ist. Mittlerweile hab ich dieses Medium jedoch auch digital ;). Ich benutze einen „LiveScribe“ Stift, der alles geschriebene automatisch digitalisiert und durchsuchbar macht. Ich kann dann am Mac einfach „Hans Muster“ tippen und finde alle Seiten, auf welchen ich selbiges geschrieben habe. Tolles Teil.
*)
Falls ich den Eindruck erwecken sollte, ich hätte mich mit dem Thema etwas viel befasst… ja ich hab zumindest eine Diplomarbeit dazu geschrieben, ein Jahr dazu im Fachbereich Informatik geforscht, mehrere Prototypen entwickelt, einen Geschäftsplan darüber ersonnen und eine detaillierte Marktanalyse erstellt.
Ich will nicht den kreativen Fluss unterbrechen, aber dieser Thread entfernt sich gerade konsequent von seinem eigentlichen Thema: Wie erarbeite ich mir in Papyrus aus einem wirren Haufen von Notizen eine vernünftige Gliederung?
Für Ideen rund um Mindmap-Funktionalität in Papyrus sollte vielleicht jemand einen Thread bei “noch besser machen” erstellen, dann finden auch Benutzer die Diskussion, die hier bei Gliederung nicht mitlesen.
Den Verdacht, dass Mindmaps in diesem engeren Sinne sich strukturell nicht besonders von Giederungen unterscheiden, hatte ich auch schon, nur: Die graphische Position der Knoten soll doch durchaus ikonisch sein, d.h., was näher beisammen steht, soll systematisch enger zusammen gehören. Unter dieser Voraussetzung gibt es einen bemerkenswerten Unterschied: Wenn der Zentralknoten im Zentrum steht, dann sind der erste und der letzte (nebengeordnete) Tochterknoten wieder benachbart (weil die Tochterknoten eben einen Ring um das Zentrum bilden, während in der herkömmlichen Gliederung der erste und der letzte Punkt maximal voneinander entfernt sind, und das scheint mir jetzt doch ein struktureller Unterschied zu sein!
(Sebastian, du hast recht, das ist sicher auch einen eigenen Thread wert, hat aber eben auch prinzipiell etwas mit dem Gliederungsthema zu tun.)
In der Inhaltsübersicht mit Drag & Drop? Da höre ich das Fluchen schon, wenn man sich dank etwas linkischer Handhabung der Maus beim Anklicken (und ziehen…) einen Text zersemmelt. Da nur mit Tasten oder „Klickflächen“. Nicht alles, was andere machen, ist per Se schlecht und man muss es anders machen …
Was die Gliederei betrifft: mag sein, dass ich da ein Primitivling bin, aber die Zwischenablage ist eine ziemlich coole Funktion. Die Angst vor Verlust treibt mich dabei nicht um (es gibt STRG-Z), ich kann damit stressfrei in der Gegend herumrollen und mir meinen Text zusammenklimpern - vor allem ggf. auch mehrere Hirarchien gleichzeitig. Das rumgeschiebe auf Klemmbretter ist auch nichts anders, nur mit einer Zwischenstation. Ob das wirklich „sicherer“ ist, sei mal dahin gestellt.
Wem buzan´sches Mindmapping zu zentralistisch ist, sei das Programm yED ans Herz gelegt (www.yworks.com). Spricht deutsch, ist kostenlos und kann so ziemlich alles, was sich noch malen lässt. Vor allem kann es per Klick die Struktur unter verschiedenen Aspekten sortieren. Da gäbe es bei „Zettelwirschaft“ nur verknittertes Papier.
Ich benutze das seit geraumer Zeit und bin froh, dass es ein eigenständiges Programm ist, was mein „Strukturieren“ vom „Erstellen“ sauber trennt (sowohl programm-technisch als auch inhaltlich). Allein deshalb würde ich ein solches Werkzeug als Dreingabe von Papyrus nicht nutzen. Aus Beobachtungen (an mir selbst und an Kursteilnehmern als Seminarleiter) weiß ich, dass „Stichpunktlisten“ innerhalb eines Dokuments überwiegend als „Kreativ-Bremse“ wirken, was das Ausarbeiten betrifft. Das liegt (mutmaßlich) daran, dass die Liste als „Vorgabe“ wahrgenommen wird, die es durch „Zwischenstücke“ zu verbinden gilt, statt sie als roten Faden aufzugreifen und „dynamisch“ auszuformulieren. Das funktioniert mit einer „externen, nicht formatkompatiblen“ Liste (zumindest ist das mein Eindruck, s.o.) besser.
Wenn schon innerhalb von Papyrus „Elemente sammeln“, dann bitte die Datenbank nicht vergessen! Die kann Stichworte, Zeit, etc. aufnehmen, das lässt sich per Klick sortieren. Durch eine „Positionsnummer“ (0 10 20 30…) kann man damit leicht strukturieren, umsortiert und eingeschoben wird ggf. mit Zwischennummern (15 25 35). Das entspricht dem Prinzip der Prozess-Steuerung, was sich vorzüglich auf einen Text übertragen lässt. Denn egal was für ein Werkzeug man benutzt: Am Ende muss es so oder so „seriell“ in ein Dokument …
Berechtigter Einwand. S. mein Vorschlag mit der Datenbank (etwas oberhalb … ). Um das etwas konkreter zu beschreiben: Man baut sich eine (beliebige) Datenbank, wichtig ist lediglich ein Feld „Position“ (oder „Absatz“ oder was weiß ich), Typ „Ganzzahl“. Dann fängt man munter an, Datensätze zu produzieren. Die „Position“ bekommt (je nach geplantem Umfang) Nummern mir entsprechend Raum dazwischen (100, 200, 300, … ). So kann man nach Bedarf „auffüllen (150, 225, 317, … ) und bekommt im Handumdrehen eine Reihenfolge, die sich durch Ändern der Nummern neu „gliedern“ lässt.
Das Verfahren ist „hornalt“ und wird z.B. in der Angebotserstellung aus Datenbanken verwendet oder in der Ablaufsteuerung. Da hält es sich sehr hartnäckig, was einen Grund haben muss … .
Nee. Absolute Zustimmung - das gibt Buttons, mit denen man einen selektierten Eintrag hoch- und runterschieben können wird, kein unfallgefährdetes Drag & Drop.
Interessanter Gedanke, den man ggf. für Verbesserungen / Erweiterungen aufgreifen könnte.
Ein “Einschieben” eines Datensatzes zwischen zwei “Gliederungspunkt-Datensätze” könnte man ja programmtechnisch lösen (selbst bei tausender Nummern mag es vorkommen, dass man noch zwischen 1217 und 1218 einen Punkt haben will).
Ob wir hier mal ein Brainstorming machen sollten …?
Wir sind da offen.
Übrigens, zum Thema Mindmapping (oder Clustering oder wie auch immer man das nennen mag und wir es nennen werden, wenn wir derlei mal einbauen) - Papyrus ist hier natürlich prädestiniert, etwas zu können, was andere niemals haben werden - nämlich die HyperOffice-Links vom Text - oder auch Mindmap-Bubbles - auf Datenbank-Einträge.
Das kann ja sonst keiner.
Dazu kann man dann ja wohl auch vielleicht Inhaltsübersicht-Dialog-relevante Einträge in der “Mindmap” haben. Und Querverweis-Dinger.
Das wäre dann in meinen Augen DIE Verknüpfung von allen Möglichkeiten - incl. Datenbank. Wie Ihr merkt, “gärt” dieser Gedanke schon länger in mir. burps
Ich selber habe so schon Datensätze in Datenbanken sortiert. Wenn man nicht Ganzzahl sondern Dezimalzahl nimmt, hat man fast unendlich viele Möglichkeiten, dazwischen einzufügen.
Es wäre hier meiner Meinung nach sinnvoll, wenn Papyrus Papyrus- und *.doc-Texte als Datenbank-Feld haben könnte und sie dann per Report als Dokument zusammengestellt werden könnten (ich hatte das ja bereits vor kurzem in einer PM vorgeschlagen)!
Diese “formatierten Textfelder” oder “… Texte” in einem Dokument zu haben, und über Absätze zu referenzieren, wäre natürlich auch eine Möglichkeit - allerdings vermutlich sehr viel schwerer zu realisieren.
Dann eben als Feldtyp „Text“ dann entscheidet die „Textlänge“ über die Position. Und dann lässt sich zwischen 1217 und 1218 problemlos noch 1217a, 1217b, 1217c,… einbauen.
Was die Datenbank-Pflege betrifft, könnte ein „Last+1“ Wert recht hilfreich sein (gibt´s - afaik - noch nicht), damit man hochzählen kann. Dazu noch ein „Inkrement“ („Last(50)“) für den «Abstand», würde es vereinfachen. «Last(1)» wäre in Datenbanken cool für Rechnungsnummern (aber das nur am Rande).
Eine „Renumber“-Funktionalität („Renumber(50)“) für die Spalte, wieder mit einstellbarem Offset, wäre ggf. die “schaff-Platz”-Lösung, wenn es doch mit Zahlen gehen soll.
Bei einem entsprechenden Report kann man ein Script (ohne Nummern) raushauen. Oder mit Nummern für jurisitische Texte (Absatznummerierung, vorher «Renumber(1)»). Oder die nach Gang sortierte Einkaufsliste für Mutti… - die Möglichkeiten sind sehr vielfältig ohne deshalb neu zu sein (Datenbänker kennen das alles). Evtl. fehlt lediglich die „Bedienungsanleitung“ im Kontext mit einem Textsystem.
Hatte ich auch vermisst, geht aber: Variable definieren, z.B. lfde für Laufende Nummer, und um jeden Datensatz um 1 hochzuzählen, im Rechenfeld des Feldes eingeben:
Da bestätigt sich doch wirklich wieder: “Ihr Papyrus kann mehr!” – Man muss nur drauf kommen.
Aber beide Methoden funktionieren natürlich unterschiedlich, da muss man wissen, was man will: Bei ersterer lassen sich die Werte editieren, bei letzterer sind und bleiben sie fest.
Und einen Absatz später schreibst Du noch, dass dank Undo ein anderes Thema ja kein Problem wäre. Das ist schon ein wenig inkonsequent oder? Mag sein, dass unter Windows die Tree-Widgets so hakelig sind, dass sie nicht bedienbar sind (sind sie nicht - in unserem Produkt arbeiten sie zuverlässig - aber mal einfach angenommen) unter Mac OS X funktionieren sie allerdings absolut zuverlässig und gut.
Achh Herrje! Absolute Ablehnung - das ist doch eine Krücke! Wenn ich einen Abschnitt um ein dutzend Abschnitte verschieben möchte, soll ich mir den Finger an einem blöden Button wund drücken? Wie war das nochmal mit dem Karpaltunnelsyndrom? Zumindest am Mac ist es in Tree-Widgets absolut üblich und nach den Apple Human Interface Guidelines Knoten per Drag & Drop zu sortieren. Zu was liefert Apple das als Standardfunktionalität mit diesen Widgets mit? Damit jemand dann ein paar eigene krude Knöpfe dazuprogrammiert? Ich sehe auch absolut nicht was daran sonderlich unfallgefährdet sein soll?!? Zu was gibt es - wie NoSi ja auch an anderer Stelle betont hat - eine Undo Funktion? Ich erwarte, dass ich eine solche Operation per Undo rückgängig machen kann!
Ich würde ein solches Inhaltsübersicht-Verschiebe-Feature bestenfalls rudimentär nutzen, von daher wäre mir drag & drop ebenfalls lieber - da belasten keine zusätzlichen optischen Elemente die Übersichtlichkeit der Benutzeroberfläche. Buttons hätten natürlich den Vorteil, dass der Benutzer das Feature sofort wahrnimmt, aber ich würde mal sagen, drag & drop in der Inhaltsübersicht versucht eh jeder User früher oder später mal (ich bin da keine Ausnahme), und es ist auch ein positives Aha-Erlebnis, wenn das dann auch wirklich funktioniert.
Und bei anderen Operationen (z.B. verschieben von Textblöcken, Klemmbrett) geht drag & drop in Papyrus ja auch sehr leicht und problemloß von der Hand.
Diesen Einwand verstehe ich nicht ganz. UNDO bedeutet für mich «STRG-Z». Oder «Bearbeiten ►Rückgängig». In wieweit das Inkonsequenz bzgl. einer Ablehnung von Drag&Drop in einem Treeview bedeutet, müsstest Dur mir bitte erläutern. Wenn es „Klickflächen“ gibt, kann man die auch mit Tastenbefehlen belegen und den Dialog mit der Tastatur steuern. Das ist einerseits einer Textverarbeitung (mit den Fingern … ) angemessen und andererseits mit einer erheblich geringeren Fehlerwahrscheinlichkeit behaftet.
Also ich habe eine Wiederholungsrate für die Tastatur eingestellt, die es recht komfortabel macht, Befehle mehrfach aufzurufen. Einfach die Finger liegen lassen ist erheblich bequemer, als mit der Maus Streckenverrenkungen durchzuführen. Es ist nicht so einfach, eine größere Gruppe – das ist ja eines deiner Hauptargumente – gezielt an eine bestimmte Stelle in einer Liste zu verschieben, wenn man die Eigenbewegung mit einer Listenbewegung synchronisieren muss. Eine Lösung sollte immer so angelegt sein, dass eine große Gruppen Menschen ohne Mühe das gesteckte Ziel erreichen kann. Das ist mit dedizierten Knöpfen und/oder Tastenbefehlen jedenfalls eher sicher gestellt als mit Drag&Drop. Schau einfach mal älteren Menschen zu – ich rede jetzt nicht von Computeranfängern, sondern von durchaus versierten Anwendern. Da gibt es schlicht motorische Argumente, warum die Maus nicht unbedingt die beste Lösung darstellt. [Ich kenne darüber hinaus hinreichend junge Leute, die mich manchmal zweifeln lassen, ob die Maus tatsächlich das geeignete Eingabegerät ist – ich schule gelegentlich am Computer.]
Natürlich kann man alles mit Undo rückgängig machen. Ist halt die Frage, warum ich das brauche: Weil eine Funktion so unsicher implementiert ist, dass ich mehrere Anläufe benötige (was dann ebenfalls zu einem Karpaltunnelsyndrom führen kann), oder weil ich mich dazu entscheide, eine planmäßige Operation aufgrund von Umdenken, Neubedenken, was auch immer, zurück zu nehmen.
Dass man das probiert, liegt eher an der Verzweiflung, weil keine Knöpfe da sind. Die tollste Funktion hilft nicht, wenn sie sich nicht erschließt oder nach Jahren zufällig entdeckt wird. Mich macht letzteres eher ärgerlich, weil ich mich frage, warum das nirgends dokumentiert ist.
Drag&Drop muss nicht implementiert werden. Das ist mit markierten Blöcken problemlos möglich, sogar „diskontinuierlich“ mit automatischem Zusammenfügen der Blöcke. Warum eine vorhandene Funktion mit Einschränkungen (diskontinuierliche Markierungen in einer Liste dürften noch nicht das Problem sein – spannend wird das Einfügen … ) auf eine Listendarstellung „gestattelt“ besser sein soll, kann ich noch nicht erkennen. Ich weiß nur, wie viele daran verzweifeln, wenn sie mit Drag&Drop versuchen, in einem TreeView etwas umzusortieren. Denn sobald die Liste anfängt nach oben oder unten zu rollen (und nur das ist echtes Verschieben), wird es eine echte Herausforderung, den gewünschten Platz zu finden und dort „abzuwerfen“ – selbst für versierte Mausanwender.
Danke! Das könnte die Lösung für beliebige Schrittweiten sein. Allerdings ist mir noch nicht klar, wie «lfde» initialisiert wird. Das liegt fraglos an meiner (nahezu) Unkenntnis der Papyrus-Datenbank, denn ich kenne das eher so, dass ich mit Funktionen auf Felder der Datenbank zugreife. Da wäre «Last» das Synonym für „zuletzt eingegeben“ (mySQL z.B. «select last_insert_id() from table» oder um den höchsten Wert rauszukriegen «select max(id) from table»), was bei einer Variable nicht unbedingt zwingend gewährleistet ist. Oder habe ich das was noch nicht verstanden?
Die Inkonsequenz sah ich darin, dass Du die persönliche Abneigung für Copy&Paste bei Anderen mit dem Hinweis auf STRG-Z (Undo) zu entkräften versuchst, dieses jedoch scheinbar bei Deiner persönlichen Abneigung gegen Drag&Drop für nicht beachtenswert findest. :). Bedenke bitte dabei auch, dass Befürworter von Drag&Drop allen Anschein nach ebensowenig Probleme mit „zerschmissenen Bäumen“ haben wie Copy&Paste’er mit flüchtigen Zwischenablagen.
Ich finde Copy&Paste bei reiner Tastaturbedienung sinnvoller. Natürlich kombiniert mit reichhaltigen Tastenkürzel um Wörter, Sätze, Absätze oder ganze Abschnitte zu selektieren. Eine sinnvolle Erweiterung für Papyrus wäre ein Tastaturgesteuertes ein-/ausrücken des markierten Bereichs (in Hinsicht auf die Gliederung). Ob das bei der gegebenen Implementierung so leicht möglich ist, bin ich jedoch nicht so sicher.
Das sehe ich (zumindest für mich gesprochen) anders. Eine Maus ist immerhin noch analog bedienbar. Ich kenne beim Tastenrepeat eigentlich bei sowas eher One-off Fehler (oder auch mehr). Ich kann mir vorstellen, dass das bei entsprechend geschulten Reflexen funktioniert - aber das wäre dann ja wohl keine generelle Alternative zu D&D.
Ich bin nicht sicher - arbeitest Du hin und wieder mit Macs? Bei Windows ist Drag&Drop tatsächlich nicht so durchgängig und stimmig realisiert. Viele UI-Konzepte in Mac OS basieren auf Drag&Drop; dementsprechend ist das System so gestaltet, dass man tatsächlich auch dabei gut navigieren kann. Nachdem ich beruflich sowohl massiv mit Windows als auch mit Mac OS X Benutzern zu tun habe, sehe ich tendenziell tatsächlich, dass Windows-Nutzer häufiger C&P statt D&D nutzen und umgekehrt.
Naja - ich finde dennoch, dass dies eine Sache der Übung/Gewöhnung ist. Unter Mac OS X sind viele Dinge mit D&D sehr Mühelos nutzbar. Ich hoffe, wir können uns zumindest darauf einigen, dass Mac OS X weder als besonders benutzerunfreundliches noch als besonders Mühsames OS gilt. Einer meiner Kunden ist 90 und kommt mit der Bedienung seines Macs hervorragend zurecht. Was ich damit sagen will: Vielleicht liegt es ein wenig am „Ökosystem“, der Art und Weise wie ein System aufgebaut und strukturiert ist und wie alle Konzepte ineinandergreifen. Bei Mac OS ist Drag&Drop ein fundamentaleres Konzept als bei Windows. Ich finde, dass man als Entwickler die Mac-Varianten seiner Anwendung auch so gestalten sollte, wie man es als Mac-User erwartet. Eines der ersten Dinge die ich in der neuen Inhaltsübersicht probierte war etwas mit D&D zu verschieben. Es wirkte wie eine willkürliche Einschränkung, dass es nicht ging.
Usability hat auch etwas mit Erwartungshaltung der Benutzer zu tun. Ein Mac-Benutzer wird eher korrekt funktionierendes Drag&Drop erwarten als ein Windows-User. D&D unter Mac OS ist alles andere als unsicher, sondern ein integraler Bestandteil des Bedienkomforts. Es tut mir weh das sagen zu müssen, aber auch die Konfiguration der Toolbar-Icons (Knöpfchen statt D&D) ist beispielsweise verglichen mit dem unter Mac OS üblichen Verfahren einfach nicht gut. Darüber kann ich hinwegsehen, weil Papyrus dafür an vielen anderen Stellen Dinge besser macht - trotzdem muss ich schon sagen, dass Papyrus sich in Bezug auf Mac-Usability schon gerne noch weiterentwickeln dürfte. *
Jochen
*) Ja Ulli, ich weiß, dass das womöglich als Spartenmarkt auf den ersten Blick nicht interessant erscheinen mag - allerdings gibt es Firmen wie Nisus oder die Redlers, die mit Mac-only Schreibzeugen scheinbar gut genug verdienen um mindestens zu überleben. Ich wage einfach mal zu behaupten, dass die Grundidee und viele Konzepte in Papyrus den Mac-Konkurrenten überlegen sind - die Präsentation und Usability jedoch nicht immer. Wenn an letzteren Themen noch Dinge verbessert werden, dann sehe ich für Papyrus richtig gute Chancen im Mac-Markt.
Man muss Variablen in den Datenbankeigenschaften deklarieren und kann dort auch einen Startwert festlegen sowie zwischendurch den aktuellen Wert manipulieren.
Richtig. Die Lösung mit der Variablen ist eher ein Notbehelf als eine stabile Funktion. Sie versagt z.B. bereits, wenn man mit der Eingabe eines neuen Datensatzes beginnt und dann aus irgendwelchen Gründen die Eingabe abbricht und das Eingabeformular wieder schließt. Die Variable wird nämlich bereits beim Öffnen des Eingabeformulars hochgezählt. In vielen Fällen funktioniert das ganze aber trotzdem hinreichend gut.
Sie wird sogar weiter hochgezählt, wenn auf den “Rettungsring” geklickt wird - das finde ich besonders fatal. Die Rücknahme einer Aktion - hier die Eingabe eines Wertes in ein beliebiges DB-Feld - erzeugt einen neuen Wert. (!)