Office: Dbwiki -> News (war: nun auf dbwiki.net)

Hallo!

Zum Thema "FAQ": Dabei muss uns klar sein, dass eine Redundanz zur FAQ von Karl (donkarl.com) entstehen könnte.
Allerdings würde ich es praktisch finden, wenn man die oft wiederkehrenden Fragen vom MOF & Co. in eine Sammlung aufnehmen könnte, um dann im MOF auf einen Eintrag diese Sammlung verweisen zu können, dessen Inhalt z. B. nicht in der FAQ von Karl vorkommt.
Anm.: Ich stelle mir dabei eine FAQ ohne irgendwelche Nummerierungen vor. Ich würde das nur als Hauptbereich (Namespace) im Wiki sehen und die Beiträge nach Bedarf passenden Kategorien (mehrere Kategorien pro Beitrag sind erlaubt!) zuordnen.

Was diese FAQ nicht werden sollte: eine Kopie der FAQ von Karl. Das bringt keinen Mehrwert.

Ich stelle mir darunter hauptsächlich eine dynamisch wachsende FAQ vor, die von Benutzern für Benutzer erstellt wird.

Grundaufbau der FAQ-Beiträge:
Frage: ... (ausformulierte Frage - keine einzelnen Stichwörter)
Antwort: ...


Vielleicht ist dieser Bereich auch umsonst, wenn die Antworten auf oft wiederkehrende Fragen im Bereich "How-To's" oder unter "Tipps & Tricks" vorkommen.


=> Bevor Arne das Wiki startet sollte meiner Meinung nach festgelegt sein, welche Gliederung genutzt wird und welche Inhalte in die jeweiligen Bereiche geschrieben werden.
Eine zu feine Gliederung in den "Hauptbereichen" kann zum Problem führen, dass man nicht mehr weiß, wo man einen Beitrag unterbringen soll.
=> daher lieber weniger Gliederungen auf "oberster Ebene" (Namespaces) dafür aber eine detaillierte Zuordnung zu Kategorien ... die übrigens im Wiki jeder Schreiber selbst "erfinden" kann.


Vielleicht hilft das Access-Wiki von utteraccess.com bei der Ideenfindung fürs DbWiki.
Ihr könnt euch auch im Wiki der Access Code Library umsehen, welche Gliederungsmöglichkeiten dort genutzt werden. Dabei aber bitte beachten, dass die Aufgabe dieses Wiki darin bestehen soll, das gemeinsamen Erstellen von wiederverwendbaren Code zu unterstützen. (Das darf man meiner Ansicht nach nicht mit der Aufgabe des DbWiki als allgemeine Informationsquelle vergleichen.)

Falls sich jemand in die Möglichkeiten der Strukturierung eines Wiki (MediWiki) einarbeiten will: die Beschreibung für Wikipedia sind meiner Meinung nach ganz gut.
Anm.: Die Wikipedia verwendet auch die MediaWiki-Software.

mfg
Josef

 

Der Lobhudelei von Anne an Arne möchte ich mich uneingeschränkt anschließen, und selbstverständlich würde ich mich neben der moralischen Unterstützung auch aktiv mit einbringen wollen.

Zur Gliederung/Struktur habe ich noch keine großen Vorstellungen, allerdings den Wunsch auf Einfachheit.
Beispiel: Wo zieht man die Grenze zwischen Tipps & Tricks und FAQ (unter "man" sollte man auch den unerfahrenen Nutzer der Informationen einbeziehen), oder ist das nicht alles eins? Selbst eine Beispieldatenbank, die eine einzelne Thematik beschreibt, ist ein Tipp, nur in einer anderen Darstellungsform als bloßer Text.

Ausformulierte Fragen werden wohl besser sein als Stichworte, Kategorien u.ä.: Wenn ich weiß, was ich wo zu suchen habe, habe ich wenig Probleme. Wenn mir als Neuling schon die Fachbegriffe fehlen, dann wird es schwierig. Gehört die Erstellung einer Abfrage zur Kategorie Abfrage, zur Kategorie SQL, zur Kategorie Programmierung oder Formular oder Bericht? In den allermeisten Fällen doch ein wenig zu allen.

Das würde ich vor allem inhaltlich so verstehen, auch in umgedrehter Richtung. Wiki-Beispieldatenbank vs. Code-Archiv, Wiki-T&T´s vs. Forum-T&T´s, Duplikate, vielleicht auch noch vom gleichen Autor, machen nicht direkt Sinn. Also bräuchte man eine Strategie, was wohin gehört, wenn man die Alternative hat.

Außerdem: Ein wirklich gutes und umfangreiches DBWiki gräbt den Foren das Wasser ab, sicher auch einiger Fachliteratur, zumindest in den einfacheren Bereichen - falls ein intelligenter Nutzer es findet. Ist das gewollt?

//Edit: Das DBWiki wäre eine sehr gute Teillösung zu dieser Frage: Frage - Favoritenliste im Forum

 

Das ist bestimmt das wichtigste Ziel für die Struktur.
Sie muss für den Leser übersichtlich sein und sie darf auch beim Beitragsersteller nicht zur Frage führen, wie er seinen Beitrag einordnen kann.
Es besteht zwar in einem Wiki auch die Möglichkeit einen Beitrag ohne Einordnung zu erstellen, das sollte aber vermieden werden.

Genau! Darum sollten wir überlegen, ob man dann nicht nur eine Struktur für so etwas verwendet.
Oder anders gefragt: was unterscheidet eine FAQ von Tipps & Tricks?

Wenn man FAQ dem Namen nach betrachtet, könnte man das durchaus abgrenzen.
Unter Tipps & Tricks würde ich Beiträge suchen, mit denen ich meine Arbeit mit Access verbessern kann, ohne zuvor eine bestimmte Problemstellung zu haben, die ich als Frage ins Forum stellen könnte.

Aus Wiki-Sicht kann man aber genausogut einen FAQ-Beitrag auch noch in den Tipps & Tricks unterbringen.
Meiner Ansicht nach muss man bei einem Wiki etwas weg von einer Baumstruktur und etwas mehr in Richtung "Vernetzen durch Links und Tags" denken.

Schafft aber Platz für Wein statt Wasser. *Smilie
Oder anders ausgedrückt: Man könnte im Forum über das diskutieren, was im Wiki erklärt wurde und hätte eine gemeinsame Basis für eine weiterführende Diskussion - bzw. für die Fragen, die beim Leser des Wiki noch nicht beantwortet wurden.

Außerdem: wie oft kommen Beiträge im Forum vor, deren Lösung mittels Google-Suche & Co. gefunden werden könnte? *wink.gif*

Der große Vorteil von einem gepflegten Wiki: Es bleibt auf dem neuesten Stand, weil es eine schnelle Ergänzung oder Fehlerkorrektur ermöglicht.
Ein Wiki wird aber niemals eine Diskussionsplattform darstellen können.
Beispiel: Diskussionen über gebundene vs. ungebundene Formulare - die immer subjektiv sind - wird man in einem Wiki nie so festhalten können, dass der Leser den gleichen Eindruck erhält als beim Lesen einer Formsdiskussion zu diesem Thema.

mfg
Josef

 

Mir wäre das schon recht, aber mancher will Wasser, und mancher benötigt es, oder wie wären sonst solche inhaltsschweren Forenthemen (letztlich schon der Forenbereich) zu erklären: zählen wir mal bis ... *Smilie

 

Zum Thema "Kategorie".

Den Seiten im Wiki können mittels
[[Kategorie:Kategoriename1]]
[[Kategorie:Kategoriename2]]
eine oder mehrere Kategorien zugewiesen werden. Daraus resultiert auf der Seite ein Linkgebilde, das auf die Kategorie(n) verweist.

Klickt man darauf, dann könnte die Kategorieseite so aussehen (ich experimentiere momentan nur lokal) (bitte stört euch nicht an den zugewiesenen Seiten, das stimmt natürlich größtenteils nicht). Der Seitenkopf mit dem Inhalt:

wird durch einen (dynamischen) Textbaustein generiert, den man mit {{Kategoriebeschreibung}} im Inhalt der Kategorieseite benutzen kann/sollte. Den Text des Textbausteins habe ich übrigens noch angepasst und etwas einfacher/logischer umgestellt, der Screenshot ist also etwas veraltet.

Die Wiki-Suche stört sich übrigens nicht an Kategorien. Wenn man nach "Abfrage" sucht, ist die Kategorie erst einmal unwichtig. Bei Namespaces wäre das noch etwas anderers, aber die kann man auch automatisch mit durchsuchen lassen (@josef: dazu habe ich eine Möglichkeit gefunden).

Zur Favoritenliste: die könnte man auf seiner Wiki-Benutzerseite pflegen. Mittels eines Textbausteins könnte ich das auch relativ bequem gestalten. Also so etwas wie {{MOFThread|Threadnummer=IrgendeineNummer|Threadtitel=IrgendeinTitel}} (aus dem Bauch heraus) wäre denkbar. Letztendlich bekommt man das aber auch mit der normalen Wiki-Syntax: [url urlbeschreibung] hin, ist vermutlich sogar viel einfacher.

 

\@Arne: Nur zur Klarstellung: Ich meinte nicht primär eine Favoritenliste im Wiki, sondern nur dies, dass man einen Wiki-Eintrag einfacher findet als einen Beitrag in einem Forum, wenn einem die genauen Suchbegriffe und beteiligte Personen nicht gleich einfallen.
Schaden wiederum würde eine leicht erreichbare Favoritenliste auch nicht, es ist halt eine Frage der Datenmenge - und man muss sich auch Großes vorstellen können.

 

\@Arne:

Vorlagen haben allerdings den Vorteil, dass du diese URLs dann auch grafisch hervorheben kannst und z. B. auch einstellen kannst, dass der Link in einem neuen Fenster geöffnet werden soll.
Außerdem findest du damit mit wenigen Klicks alle Seiten, die z. B. auf MOF-Beiträge verweisen.

Ich versuche z. B. in access-codelib die meisten grafischen Elemente über Vorlagen zu gestalten.
Typisches Beispiel: Vorlage:Info – Access Code Library

Das hat sich bei späteren Layoutänderungen (Wiki-Skins) bewährt, da ich nur an wenigen Stellen etwas anpassen musste.


mfg
Josef

 

Ist klar, wobei target="_blank" nicht so mein Ding ist.

Ich kenne das System mit {{Vorlagen}} auch aus meinem CMS (namens "MODx"), dort nennen sich die Vorlagen "Chunks" und werden auch z.B. auf einer Seite mit {{Chunkname}} aufgerufen. Ist also ziemlich ähnlich.

Ein bis zwei Vorlagen habe ich schon gebastelt - die noinclude-Geschichte habe ich jetzt auch verstanden. *biggrin.gif*

 

Guten Abend,

schön zu lesen dass das Dbwiki wiederbelebt wird :-)
Bin gerne behilflich wo ich kann.

 

Moin,

in der Zwischenzeit könnte man ja schon einmal an einem schönen Logo + Favicon basteln. Meine Versuche scheitern an meinem mangelnden Händchen dafür. Ich stelle mir etwas vor, das ein wenig an Datenbanken erinnert. Anbei mein letzter kläglicher Versuch.

 

Naja, im Vergleich zu meinen grafischen Fähigkeiten ist das schon "künstlerisch hochwertig" *wink.gif*

Brauche ich besondere Icons mach ich ein Foto und konvertiere mittels ZIcon das Bild ins ensprechende Format *mrcool

Vielleicht wäre die Gestaltung/Umsetzung des DBWIKI auch etwas für das nächste Lifemeeting?!

 

Hallo!

Bei Bedarf richte ich auch gerne außerhalb der Stammtischtreffen ein Live-Meeting ein.
@arne: du würdest dann zwangsbeglückt zum Referenten. *wink.gif*

mfg
Josef

 

Aha - ist ja interessant. *wink.gif*

Vielleicht sollten wir damit warten, bis es endlich losgehen könnte (sprich: ich die Domain habe, ich kann's leider nicht beschleunigen). Ich weiß aber auch nicht ganz, was ich dann erzählen sollte - eine Kurzvorführung des Abzugs auf meinem Rechner mit den paar Anpassungen wäre vielleicht möglich. Damit bekomme ich aber nicht einmal eine halbe Stunde voll.

Falls sich doch schon jemand am Logo ausprobieren möchte. Lt. Handbuch:$wgLogo - MediaWiki darf es bis zu 135*135 Pixel groß sein (außer ich passe die CSS an, aber fürs Logo sollte die Größe eigentlich reichen).

 

Hallo Ihr.

Ersteinmal vorweg: Danke Arne, für Deine Mühen!

Zum Thema Logo: Ich habe für solche Dinge auch kein glückliches Händchen. Allerdings habe ich mir mal ein Lifetime Icon Pakte gekauft, die Quelle erstellt auch Icons "nach" Wunsch. Ist nicht sonderlich teuer und vielleicht, wenn ich den Zweck erkläre und mein Verhandlungsgeschick einsetze sogar extrem günstig. Dann würde ich gerne als "Richtfest" Geschenk sponsoren wollen. Da ich mich noch nicht mit Erstellung eines Wikis beschäftigt habe, stellt sich die Frage, ob man auf einer solchen Seite auch einen Link an der Hersteller unterbringen kann? In diesem Fall sollte das Logo aber kostenlos zur Verfügung gestellt werden. Keine Ahnung wie ein gutes Wiki es handhaben sollte.

Grundsätzliches zum Thema Logo

- welche Farbe(n) ist/sind erlaubt?
- Das Logo soll eine Datenbank symbolisieren! Noch andere Wünsche? (Ich könnte mir auch einen MOF Erkennungsmerkmal als Hintergrund vorstellen)

EDIT: War zu schnell

Insofern sich kein Icon Profi findet, würde ich mich gerne dem Thema widmen wollen und ein solches "Besorgen"

 

Hallo Sascha,

vielen Dank für dein Angebot. Es ist geplant, keine Werbung, und sei es nur ein Link, auf der Seite zu haben. Deshalb wird die vielleicht kostenlose Variante entfallen. Bevor du dort aktiv wirst, warte aber lieber noch ab.

Farblich bin ich nicht festgelegt. MOF-Style muss nicht sein, das Logo sollte nur zu den beiden Skins "monobook" (zur Zeit auf dbwikialt.ardiman.de zu sehen) und "vector" (wird vermutlich Standard, da es dazu einige nette Erweiterungen wie den neuen Editor gibt) passen. Den vector-Look gibt es zur Zeit auf MediaWiki und Wikipedia – Die freie Enzyklopädie etc. zu sehen.