Dse Anregungen
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Auf dieser Seite können Anregungen für die technische Verbesserung des DseWiki gegeben werden. Für soziale, organisatorische oder strukturelle Vorschläge (wie gehen wir mit dem bestehenden Wiki um) bitte auf WikiAnregungen.


Siehe auch:


Inhaltsverzeichnis dieser Seite
Schnellere Volltextsuche   
ISBN-Nummern stets nach amazon.de verlinken   
Wiki-Link Unterdrückung   
Zeilenwechsel erzwingen   
Eigene Domain   
Zufällige Seite   
diff   
Änderungs-e-Mails   
Archiv   
Referenzen auf Umleitungsseiten   
Editieren   
RecentChanges   
Suchen   
Benachrichtigung   
Schriftgestaltung   
Inhaltliche Wiki-Struktur   
Wiki für lange oder buchähnliche Dokumente   
Editierbare InterWebLink-Seite   
Umlaute in Links   
Rekursive Wirkung fehlt   
Titel beim "Ändern von Seite"   
InterMap Eintrag   
Persönliche Kategorien   
KategorieKkkkkkkkkkk --> zusätzlich SammlungSssssssssss   
Wiki-WYSIWYG-Editor   
Korrektes Deutsch   

Schnellere Volltextsuche    

/SchnellereVolltextsuche

ISBN-Nummern stets nach amazon.de verlinken    

Auf TextFormatierung ist ja erklärt, dass ISBN-Nummern automatisch Amazon-Links bewirken. Interessanterweise wird abhängig von der ISBN-Nummer mal nach amazon.de, mal nach amazon.com verwiesen. Beispiele: ISBN 354042685X, ISBN 0201419750. (Zwischenfrage: Gibt es ISBN-Nummern, die Links auf weitere Amazon-Sites wie amazon.co.uk oder amazon.ca erzeugen?)

Deutschsprachieg ISBN-Nummern (beginnend mit 3) würden auf amazon.com zu nichts führen, deswegen trennt die Software das automatisch auf. Eine weitere Auftrennung erfolgt nicht. Man kann allerdings auch konfigurieren, dass mehrere Links erzeugt werden. Auf Wunsch könnten weitere Buchversande verlinkt werden. -- HelmutLeitner

Jedoch haben amazon.com-ISBN-Verweise seit einiger Zeit einen komischen Effekt: Man landet durch sie nicht auf der Buch-"Detailseite" (wo ja meist ein Bild zu sehen ist), sondern auf der Seite mit "Reviews" zum Buch. Kann man an dem zweiten Link nachvollziehen.

Mmmmh. Da hat sich die Linkverarbeitung von Amazon verändert. Ich sehe auf die Schnelle nicht, wie ich wieder zur eigentlich gewünschten Detailseite komme. Sobald ich das sehe, ändere ich das. -- HelmutLeitner

Deshalb die Anregegung: Ist es vielleicht besser, generell nach amazon.de zu verweisen? "Anderssprachige" ISBN-Nummern scheinen dort zu funktionieren, und man landet eben halt auf der "Detailseite" und nicht bei den "Reviews". Beispiel: http://www.amazon.de/exec/obidos/ISBN=0201419750. -- VolkerGlave

Das wäre eine Möglichkeit. -- HelmutLeitner

Wiki-Link Unterdrückung    

Es gibt Eigennamen und erklärende Texte wo ein Wort wie ein Wiki-Link geschrieben wird, aber nicht ein solcher werden soll. Die Lösung mit <nowiki>LinkMuster</nowiki> ist sehr HTML-Like. Warum nicht das Sonderzeichen "¦" auch vor dem Link nutzen: ¦LinkMuster wäre dann kein Link. Sowas habe ich in anderen Wikis gesehen, allerdings mit Ausrufezeichen. -DerKarlos-

Ich kenne es vom CoForum, dort glaube ich mit ^. Ich geb zu, dass das was für sich hat. Derzeit gibt es nur den senkrechten Strich CharacterCode0166, der eine ähnliche Funktion erfüllt, allerdings optisch nicht so elegant wirkt. Ich habe bei diesen Markups immer bedenken, dass sie irgendwann im Programmcode zuschlagen und Verwirrung stiften. -- HelmutLeitner

Nur Mut!

Zeilenwechsel erzwingen    

Einen hab' ich noch: Statt mit HTML-Tag <br> sieht man oft drei Minus- oder Prozentzeichen am "Qellcode"-Zeilenende um gezielt eine neue Zeile zu beginnen. Finde ich handlich. -DerKarlos-

Das habe ich noch nie gesehen. Wenn, dann solle man solche Dinge standardisieren - sonst werden die Benutzer bald unter einem Markup-Wirrwarr leiden. -- HelmutLeitner

Die Wikies mutieren derzeit munter 'drauflos. Standards kommen da nur durch Evolution. Deine Art [syntax] ist auch einmalig! %%% habe ich öfter gesehen als --- vorkommen. Oft wird es auch nicht beschrieben, geht aber. Www-Tags sind dagegen oft verpöhnt. Alles Geschmackssache -karlos-

Eigene Domain    

Die aktuelle Web-Adresse des DseWiki - http://www.wikiservice.at/dse/wiki.cgi - ist irgendwie nicht besonders einprägsam. Jedesmal, wenn ich keinen Zugriff auf meine BookMarks? habe, benutze ich Google, um das Wiki zu finden. Wäre es nicht schön, einfach www.dsewiki.de tippen zu können? -- IljaPreuß

Ja, eine eigene Domäne ist heutzutage eigentlich fast schon eine Selbstverständlichkeit, oder? Ich habe nur Probleme mit der Anmeldung deutscher Domänen, weil ich über keine deutsche Geschäftsadresse / Admin-C verfüge. -- HelmutLeitner

Mhh, wäre dsewiki.org einfacher für Dich? .at wäre ja auch keine Katastrophe... ;->

dsewiki.org ist einfacher und wäre vermutlich die beste Lösung, aber was bedeutet DseWikiOrg? -- hl

Wäre dse.wikiweb.at technich möglich? -karlos-

Zufällige Seite    

Um einfach so zu stöbern, während man auf dem Compiler wartet, wäre ein Link, der immer auf eine andere zufällig ausgewählte Seite zeigt, eine sehr nettes Feature.

Ist ja schon drin, siehe ZufallsSeite. Sorry, habe ich gar nicht gemerkt.

diff    

Ich lese nun seit ein paar Wochen hier regelmäßig die RecentChanges und versuche, den Diskussionen zu folgen (und, wenn möglich, selbst dran teilzunehmen). Doch dies fällt mir recht schwer, aber vielleicht mache ich auch etwas falsch - naja, les selbst: Wenn ich in die RecentChanges schaue, so stehen dort neben den Themen die diff-Links. Am Beispiel FrameworkVeröffentlichung von heute versuche ich nun, die in den letzten Stunden sich ergebenen Diskussionen zu verfolgen. In diesem Fall hast Du um 7:32h etwas geändert, Ilja um 10:37h. Wenn ich den diff-Link neben Deinem Eintrag um 7:32h anwähle, so erhalte ich immer die letzten Änderungen, also diejenigen, die Ilja gemacht hat. Weiterhin ergibt sich des öfteren das Phänomen, daß ein Autor einen Eintrag schreibt und ihn sichert, beim anschließenden Durchschauen aber noch einen Punkt oder seine Signatur ergänzt. Wenn ich dann in die RecentChanges schaue, steht dort, daß der Autor 2 Änderungen gemacht hat, und wenn ich mir das Diff anschaue, sehe ich nur die Änderung, daß ein Punkt oder eine Signatur hinzugekommen ist, nicht aber den eigentlichen Inhalt von der ersten Änderung.

Falls ich da nun nicht völlig auf dem Holzweg bin, hätte ich zwei Änderungswünsche an Dich:

  1. Wenn ein Leser in den RecentChanges neben einen Eintrag x zum Zeitpunkt a auf ein Diff klickt, so erhält er den Vergleich zwischen dem Dokument x vor dem Zeitpunkt a und nach dem Zeitpunkt a. Der Leser kann sich so die RecentChanges "entlang hangeln" und die letzten Diskussionen besser verfolgen.
  2. Wenn ein Autor zu einem Zeitpunkt a einen Eintrag x des Wikis editiert und zu einem späteren Zeitpunkt b diesen Eintrag nochmals editiert und wenn zwischen den Zeitpunkten a und b kein weiterer Autor den Eintrag x editiert, so wird dies in den RecentChanges als eine einzige Änderung geführt. Weiterhin werden in solch einem Falle beim Klick auf den Diff-Link neben dem Eintrag x in den RecentChanges diese beiden Änderungen als eine einzige gezeigt.
Was hältst Du davon? Bernd --bs

Deine diff-Vorschläge gefallen mir sehr gut, und als Vielbenutzer des Wiki stören mich diese Dinge oft genau so wie dich. Sie werden allerdings selten reklamiert und bedeuten einen relativ hohen Aufwand, so dass sie es noch nie ganz nach oben in der Prioritätenliste geschafft haben. Aber ich denke, es wird Zeit (dein Feedback motiviert), diese Mängel zu beseitigen. -- hl

Zu den diff-Vorschlägen: zur weiteren Motivation: ich lese gerne in diesem Wiki, vergeude aber wirklich viel Zeit bei der Diskussionsverfolgung, die Beiträge auseinander zu halten. Es wird nicht jeder Beitrag signiert und teilweise erfolgen Zeilenumbrüche etwas unglücklich. Bei mehr als zwei Änderungen oder über mehrere Seiten lange Diskussionen muss ich die Suchen-Funktion des Browsers zu Hilfe nehmen, wenn ich nicht aktiv an der Diskussion teilnehme (in letzterem Fall präge ich die Struktur mit und kann mich leichter orientieren, was nicht bedeutet, daß ich mich leicht orientieren kann). Ich wette, nicht nur mir geht das so, sondern Vielleser/-schreiber wie ip, hs, vgl sehen das ähnlich...! -- Bernd

Logo, das Feature vermisse ich natürlich auch. -- vgl

@Bernd: Tip: Schau ins Archiv, dort kann man dann die einzelnen diffs nachvollziehen und auch längere Diskussionen mit häufig wechselnden Autoren werden dabei verständlich. -- ds?

Ja, nutze ich seit kurzem auch. Allerdings ist das doch eher umständlich und oben vorgeschlagene Änderung dürfte es doch erheblich einfacher machen (Usability und so). -- bs

Das Anmerkungen durch Einrücken gekenzeichnet werden ist ja schon mal eine gute Tradition. Neues findet man so aber nicht automatisch. Immer Datum und Uhrzeit dranschreiben währe Umständlich, könnte aber mit einem "Wiki-Tak" [Neu] automatisiert werden. Hier würde außnamsweise mal automatisch der Qellcode geändert bzw. das Datum angehängt, wenn noch keine aktuelle Ziffer hinter [Neu] folgt! Beispiel: [Neu]14.4 14:28 - Nach x Tagen/Wochen kann man das dann wieder automatisch rausfallen lassen.

Änderungs-e-Mails    

Noch eine kleine Frage: wen erreicht eine Änderungs-e-Mail, wenn ich auf Änderungs-e-Mail verschicken beim Ändern eines Eintrages klicke? -- bs

Die Änderungs-e-Mails werden an Teilnehmer verschickt, die sich unter "Einstellungen" dafür eingetragen haben. Dies ist ein UseMod-Erbstück, das - ehrlich gesagt - in dieser Form nur wenig benutzt wird und fragwürdigen Nutzen bringt. Es wäre einerseits notwendig, dass Teilnehmer bestimmte Seiten oder Kategorien aktiv auswählen können (ohne von der Kooperation des Autors abhängig zu sein). Andererseits wäre eine flexible Akkumulation der Änderungen nötig (damit nicht 20 Änderungen als 20 getrennte Mails kommen).

Was ich gut finden würde (Achtung: weiterer Verbesserungsvorschlag :-) ), wäre, wenn ich auf einer Homepage eines WikiBesuchers?, wenn ich ihm eine Nachricht hinterlassen habe, ihm eine Email automatisch zukommen lassen könnte. Natürlich müßte er, der Homepagebesitzer, daß vorher zugelassen haben (in seinen Einstellungen?). Was ich nämlich mehrmals erlebt habe: Leser mit eigener Homepage kommen nicht regelmäßig vorbei und bekommen nicht mit, wenn Nachrichten auf ihrer Homepage für sie hinterlassen worden sind. Natürlich könnte ich eine Email direkt an den Homepagebesitzer schicken (wenn ich denn die Adresse habe), aber vielleicht möchte ich ja gerade zum Nutzen der anderen Wikiteilnehmer eine Diskussion öffentlich austragen. Btw: diese Möglichkeit, Emailbenachrichtigung für Nachrichten auf der eigenen Homepage, würde mit ziemlicher Sicherheit die Diskussion im Wiki ankurbeln. Spekulation: vielen ist es zu aufwändig, regelmäßig vorbeizuschauen und würden nur dann kommen, wenn es sie interessiert. Was könnte sie mehr interessieren als eine Nachricht an sie persönlich? ;-)

Archiv    

Ein RCS-Archiv, das jeweils beim Wechsel des Autors eine Version archiviert läuft seit einiger Zeit versuchsweise mit und ist jetzt für jeden Benutzer, der einen Namen unter "Einstellungen" eingetragen hat, zugänglich (unter Zusatzfunktionen, am Fuße der Seiten). [25.12.2001] -- HelmutLeitner

Coole Sache. Vorallem bei häufigen Änderungen sehr nützlich um zu sehen, was alles verändert wurde.

Wenn Dir mal eine Stunde zwischendurch übrigbleibt, wäre es vielleicht interessant darüber nachzudenken das auf cvs umzustellen. Damit könnte man das "Mergen" bei Konflikten vereinfachen, anonymen cvs Zugriff auf das gesamte Archiv, vielleicht sogar die Möglichkeit für "Registrierte" commits zu machen, das Mitspeichern von Zusammenfassungen, ... --ds

Ja, ein cvs-mergendes Wiki wäre eine echte Innovation, so etwas gibt es in der WikiWelt noch nicht. Allerdings mit einem Stündchen ist das nicht abgetan. Derzeit kommen die Änderungen nämlich gefiltert in das Archiv (erst wenn sichergestellt ist, dass ein Autorenwechsel stattgefunden hat), d. h. es gibt 2 Hauptversionen einer Seite, die konventionell gespeichert werden, bevor das rcs-Archiv beteiligt wird (und das ist auch eine feine Sache, obwohl es sich mehr zufällig aus der Verschmelzung zweier unterschiedlicher Systeme ergeben hat).

Ich glaube nicht, daß es wünschenswert wäre alle Änderungen einzeln als Revisionen zu haben.

Das Mitspeichern von Zusammenfassungen ist eine andere Geschichte, die damit wenig zu tun hat. Derzeit existieren sie nur im RecentChanges-Logfile und nicht als Eigenschaft einer Bearbeitungsversion, was sich aber relativ leicht ändern ließe (Seiteneigenschaften können wiederum leicht in die Kommentare der rcs-Revision verpackt werden). -- hl

Ad mergen: Schau dir mal diff3(1) an. Dafür braucht man gar kein cvs.

Danke für den Tipp. -- hl

Ad eine Stunde: eine Stunde nachdenken. Nicht eine Stunde programmieren.

Referenzen auf Umleitungsseiten    

Für die konsistente Behandlung von Umleitungsseiten wäre es wünschenswert, wenn beim Klicken auf den Titel der Zielseite der Umlenkung auch alle Seiten aufgelistet würden, auf denen die Umleitungsseite referiert wird, z.B für KlausGünther auch die Seiten wo ich kurz mit --kg signiert habe.

Ja, das finde ich auch. Vermutlich wird das aber ein bisschen dauern, das zu realisieren. Gib mir 1-2 Wochen. -- hl

Work-around: Such-Link am Fuß der Seite. -- her

Editieren    

Es wäre toll, wenn es zusätzlich zu den Schaltflächen Speichern und Vorschau noch weitere Werkzeuge geben würde. Ein sehr nützliches Werkzeug wäre ein Menü zum Anhängen von Kategorien an eine Seite. Es ist sonst ziemlich schwierig, sich die Kategorien zu merken.

Workaround: ein zusätzliches Browser-Fenster öffnen, in dem man auf Kategorien klickt und dann die Kategorien per Cut'n'Paste übernehmen. --PeterFunk

RecentChanges    

Siehe auch ÄnderungOderKorrekturDiskussion


HelmutSchellong hat gerade mehrmals nacheinander Änderungen an OpenUnix8 ausgeführt und dabei jeweils einen informativen Kommentar über die Art der Änderung eingetragen. In RecentChanges sieht man natürlich immer nur den letzten Kommentar. Bei der letzten Änderung hat er dann keinen Kommmentar mehr eingegeben, also sind sie jetzt alle weg. Schade, denn sie wären ja alle weiterhin nützlich.

Es ist mir auch schon öfter so gegangen. Wenn ich einen Kommentar eingegeben habe und dann die Seite nochmal ändere, dann muss ich den Kommentar nochmal eingeben, damit er nicht verschwindet.

Deshalb ein Wunsch: Wenn jemand eine Seite editiert, die er an diesem Tag schonmal editiert hat, dann sollte in dem Feld, in den der Kommentar eingetragen wird, der Kommentar vom letzten Mal vorgegen werden, falls vorhanden. Man kann ihn dann - je nach Situation - lassen, oder noch etwas dazu schreiben, oder ihn rauslöschen. -- her

Ja, ich seh ein, dass ich da etwas verbessern muss. Ich bin mir aber noch nicht sicher, wie. RecentChanges wird aus einem Logfile erzeugt, der je Änderung einen Zeileneintrag enthält. Das zu lesen und aufzuarbeiten ist neben der Volltextsuche die aufwendigste Operation im Wiki. Ich zögere deshalb beim Editieren die korrespondierende Zusammenfassung aus dem "rclog" zu holen. Diese Zusammenfassung wird in vielen Fällen auch nichts mit dem neuen Beitrag zu tun haben. Vielleicht wäre es auch ausreichend, aus der Abfolge der Änderungen (mit u.U. wechselnden oder fehlenden Kommentaren) die letzte eingegebene Zusammenfassung anzuzeigen? Das wäre einfacher. -- hl

Du meinst, wenn einmal eine Zusammenfassung eingegeben wurde, dann erscheint sie solange weiter, bis eine andere eingegeben wird, wobei Autoren nicht die Möglichkeit haben sie zu editieren, sondern nur sie komplett neu einzugeben?

Suchen    

Eine erweiterte Suche wie in WardsWiki? -- HelmutEnckRadana

Was meinst du damit? WardsWiki besitzt eine Suche im Titel, eine Suche im Text (nur Einzelworte, inverse index)? Oder meinst du ein spezielles Formular mit den SuchFunktionen? --hl

Die Seite SuchFunktionen hatte ich noch gar nicht entdeckt, es gibt ja kaum Links dahin. Das geht schon in die Richtung, die ich meinte. Ich habe mich auf die FindPage? im c2-Wiki bezogen. Das Schöne dort ist, dass auf jeder Wiki-Seite unten ein Link zur FindPage? ist. Es geht mir vorwiegend darum, Suchbegriffe mit AND verknüpfen zu können. Bin eigentlich ein Fan von Regular Expressions, habe sie aber vorwiegend vor längerer Zeit (ca. 10 Jahre her) in vi, awk und sed intensiv verwendet, und später in Perl nur recht wenig (noch Perl4). Kann in Perl ein '.' auch für ein '\n' stehen? Gibt es ein Zeichen für AND? Oder muss ich sowas schreiben: /(wort1.*wort2)|(wort2.*wort1)/ ?

Es ist sicher besser, solche Funktionen durch Formularoptionen zu realisieren, weil sonst nur weniger Benutzer damit zurecht kommen. Ich habs auf meine Liste gesetzt, kann aber nicht garantieren, wie schnell ich es realisieren kann. -- hl

In Perl matcht '.' normalerweise nicht mit '\n' es sei denn, du verwendest die Option "/s". Inline, also im Suchtext muss man das als "(?s)" schreiben. Also vermutlich "(?s)(wort1.*wort2)|(wort2.*wort1)". -- hl


Ein Button zum Starten der Suche würde Wechsel zwischen Maus und Tastatur einsparen. (Eintippen tut man zwar auch mit der Tastatur, aber Anklicken der Checkboxen mit der Maus - typischerweise nach dem Eintippen und vor dem Starten.) -- her

Benachrichtigung    

Verbesserungen an der EmailNotifikation.

Schriftgestaltung    

Das Attribut Größe könnte auch nützlich sein im Element 'Marker', oder vielleicht ein Attribut 'Hintergrund' im Element 'Schrift'. -- her

Da muss ich noch nachdenken. Im Grunde würden die Elemente dann zusammenwachsen. Bei 'Schrift' spricht aber nichts gegen die Erweiterung. -- hl

Es bliebe noch der Unterschied, dass Marker ein Inline-Format ist, während Überschrift ein Block-Format ist und immer so breit wie die Seite. Auch Attribut Luft in Marker könnte nützlich sein, ich befürchte allerdings, dass sich das gar nicht zuverlässig in HTML übersetzen lässt. Wenn man Marker als Überschriften verwenden will, könnte man stattdessen auch eine Tabelle mit einer Zelle verwenden, wenn man dort die Schriftgrösse einstellen könnte.

Attribut Hintergrund in Element Schrift bräuchte man dann nur noch, wenn man entweder farbige Schrift auf farbigem Hintergrund möchte, oder wenn 'Schrift' das universellste Inline-Element sein soll. Statt farbiger Schrift auf farbigem Hintergrund würde ich eher vorschlagen, dass die Schriftfarbe bei 'Überschrift' und 'Marker' automatisch in weiss geändert wird, wenn die Hintergrundfarbe zu dunkel für schwarze Schrift ist.

In Tabellen wäre es natürlich schon schön, wenn man pro Spalte und/oder pro Zeile wahlweise die Hintergrundfarbe oder die Textfarbe einstellen könnte... Vielleicht wird es ja doch mal möglich sein, Zeichenformate innerhalb von Blockformaten zu verwenden?

Prinzipiell bin ich schon dafür, dass es möglichst wenige unterschiedliche Wege geben sollte, den gleichen Effekt zu erzielen. -- her

Inhaltliche Wiki-Struktur    

Die Struktur der StartSeite und die Kategorien sind teilweise redundant. Zumindest streben beide Mechanismen eigentlich das gleiche Ziel an: Eine Gliederung in Themenkomplexe. Wahrscheinlich macht es Sinn, beides zusammen zu führen, so dass das Inhaltsverzeichnis auf der StartSeite nur noch eine thematisch geordnete und kommentierte Kategorienliste ist. --PeterFunk

Du hast sicher Recht, aber die Redundanz bietet einem verschiedene Zugänge. Normalerweise sind WikiWebs eher chaotisch und neue Benutzer brauchen oft ziemlich lange, bis sie sich zurechtfinden. Deswegen habe ich ziemlich viel für die Strukturierung getan. Vielleicht wirkt das dadurch im Moment noch ein bisschen "überstrukturiert". -- HelmutLeitner

Es gibt viele verschiedene Möglichkeiten Informationen zu strukturieren, ganz besonders, wenn man versucht sich aus Gründen der übersichtlichen Darstellung an eine reine Baumstruktur halten will. Ich denke, es kann sehr hilfreich für das Auffinden von Informationen sein, wenn mehr als eine solche Struktur zur Verfügung steht.

Das System der Kategorien ist immer das aktuelle Ergebnis vieler kleiner Änderungen vieler Benutzer, kann leicht an einem Mangel an Konsistenz leiden und ist immer unvollständig. Die Struktur auf der Startseite sollte ein in sich konsistent strukturiertes Inhaltsverzeichnis sein, es muss nicht jede kleine Unterkategorie anzeigen, und ich denke, es sollte nicht nur den ist-Zustand darstellen, sondern auch noch nicht vorhandene, aber erwünschte Inhalte berücksichtigen.

Was ich mir an zusätzlicher Funktionalität wünschen würde ist eine Möglichkeit, sich die partielle Struktur anzeigen zu lassen, die durch die Über-/Unterkategorie-Beziehung zwischen den Kategorien entsteht. Bei intensiverer Verwendung dieses Features könnte sogar ein einigermassen kompletter Baum generiert werden (vielleicht in einem Batch-Lauf jede Nacht). -- HelmutEnckRadana


[Neues] ist sehr gut --ReiniUrban

Die Antworten und die Diskussion dazu wurde auf BeiträgeNeuBenennen? verschoben.


Hi Helmut, die Sache gefällt mir eigentlich recht gut. Allerdings drei Fragen habe ich (technisch und weniger technisch): --HardyGriech

Mit zum Grundgedanken des Wiki gehört es wohl auch, dass eine Seite eigentlich NIE gelöscht wird. Das Wiki gleicht eher einem Gedankenstrom in dem man über die Seiten oder über die RecentChanges (hier wohl neues) navigiert. Eine uninteressante Seite ist dann einfach nicht mehr verlinkt oder im Strom der Änderungen nach hinten gewandert. --RalfMueller


Gibt es die Möglichkeit, bei Links auf Web-Seiten einen erläuternden Text darüberzulegen, der den Link an sich verdeckt? --RalfEbert

So etwas vielleicht? -- HelmutLeitner


Gibt es eine Möglichkeit, das System bei Kollisionen während der Bearbeitung von Seiten dazu zu überreden, im oberen Fenster die Änderungen des vorherigen Autors farblich zu markieren? Es wird sonst etwas unübersichtlich, jedesmal danach den Text komplett durchzulesen, um herauszufinden, was vorher geändert wurde (bei bis zu fünf Kollisionen hintereinander ist das ab und an etwas nervig ...) --rae

Das Edit-Fenster des Browsers ist leider so wie es ist. Vielleicht gäbe es eine Chance, es als Text anzuzeigen. Ich muss ein bisschen darüber nachdenken. --hl

Unsere Kooperation in ProgrammierStilAlpha ist ein bisschen Extrem für das Wiki-System. Ich mach es jetzt so, dass ich immer nur einen Gedanken einfüge und dann speichere (kein Vorschau mit längerer Bearbeitungszeit). Auf diese Weise brauche ich nur einen Absatz kopieren, falls es zu einer Kollision kommt. Wir könnten auch vereinbaren, dass wir nicht zu rasch antworten (z. B. frühestens 15 Minuten nach der letzen Änderung des Partners). Dann hätte jeder diese Zeit um seine Gedanken oder Änderungen fortzusetzen und zu speichern und seinen Zeitraum zu verlängern. --hl

Ok --- eine ähnliche Regelung hatte ich mir eh bereits vorgenommen. --rae

Das würde das Problem nicht lösen. Sobald drei oder mehr diskutieren, wird einer eine Änderung veröffentlichen und die zwei anderen warten dann genau 15 Minuten, so daß einer davon garantiert eine Änderungskollision bekommt. -- MichaelButscher

Bestimm du bitte das Intervall. --hl

Das erinnert mich an CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Ein Protokoll aus der Netzwerktechnik: Man wartet auf einem Shared Medium solange, bis niemand anderer sendet (CSMA). Dann sendet man selbst. Kommt es während dem Senden zu einer Kollision (CD), dann wartet man eine zufällige(!) Zeitspanne ab und beginnt von vorne mit dem CSMA. --DavidSchmitt

Im Prinzip hat sich das Problem bereits erledigt, da heute meine Familie wieder vom Urlaub zurückkommt --- und da habe ich naturgemäß weniger Zeit. Im Moment schaue ich so einmal die Stunde nach, ob sich was getan hat. --rae

Wiki für lange oder buchähnliche Dokumente    

Ohne dass ich jetzt dieses einfache Anliegen [der Seitengröße] verkomplizieren will: Dahinter steckt natürlich auch noch der Bedarf, bei einem anwachsenden Thema - wenn Möglichkeiten des Refaktoring ausgeschöpft sind - das sich auf mehrere oder viele Seiten erstreckt, trotzdem noch die Gliederungs- und Navigationsmöglichkeiten zu erhalten. Ich denke da an buchartige Strukturen, die in einer Art Inhaltsplan definiert werden können, aber als Inhaltsverzeichnis über alle beteiligten WikiSeiten? dargestellt werden und die man auch in eine Gesamtseite oder in ein Austauschformat linearisieren kann. Vermutlich wäre es notwendig Seitennamen und tatsächliche Kapitelüberschriften zu trennen. Vermutlich wäre auch eine optionale Abtrennung von Notizen oder Diskussionen bei der Linearisierung sinnvoll. Eine effiziente Implementierung soll natürlich auch gegegeben sein. Wenn ihr Ideen dazu habt, wäre ich euch sehr dankbar. -- hl

Editierbare InterWebLink-Seite    

Auch vorgeschlagen wurde, dass man mögliche InterWebLinks für jeden editierbar macht. Dies wird jedoch von den meisten als zu gefährlich empfunden (siehe zum Beispiel UseMod:InterWiki, fast ganz unten). Zudem kann man sich ja auf auf InterWebLinks/Erweiterungsvorschläge eh melden, so dass das nicht nötig erscheint.

Umlaute in Links    

Sollte man vermeiden. Es ist problematisch, zumindest vorübergehend.
Ich habe TopFünfzig in den bookmarks.html. Das wurde beim Import umgewandelt. Ich korrigierte es. Dann wurde es beim mozilla-Start immer umgewandelt, aber anders als beim Import. Dann habe ich den charset=xxx der html-Datei geändert - jetzt geht es.
Zu Anfang konnte ich gar keine Umlaute schreiben, weil Compose-Key nicht ging.

Ich habe auf einem RedHatLinux System, auf dem eine UTF-8 Locale eingestellt war ähnliche Probleme gehabt. Die effizienteste Methode zur Lösung, die ich gefunden habe, war es einfach alle Sonderzeichen zu URL-enkodieren (also mit %XX). Vielleicht hilft Dir das weiter?

Ich hab das Problem ja gelöst. Mein Anliegen ist, daß man's erst gar nicht lösen muß.

Ich versteh das Problem nicht ganz. Im Wiki werden alle Umlaute in Links ohnehin mit %xx codiert, sodass, wenn jemand ein Bookmark setzt, das funktionieren sollte. Nur wenn man es manuell eingibt, das kann man auf dieses Problem stoßen (mein erster Kontakt damit war übrigens das WinBridge?-Programm, das mit den Umlauten beim durchleiten nicht fertig wird). Oder anders ausgedrückt: was könnte ich von der Wiki-Software-Seite her verbessern?-- hl

Der Mozilla hatte es aber nicht %xx-kodiert, sondern etwa TopFiYqnfzig? usw. und so an wiki.cgi?... übergeben.

Rekursive Wirkung fehlt    

 [[Link][Url=...] [[Gelb]ttt] ]
Geht z. B. nicht.

Helmut, das Problem ist mir bewußt. Zwar ist das Problem der rekursiven Verwendung im Prinzip gelöst, jedoch ist diese nur für bestimmte Elemente "freigeschaltet" (z. B. für SupportWiki:CdmlText, SupportWiki:CdmlBild und SupportWiki:CdmlCode):

Das ist ein Rekursivitäts-Test:

TEST 
 
 
 
SpracheUser
C++3
Java4
C#1
Ende des Tests.

Ich muss mir erst ein effizientes System für eine selektive Freischaltung überlegen (oben wär's nicht gut, wenn auch eine SupportWiki:CdmlTabelle in den Link gelegt werden könnte). -- hl

Es ist kein brennendes Problem. Ich versuchte das bei GNU-grub mit dem Link FreeBSD/grub.

Titel beim "Ändern von Seite"    

Irgendwie hat sich heute bei Ändern von Seite: DseAnregungen der Geist meiner Deutschprofessorin gewehrt. Klingt vielleicht Ändern der Seite "DseAnregungen" besser?

InterMap Eintrag    

Könnte man von MeatBall:InterMapTxt den Acronym Eintrag kopieren? Damit würde man sich Seiten wie ETA sparen.

David, danke für den Hinweis. Ich hab' den Link ergänzt. Ob es deswegen Seiten überflüssig macht, weiß ich nicht. -- HelmutLeitner

Persönliche Kategorien    

Siehe /KategorieBenutzerName

KategorieKkkkkkkkkkk? --> zusätzlich SammlungSssssssssss?    

Ich denke, das wäre sehr einfach zu implementieren.
Neben dem sensitiven Wort »Kategorie« gibt es dann ein weiteres: »Sammlung« beispielsweise. Gleichzeitig ist das ein neues Organisationsmittel im Wiki. --hs

Ein paar Gedanken: Es wäre tatsächlich trivial zu implementieren, ich vermute mal, dass es sogar konfigurierbar wäre. Ich bin aber vom Sinn der Sache nicht überzeugt. U. a. habe ich im WardsWiki an einem ziemlich mühsamen Prozess mitgewirkt, ein dort bestehendes 2. Ordnungssystem durch Refaktorieren zu beseitigen. Ob dort Kategorie... oder Sammlung... oder KategorieSammlung... steht, für mich ist das strukturell das gleiche. In den meisten Wikis, die ich derzeit anlege, verwenden wir den Ordner-Begriff statt der Kategorie (siehe z. B. BücherWiki). Das hat mehrere Vorteile, aber das lass ich jetzt weg. In vorliegenden Fall wäre allerdings ein "OrdnerSchellong" plausibler als eine "KategorieSchellong", denn einen Ordner kann man (bildhaft betrachtet) zu jedem Thema anlegen und ins Regal stellen. Eine Kategorie hat so etwas semantisch - philosophisch - abstraktes - endgültiges an sich, so dass man nicht weiß, ob es eine "KategorieBenutzerName" überhaupt gedanklich geben kann. Es würde sich auch anbieten, eine Ordner-Ökonomie anzudenken (wie in einem Regal, wo man auch nicht wegen 3 Zettel einen eigenen Ordner anlegt, es sei denn man ist sich sicher, dass noch viel nachkommt), wo sich entweder bei einer ausreichenden Allgemeinheit des Themas (KategorieDesign) oder bei entsprechendem Umfang (OrdnerSchellong) ein Ordner "rentiert". -- HelmutLeitner


Wiki-WYSIWYG-Editor    

Ich habe mir eben das Demo vom Sourceforge-Projekt des Monats, siehe http://www.egroupware.org, angesehen. Darin gibt es einen Wiki, der einen in Javascript geschriebenen WYSIWIG-Editor verwendet, siehe http://sourceforge.net/projects/itools-htmlarea/. Nicht, dass ich das für den DSE-Wiki vorschlagen wollte, nur mal interessant anzuschauen.

eGroupWare nutzt das Sourceforgeprojekt htmlArea als WYSIWYG-Editor. Allerdings habe ich nicht herausfinden können, ob und wenn ja, wie man welches Wikimarkup dort verwenden kann - wäre IMHO kein Wiki ohne ein solches Markup. --bs

Nichts wäre mir lieber als ein sauberes WYSIWYG, ich sehe aber in absehbarer Zeit keine einigermaßen saubere Lösungsmöglichkeit. Wenn man es mit Javascript+HTML macht, dann muss man aktiviertes Javascript verlangen und hat mit allen HTML-Browser-Inkompatibilitäten zu tun. Wenn man es in Java macht, dann mit Java-Versionsproblemen, der Reproduktion des HTML-Renderings und - bei vielfältigeren Funktionen - Ladezeitproblemen. Ich werde mir aber wie bisher schon alles anschauen, was so auftaucht. Ohne besseres CSS / bessere Browser (interaktives HTML-Objekt-Modell) wird sich wenig bewegen. -- HelmutLeitner

Zustimmung, insbes. bzgl. der Technikbewertung. So war der Hinweis auch gedacht. :-) -- SDö

Ein Zwitter zwischen Wiki und Html-Edit wäre möglich, wenn ein Tool existiert, dass HTML in Wiki-Source und umgekehrt reversibel transformieren kann. Ansätze dazu: http://www.aaronsw.com/2002/html2text/ --ThomasKalka

Aus Wiki-Syntax andere Formate zu bauen, dürfte nicht so sehr das Problem sein. Reversibel kann der Prozess nur sein, wenn das Exportformat eine reichere Syntax hat. BTW: Ein Wiki mit schicken Exportfunktionen ist Instiki ( http://www.instiki.org/show/HomePage), der kann sogar PDF (siehe z. B. http://www.ntecs.de/wiki/rubyde/export/).


Korrektes Deutsch    

Ist es möglich, auf dieser Seite in Titeln und Verweisen korrektes Deutsch zu verwenden? Es heißt beispielsweise Softwareentwickler, nicht Software Entwickler, und Startseite, nicht Start Seite. Mir ist schon klar dass die Verweisform mit den zusammengezogenen Wörtern etwas bequemer ist, aber es ist halt falsch, und nach meinem Empfinden auch sehr häßlich. Es besteht auch die Gefahr, dass sich bei häufigem Lesen dadurch ein schlechter und anglizismenfreudiger Schreibstil einschleicht. Das Getrenntschreiben von eigentlich zusammengehörenden Wörtern nimmt nach meiner Beobachtung in der letzten Zeit allgemein stark zu, vermutlich als Folge von vermehrter Beschäftigung mit dem Englischen und schlechten Deutschkenntnissen. Man sollte diesen Trend daher nicht noch unterstützen.

Ich möchte daher folgendes empfehlen: die Form mit den Großbuchstaben, die zur Getrenntschreibung von Wörtern im Titel führt, sollte so verwendet werden, wie es der deutschen Grammatik entspricht, also ObjektorientierteProgrammierung? statt ObjektOrientierteProgrammierung. Bei Titeln, die aus einem einzelnen Wort bestehen, sollte die Syntax mit den geschweiften Klammern verwendet werden, auch wenn es ein paar Tastendrücke mehr sind, wie beispielsweise Softwareentwickler? statt SoftwareEntwickler. Bestehende Titel sollte sukzessive entsprechend angepasst werden. Beispielsweise könnte man den Inhalt der StartSeite auf eine Seite mit dem Titel Startseite kopieren und auf der StartSeite nur einen Verweis auf die neue Startseite setzen, mit der Bitte, Verweise auf die StartSeite zu aktualisieren, falls man beim Lesen auf solche trifft. Mit der rasanten Wiki-Technik sollte eigentlich recht schnell geschehen sein.

Ich hoffe, dass dieser Vorschlag bei allen, die an der deutschen Sprache interessiert sind (und davon kann man doch bei den Benutzern eines deutschsprachigen Wikis ausgehen, denke ich ;-) auf offene Ohren stößt!

MfG? ChristianSmietana

Ja, stößt bei mir auf offene Ohren. Von mir aus kannst du mit der Änderung gerne beginnen. -/- Nicht so gut gefällt mir deine Idee des sukzessiven Anpassens. Wer eine Seite umbenennt, muss dann bitte auch gleich alle Referenzen darauf im Wiki geradeziehen. Die Referenzen können ja per "Suchen" gefunden werden. (Wäre natürlich hübsch, wenn Helmut da einen Automatismus für das Umbenennen von Seiten anbieten könnte ...?) -- VolkerGlave

Von einem automatischen Umbenennen würde ich aber abraten. Das kann für den Text, an dem ein Verweis auf die umbenannte Seite steht, sinnentstellend wirken wenn sich z. B. das Geschlecht des Wortes ändert und dann der Artikel nicht mehr stimmt. -- EnricoHüttig

Bei einer Änderung der Art "ObjektOrientierteProgrammierung" nach "ObjektorientierteProgrammierung" ändert sich grammatikalisch nichts, so dass ein Automatismus beim Umbenennen hier sehr wohl hilfreich wäre. -- VolkerGlave

Ich hab grundsätzlich nichts gegen Veränderungen, vor allem, wenn sie von einer Mehrheit getragen sind. Aber das Thema ist vielschichtig. ObjektOrientierteProgrammierung entspricht z. B. der Abkürzung OOP und ist IMHO um nichts schlechter als ObjektorientierteProgrammierung?. Warum nicht gleich {objektorientierte Programmierung}?? Das Problem bei StartSeite oder Startseite ist nicht eine notwendige CamelCase-Schreibweise, denn dieses Wiki verlinkt auch automatisch auf großgeschriebene Worte, wenn zugehörige Seiten vorhanden sind. Ein Problem ist, dass solche Seitennamen standardisiert sein können und bei Veränderung externe Links brechen. [...aus Zeitmangel unterbrochen]

{Objektorientierte Programmierung}? ist natürlich prinzipiell die beste Wahl, da es im Text, d.h. in Verweisform, besser lesbar ist. Außerdem kann man Bindestriche verwenden, wo Zusammenschreibung nicht angebracht ist. Das erste Wort sollte man wahrscheinlich immer groß schreiben, denn sonst erscheint es auch kleingeschrieben im Titel und in Kategorienübersichten usw. Allerdings muss man natürlich auch das bestehende System berücksichtigen. Alle Titel sind zur Zeit in "KamelSchreibung?", es bestehen Lese- und Schreibgewohnheiten, und Verweise von extern in das Wiki. Ich gebe Dir recht, dass man da sehr genau überlegen sollte. Ich sehe aber, es gibt einen Weiterleitungsmechanismus, das ist perfekt für die externe-Link-Problematik.

[..fortgesetzt] Löst man dieses Problem durch Weiterleitungen, so bekommt man schnell hunderte von Weiterleitungsseiten. Die CamelCase-Tradition reduziert die Anzahl der Benennungsmöglichkeiten auf ein Minimum und erleitert so das intuitive, automatische Verlinken von Seiten. DseAnregungen könnte auch "Anregungen für das DseWiki", "Anregungen zum DseWiki", "Anregungen zur Verbesserung des DseWiki", ... heißen. Durch die ungrammatikalische Reduktion auf ein Minimum entstehen relativ eindeutige Namen wie SeitenLöschen oder WarumWiki. Im mathematischen Sinne erschließen sie einen Raum wie eine Linearkombination von Vektoren (die auch auswertbar sind: Index nach Worten). Philosophisch bilden Sie den Ansatz für eine PatternSprache im Sinne von ChristopherAlexander. Man kann diese Denkweisen, die an der Basis des Wiki liegen, natürlich aufgeben oder reduzieren, aber verbessert man damit etwas - oder verliert man etwas? Ein C-Experte, den ich zur Teilnahme am DseWiki eingeladen hatte, sagte mal (damals gab's noch keine freien Links) "wenn ich Seiten so schreiben muss, dann verwende ich dieses System nicht". Was bedeutet es, wenn jemand ein Kommunikationssystem aus solchen Formalgründen ablehnt? Bewegen wir uns in einem ideologischen Bereich, wo es um die Priorität von Form oder Inhalt geht? -- HelmutLeitner 19. Oktober 2004 8:27 CET

Wie wäre es, wenn man am Anfang der Seite in einem speziellen Tag einen zusätzlichen Titel angeben könnte, der sofern vorhanden, anstelle des Seitennamens angezeigt wird? Falls technisch machbar, könnte er auch in den Verweisen auf den Seiten dargestellt werden. Grundsätzlich sehe ich keinen Unterschied zwischen der CamelCase-Methode und der Trennung von Wörtern mittels Leerzeichen, aber ich sehe die Schwierigkeit, ein gewachsenes System so umfassend zu verändern. Deshalb würde mir das mit dem zusätzlichen Titel eigentlich ganz gut gefallen. Es wäre eine Erweiterung der Wikitechnik, um der komplexeren deutschen Grammatik gerecht zu werden, wobei aber die grundsätzliche logische Struktur beibehalten werden würde.

Hier noch ein Lösungsvorschlag. Der OP beanstandet ja nicht das nicht-korrekte Deutsch in Titeln und Verweisen. Als Beispiele führt er "Software Entwickler" und "Start Seite" an. _Diese_ Schreibweise der beiden Beispiele ist so aber ja nur im Titel anzutreffen, an den Verweisstellen steht die zusammengesetzte Schreibweise und ist hier ohne Weiteres (und wie ich finde vorteilhafter Weise) als Wiki-Spezialität zu erkennen. Also fallen nur die Titel als nicht-korrektes Deutsch ins Auge. Vorschlag: Das Wiki sollte auch im Titel die zusammengesetzte Schreibweise präsentieren. ("Können" tut das Wiki dies sowieso bereits, siehe meine Teilnehmer-Seite, bei der ich mir von Helmut mal gewünscht hatte, dass meine Name bitte zusammengeschrieben erscheinen möge ...) Nachteil des Vorschlags: Durch die Änderung würden wir bzgl. vieler Begriffe aus dem Index von Suchmaschinen fallen. Was schade wäre, denn die Leute suchen eher nach "Windows oder Unix" als nach "WindowsOderUnix". Lösungsvorschlag dafür: Im HTML-Title-Tag, wo bislang die zusammengeschriebene Schreibweise erzeugt wird, nun die auseinandergeschriebene Schreibweise erzeugen. (Jedoch die auseinandergeschriebene Schreibweise natürlich bitte _nicht_ generieren, wenn es ausdrücklich nicht gewünscht ist, wie bei meiner Teilnehmer-Seite.) -- VolkerGlave

Fände ich in Ordnung. Kann man das so machen? -- ChristianSmietana


KategorieDseWiki
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 17. Januar 2005 15:56 (diff))
Suchbegriff: gesucht wird
im Titel
im Text