![[Home]](logo.jpg){kind=logo}
Recent Changes Features
Neues
TestSeite
Forum
Suchen
Teilnehmer
Communities
Ordner
Index
Hilfe
Einstellungen
Ändern
Entfernt: 130d129
|
Mehrfach führt eine oben aufgelistete Idee bzw. Funktionalität zu dem Punkt die ungeklärten Details doch in der Konfigurationsdatei dem jeweiligen Benutzer selbst zu überlassen. Ich rede absichtlich von ungeklärten Details. Optionen gibt es, weil keine Einigkeit darüber besteht was besser ist. Vielleicht ist der richtige Weg noch gar nicht gefunden? Und daher wandern halbe Wege in die Konfigurationsmöglichkeiten? In meinen Augen machen Optionen nur einen Sinn, wenn es verschiedene Anforderungen gibt die sich aus momentaner Sicht anders nicht logisch nachvollziehbar abbbilden lassen. Vor der Option steht daher die Frage der Anforderung und die Suche nach dem Weg diese Anforderungen nachvollziehbar unter einen Hut zu bekommen. Das beste ist, wenn der Nutzer gar nicht merkt, daß er die Technik so einsetzt wie er es braucht/erwartet und jemand anderes wendet dieselbe Technik anders an. Keiner von beiden mußte etwas für seine Zwecke konfigurieren. Stattdessen ist das Sytem so ausgelegt das beides naiv aus sich heraus funktioniert. |
Verändert: 132c131
|
Grundsätzlich gilt für mich: Je weniger Konfigurationsmöglichkeiten desto besser. Als alleinstehende Aussage ein voller Widerspruch zur Praxis. Denn je mehr sich Konfigurieren läßt, desto besser kann ich das Produkt z.B. den Wiki meinen Vorstellungen und Ansprüchen anpassen. Stimmt. Doch ich stelle die Gegenfrage: Weisst das Vorhandensein vieler Optionen nicht darauf hin, daß der/die Entwickler sich die Mühe sparen wollten den richtigen oder zumindest einen guten Weg zu finden? Es gibt ein eigentlich ordentliches DTP Programm namens "Ovation". Das ist dermaßen konfigurierbar, daß meine Konfiguration ganz anders reagieren und aussehen könnte als die Konfiguration eines anderen. Hier wurde so weit übers Ziel hinausgeschossen, das die Anwender mit der jeweiligen andere Konfiguration gar nicht mehr arbeiten können. Um kurz weiter auszuschweifen: Bestünde die Möglichkeit, daß ich immer und überall sowieso mit meiner Konfiguration arbeiten könnte, so würde sich dieses Problem stark relativieren. So weit sind wir aber noch nicht. Und vielleicht ist das auch gut so, denn dieser Schritt geht vermutlich einher mit gemieteter Software. Zurück zum Thema. |
|
Eine Diskussion verschoben nach KonfigurationsMöglichkeiten. |
Entfernt: 134,142d132
|
Überspitzt gesagt: Viele Optionen überlassen es dem Benutzer diese so zu gestalten, daß ein sinnvolles Arbeiten möglich ist. Das ist aber nicht Ziel des Benutzers! Ziel des Benutzers ist es, einen Text zu schreiben. Er will und soll sich nicht mit Konfigurationen beschäftigen müssen. Klar, es wird eine Default-Konfiguration geben. Doch warum ist der überwiegende Teil der Optionen nicht auf den Default fixiert? (Also keine Option mehr.) Weil sich der/die Entwickler nicht sicher sind was besser ist. Weil der richtige Weg noch nicht gefunden ist? Leider führt das oft zur Auslagerung/Übertragung von weiterhin offenen Fragen auf den Benutzer. Er hat doch alle Möglichkeiten, wenn er will soll er sich doch seine Gedanken machen. Die Suche nach der (ich übertreibe mal) eierlegenden Wollmilchsau bleibt an diesem Punkt einfach stehen. Das sollte sie aber nicht, denn die optimale Lösung für alle ist noch nicht gefunden. Wer jetzt ankommt und behauptet: Die optimale Lösung für alle gibt es gar nicht. In manchen Punkten mag das so sein. Die Praxis hat mich oft eines besseren belehrt. Ich sah keinen besseren Weg. Ich dachte das Thema zu verstehen und erklärte sogar unauflösbare Widersprüche, die dann eben als Option in der Konfigurationsdatei landeten. Und doch kam eines Tages eine Idee (von außen oder von mir, egal) die das alles überflüssig machte und den Widerspruch geradezu in Luft auflöste. Man sieht manchmal den Wald vor lauter Bäumen nicht. Vielleicht habe ich es geschafft, ein wenig zum Ausdruck zu bringen, warum ich der Ansicht bin, daß sich Konfigurationsmöglichkeiten auf ein Minimum beschränken sollten. Neue Anforderungen, neue Ideen sollten so im Grundkozept integrierbar sein, daß deren späteres hinzukommen nicht erkennbar ist. Konfigurationsmöglichkeiten haben zweifelsohne ihre Berechtigung, aber das bedeutet nicht, einfach mal so aus allem und jedem eine Option hervorgehen zu lassen. -- MarkusHuber *Ideen:  Ändern |
Verändert: 144c134
|
OrdnerFeatures |
|
OrdnerFeatures OrdnerTransparenz |
Die RecentChanges
sind eine der unverzichtbaren Grundfunktionen eines Wiki. Ohne diese ist eine sinnvolle Kooperation im Wiki nicht möglich - man würde nicht wahrnehmen, was die anderen Teilnehmer schreiben.
Inhalt der RecentChanges-Seite ist eine chronologische Liste der von den Teilnehmer durchgeführten Änderungen. Obwohl das ziemlich simpel klingt, gibt es eine ganze Reihe von zusätzlichen Features, die die Nützlichkeit dieser Funktion beeinflussen.
In deutschsprachigen Wikis heißen die RecentChanges manchmal "AktuelleBeiträge", oder nur "Beiträge", "AktuelleÄnderungen", "Neues" oder "Bearbeitungen".
Automatisches Zurückstützen  |  |
In den ersten Wikis waren die RecentChanges eine Seite wie jede andere. Bei jeder Änderung wurde einfach eine Zeile mit dem Seitennamen und der IP-Nummer des Teilnehmers angefügt. Der neueste Eintrag war immer hinten und die Seite wuchs und wuchs, bis sie ein Teilnehmer sie durch Löschen per Hand auf eine sinnvolle Größe zurückgestutzt hat.
Normalerweise brauchen sich heute Wiki-Benutzer darum nicht mehr kümmern. Die Änderungseinträge kommen in entweder als Zeileneinträge in einen Log-File oder als Datensätze in eine Datenbank. Daraus werden dann die erforderlichen Einträge gezielt ausgelesen.
| Zeitanzeige | |
Es ist angenehm, wenn bei der Änderung auch die Änderungszeit angegeben wird. Warum? Die zusätzliche Information kann manchmal Anknüpfungspunkt für ein Gespräch sein ("du warst gestern aber wieder lang aktiv!"), es kann aber auch - wenn es gerade vor 2 Minuten war - eine Hinweis geben, dass der Benutzer vielleicht noch daran feilt und es daher besser ist, nicht sofort in der Seite weiter zu schreiben.
| Zeitzone des Teilnehmers berücksichtigen | |
Wenn die Zeit angezeigt wird - schön! Aber welche? Es bringt wenig, vom Benutzer zu erwarten, dass er eine angezeigte Serverzeit im Kopf auf seine Lokalzeit umrechnet. Das ist es besser, er kann irgendwo (z. B. unter "Einstellungen") seine Zeitzone definieren und bekommt dann alle Zeitangaben in seine lokale Zeit umgerechnet.
| Wählbare Länge der RecentChanges | |
Wie viele Beiträge sollen in RecentChanges angezeigt werden? Manche Wikis zeigen alle Änderungen (bis sie manuell gestutzt werden). Manche Wikis zeigen eine bestimmte Anzahl von Änderungen (siehe DeWikiPedia:RecentChanges). Manche Wikis bestimmen die Zahl der Einträge nicht direkt (also "die 50 letzten"), sondern indirekt durch einen Zeitbereich (also "die Änderungen der letzten X Tage").
Wieder ist es praktisch, wenn sich dies der Teilnehmer so einstellen kann, wie er dies braucht. Wenn jemand nur alle 1-2 Wochen in ein Wiki kommt, möchte er vielleicht eine 30-Tage-Anzeige sehen (vor allem wenn wenig Traffic existiert). Wenn jemand täglich in ein Wiki schaut, dann wird er vermutlich eine 3-Tage-Anzeige bevorzugen. Es schadet nicht, wenn man das in den "Einstellungen" konfigurieren kann.
| Reihung Top-Down | |
Ursprünglich waren die neuesten Einträge am Ende der RecentChanges platziert. Praktischer ist es am Anfang der Seite. Manche Wikis lassen die Benutzer dies konfigurieren.
| Teilnehmeranzeige | |
Relativ nützlich ist die Anzeige des Benutzernamens. So sieht man auf einen Blick, von wem eine Änderung kommt. Die IP-Nummer ist einfach zu wenig, vor allem für den gelegentlichen Benutzer.
Technisch wird der Benutzername fast immer mittels Cookie realisiert. Entweder gibt es eine spezielle Funktion (siehe 
WardsWiki:UserName) zur Eingabe, oder diese ist Teil eines Formulars für "Einstellungen" (engl. "Preferences") in das der Benutzer auch noch andere Dinge (z. B. eben Optionen für die RecentChanges) konfigurieren kann.
| Differenzanzeige / Art | |
Viele Wikis haben unmittelbar neben dem Seitennamen einen Link für eine DifferenzAnzeige?. Beschriftet ist das als "diff", "(diff)", "Differenz" oder mit einem entsprechenden Grafiksymbol. Wenn man sich primär für die Frage "Was ist verändert worden" interessiert, dann bekommt man hier die direkte Antwort.
Ob diese Funktion an dieser Stelle notwendig ist, ist fraglich. Andere Wikis mit Differenzanzeige bieten diese Funktion nur auf der jeweiligen Seite an. Das scheint kaum ein Nachteil zu sein. Manche Wikis bieten die Differenzanzeige an beiden Stellen ("hilft's nicht so schadt's nicht").
| Recent Edits (kleine Korrekturen) | |
Normalerweise mischen sich in den RecentChanges inhaltliche Beiträge (die mehr oder weniger interessant sind) mit kleinen Korrekturen und Layoutänderungen (die fast niemand interessieren). Es kann ärgerlich werden, wenn man viele Beiträge anklickt, ohne dass man etwas interessantes zu lesen bekommt.
Daher gibt es vielfach beim Editieren die Auswahl "[x] Änderung ist eine kleine Korrektur", wobei dies bewirkt, dass die Änderung nicht in RecentChanges angezeigt wird. Wenn die Benutzer das richtig benutzen, dann werden die RecentChanges viel attraktiver.
Leider werden die "kleinen Korrekturen" oft missbraucht, sie sind also das, was englisch als "mixed blessing" bezeichnet wird. Wenn Benutzer normale Beiträge - in Bescheidenheit oder um Konflikte zu vermeiden - als "Korrekturen" deklarieren, dann nimmt diese niemand mehr wahr. Im Extremfall kann es so aussehen, als wäre im Wiki nichts geschrieben worden, aber in Wirklichkeit sind dutzende von Beiträgen geschrieben und als "Korrekturen" versteckt worden. Wenn das passiert, kann man nur mit den betreffenden Benutzern diskutieren und allenfalls dieses Feature für eine Zeit abschalten.
Natürlich braucht man dann auch eine Funktion, um diese kleinen Korrekturen gezielt anzuschauen, oder um die RecentChanges optional mit oder ohne diese Korrekturen anzuzeigen.
Ein anderer negativer Effekt, der sich durch Abtrennung von "kleinen Korrekturen" ergeben kann, ist, dass auch kleine Korrekturen Aufmerksamkeit auf eine Seite lenken, die vielleicht schon lange keine Änderungen / Verbesserungen mehr erfahren hat, obwohl welche möglich wären. Von daher sollte man eine solche Funktion vielleicht erst dann anschalten, wenn es ansonsten zu unübersichtlich würde, also bei sehr aktiven Wikis.
| Detaillierungsgrad | |
Wikis unterscheiden sich sehr stark im Detailierungsgrad der Anzeige. Typische Variationen:
- (1) angezeigt wird jede einzelne Änderung (z. B. DeWikiPedia:RecentChanges)
- (2) angezeigt wird nur die letzte Änderung jeder Seite an jedem Tag
- (3) angezeigt wird die letzte Änderung von jedem Benutzer an jeder Seite je Tag (z. B.
GründerWiki:RecentChanges) - (4) angezeigt wird nur die letzte Änderung jeder Seite (z. B. WardsWiki:RecentChanges)
- ...
- Ich finde es nicht so doll, wenn eine Zusammenfassung der Einträge Kommentare zur Änderung ausblendet. Es ist oft der Fall, dass ich eine große Änderung einer Seite mache, und dann noch einige kleine. Den Kommentar gebe ich nur bei der ersten Änderung ein. In den RecentChanges ist dann der Kommentar gar nicht zu sehen. --ThomasKalka
| Kommentar zur Änderung | |
Beim Speichern einer Seite kann ein Kommentar eingegeben werden, der dann auf der Liste der Änderungen erscheint. Der Leser kann so schneller beurteilen, ob er die geänderte Seite besuchen möchte.
Ergänzend könnte eine Auswahlbox die Art der Änderung klassifizieren (Korrektur, Antwort, Löschen der Seite). Ich kenne jedoch bisher keine Software, die das unterstützt. --ThomasKalka
| Änderungen in der Umgebung | |
MediaWiki kann Änderungen in der Nachbarschaft einer Seite anzeigen.
Zur Nachbarschaft zählen alle Seiten, auf die die aktuelle Seite verweist, oder die auf die aktuelle Seite verweisen.
| Thematisch gegliederte Liste | |
Theoretisch wäre es möglich mittels des KategorieSystem?s eine thematisch gegliederte Liste von Änderungen anzuzeigen. Bisher kenne ich keine Implementation, die das macht. --ThomasKalka
| Angabe zur Menge der Änderungen | |
Im CoForum hat Karl vorgeschlagen, die Anzahl der geänderten Zeichen
anzugeben. Das wäre IMHO ein guter Indikator für die Menge der Änderungen. --ThomasKalka
- Ich finde das eine gute Idee. Ein stilisierter Balken, der den Änderungsumfang optisch darstellt, wäre auch schön.
| Features mit eigenen Seiten | |
| Weitere Features | |
Bitte listet weitere Features auf, die Euch bei den verschiedenen WikiEngines aufgefallen sind, oder Euch angenehm erscheinen. --ThomasKalka
...
| Diskussion | |
- Ich finde die Recentchanges eines Wikis ist das Herzstück und die Zentrale und würde mir eine Diskussion über mögliche optimierungen dieser Seite wünschen.~ErnstGruber
- Gibt's doch längst: RecentChangesFeatures. -- HelmutLeitner
Ich halte es für nicht optimal das Automatisch 30 Tage angezeigt werden meiner Meinung nach würden 3 Tage reichen,wer weiter zurückblicken will hat sowieso die Möglichkeit.
Zustimmung FranzNahrada
- Das könnt ihr unter "Einstellungen" einstellen. Es ist eine Konzession an Wikis, die wenig Traffic haben. -- HelmutLeitner
weniger Zustimmung FranzNahrada
Was würdest für neue Inovationen sehen?~ErnstGruber
Eine Diskussion verschoben nach KonfigurationsMöglichkeiten.
OrdnerFeatures OrdnerTransparenz