strohhalm.org / Archiv / Projektpflege / Eintrag lesen

Community Konzeptansatz

1. Community Konzeptansatz

   amanojaku.org 05. Juli 2004, 10:16

   hi com,
   
   vorab:
   HIER GEHT ES NICHT UM EINEN NEUEN STROHHALM!
   
   Es geht um einen Konzeptansatz für eine Community Lösung in der strukturierung, rubrizierung und verschlagwortung helfen sollen Fragen schon zu beantworten bevor sie gestellt werden, der schwerpunkt liegt also im Bereich FAQ und KnowledgeManagement.
   
   Es geht darum die Vorteile von Wiki, Weblog, Board und WCMS zu verbinden um die einzelnen Schwächen dieser systeme auszugleichen.
   
   Der Konzeptansatz ist in meinem Wiki festgehalten:
   http://amano7.org/wiki/wakka.php?wakka=WikiWikiBoardWeblogWCMS
   
   Leider habe ich viele Spammer und Kiddies dort gehabt und habe den artikel schreibgeschützt, eure Kritiken und Anregungen werden also von Hand von mir eingetragen werden wenn Ihr Sie hier hinkritzelt.
   
   Das Konzept, bzw. der Ansatz wird noch weiter ausgearbeitet und ich würde mich freuen wenn Ihr euch daran lebhaft beteiligt.

2. Re: Community Konzeptansatz

   timbec 05. Juli 2004, 12:57

   Hallo Ansgar!
   
   Ich finde den Ansatz auch hochinteresant und kann mir diese Idee sehr gut als "fertiges" vorstellen.
   Ich denke auch das es einiges an Arbeit abnimmt, sowohl bei den Usern als auch bei den Moderatoren.
   
   Grade auch Routinen wie Neulingfragen herauszufiltern und diesen sofort fertige Antworten zu präsentieren wäre wohl ein unglaublicher Mehrwert für die meisten Foren.
   
   Ich kann mir nur noch nicht ganz vorstellen wie das ganze aussehen soll, soll direkt in jedem Thread/kommentar bereich/ Artikel alle (oder 5 davon...) verweise aufgezeigt werden, oder wie soll das funktionieren?
   Ich würde eine Liste über/neben/unter den Beiträgen mit Querverweisen als optimal finden, so wie es auch bei vielen Magazinen ala >mehr zum Thema (drweb, spiegel, ...) gang und gebe ist.
   
   ich werde das ganze jedenfalls weiter verfolgen und soweit mein wissen ausreicht auch gerne mit diskutieren.
   
   gruß,
   tim

3. Re: Community Konzeptansatz

   amanojaku.org 05. Juli 2004, 13:43

   Das mit den querverweisen denkt ihr euch immer selbst dazu weil ihr sowas wohl scheinbar alle sehr spannend findet, ist aber mit keinem Wort im Konzept erwähnt.
   Scheinbar sollte es hinzukommen.
   Wie die Querverwiese angezeigt werden ist Sache der Templates die diese aufrufen würden, Beim Wo würde ich auf den Artikel, die Dikussion bzw. sogar den Kommentar verweisen. Beispiel: +---------------------------+
| artikel | verweis 1 |
| | verweis 2 |
| text text | verweis 3 |
| text text +--------------+
| text text | diskussion 1 |
| text text | diskussion 2 |
| text text | diskussion 3 |
| text text | diskussion 4 |
| text text +--------------+
| text text | |
| text text | |
| text text | |
+------------+--------------+
   
   Verweis steht in diesem Falle für den Verweis auf einen Artikel, Diskussion für den Verweis auf eine Diskussion.
   
   Man könnte so weit gehen und Moderatoren eine "Wenn nach 3 wochen keine neue Reaktion von Poster dann schließen" geben um somit eindeutig festzulegen daß es sich hier um eine doppelte Diskussion handelt die bereits an anderer stelle besser beantwortet wurde und nun quasi nur noch als schlagwortansammlung und weiterleitung für suchroutinen diehnt.
   
   Ja, unter diesem Gesichtspunkt muss ich sagen daß Querverweise nötig sind. Ansonsten würde die Zuweisung über die gemeinsammen Oberrubriken und die Verknüpfung zu Artikeln stattfinden.

4. Re: Community Konzeptansatz

   drummerboy 05. Juli 2004, 22:13

   ot: bei dem threadtitel hab ich sofort gewusst, von wem er ist, auch ohne den namen zu sehen :D
   
   drummerboy

5. Re: Community Konzeptansatz

   Earl 05. Juli 2004, 23:12

   Guude,
   
   ich finde das Ganze ne Stufe zu komplex und zu viel Funktionen in eins verpackt. Die Übersichtlichkeit wird IMHO sehr stark darunter leiden (schau dir bloß mal deine Beispielseitenstruktur an). Außerdem ist ne eierlegene Wollmilchsau nicht unbedingt der Weisheit letzter Schluss.
   
   Trotzdem werde ich den Ansatz mal weiter verfolgen.
   
   Gruß

6. Re: Community Konzeptansatz

   timbec 06. Juli 2004, 00:09

   hallo earl!
   
   es ist doch noch garnicht gesagt, wie das ganze nachher aussehen wird und ansgar hatte ja schon gesagt, das die querverweise nicht immer direkt auch angezeigt werden, wenn man diese als option hinzuschalten kann oder je nach fall direkt angezeigt werden und der artikel als zusatz dient dann kann das ganze schon übersichtlich werden, ich denke das ist alles nur ne frage der umsetzung. aber die idee ist noch immer gut :)
   
   gruß,
   tim

7. Re: Community Konzeptansatz

   amanojaku.org 06. Juli 2004, 09:20

   @Earl & timbec
   Es stimmt schon daß die Umsetzung erst zeigen wird ob das zu komplex ist. Im Grunde soll es ebend weniger Komplex und eher Übersichtlich sein. Das Erschlagende währe evtl. halt daß es einen zu großen Strukturbaum geben würde, aber da gäbe es auch sicherlich Möglichkeiten diesen nur Bedingt anzuzeigen, z.B nur bis zur zweiten Ebene.
   
   Die querverweise würden eher wie "weiterführende Links" behandelt die man ja auch von Heise, SpOn und Co kent und die eher selten als unübersichtlich bezeichnet wurden.
   Und daß an allem evtl. 1 bis 2 Diskussionen dranhängen ist auch überlich, ich glaube somit der User kommt damit zurecht.
   
   @drummerboy:ot:
   Mein Charme liegt in meinen Headlines.

8. Re: Community Konzeptansatz

   drwitt 07. Juli 2004, 21:11

   Moin Leute,
   hab ein paar Tage drüber nachgedacht und will meinen Senf auch kurz beisteuern. Es ist teilweise schön ins Blaue geschossen; vielleicht treffe ich ja nicht ganz ins Schwarze, aber ein Bock wirds schon werden ;-)
   
   Amano nennt drei (vier ;-) verschiedene Arten von Inhalten:
   Artikel, Diskussion, Kommentare und Rubriken.
   Ich bin der Auffassung, es gibt zwei Arten:
   * Diskussionsbäume - Kommentarlisten sind entartete Bäume
   * Wikibaustellen - ein Artikel ist eine entartete Wikibaustelle
   Rubriken betrachte ich nicht als eine Form von Inhalt, sondern als eine Einordnung.
   
   Evolutionsgedanke:
   Ein guter "Inhalt" durchläuft ja mehrere Stadien, von der ersten Frage zur ersten Problemspezifikation, von der ersten Idee zur fertigen Antwort, gekrönt durch eine universelle Formel oder ein brauchbares Rezept. Ebenso verhält es sich mit den von Amano ins Auge gefassten Inhaltssorten: Irgendein Beitrag (ein Problem, eine Frage) steht für sich allein als Blatt am Ende des Teilbaumes. Dann kommen andere Leute und kommentieren (vgl. Strohhalm). Wieder andere fügen den Kommentaren Kommentare hinzu, eine Diskussion entsteht. Irgendwann ist dann genug fundiertes Wissen beisammen, der Thread wird in eine Wikibaustelle umgewandelt. Und irgendwann ist dann ein Artikel draus entstanden.
   
   Elementstruktur:
   Strukturell unterscheiden sich alle zwei (von mir aus auch vier) nicht: Alle werden eine Überschrift haben, einen oder mehrere Subtitel, vielleicht ein Bild, Inhalt und eine Linkliste. Die Unterschiede repräsentieren sich neben
   der optischen Aufbereitung in der Funktionalität der Beiträge, z.B. ob es erlaubt sein soll, Kommentare hinzuzufügen oder einen Beitrag wikimäßig zu beackern. IMO bietet sich ein NestedSets-Baum an, der neben den obligatorischen LFT/RGT-Feldern zwei weitere Flags erhält, nämlich comments und wiki. Die Werte dieser beiden Flags spiegeln das Evolutionsstadium wider und entscheiden ferner über Darstellung und Funktionalität eines Elements.
   
   1) Comments (true|false)
   * true: Benutzer dürfen Kommentare verfassen.
   * false: Beitrag ist ein Artikel oder Wikibaustelle
   
   2) Wiki (true|false)
   * true: Der Beitrag darf wikimäßig beackert werden.
   * false: Keine Bearbeitung möglich
   
   
ID LFT RGT| Comments | Wiki | Ergebnis
--+---+---+----------+------+-------------------
04,66,67 true false Kommentarliste (Wurzel)
22,128,176 true true Diskussion (Wurzel)
1265... false true Wikibaustelle
11... false false Artikel

   
   Auf der Startseite können mittels dieser beiden Flags bequem alle Diskussionen, Artikel und Wikibaustellen voneinander getrennt dargestellt werden. - Linklisten oder Bilder (oder auch Wikiänderungen, keine Ahnung, wie Wiki intern funktioniert) zu Artikeln werden in getrennten Tabellen mit
   Fremdschlüssel verwaltet.
   
   Zum Rubikenproblem:
   Mir fällt dazu ein weiteres Tabellen-Feld Rubrikein, das den Kern eines Beitrages benennt. Der indirekte Pfad ergibt sich aus den Schlagworten der übergeordneten Elternelemente eines Beitrags. Realisierbar wäre das über
   einen (fast) beliebig langen URL, der per modrewrite in seine Bestandteile aufgeteilt wird. Natürlich könnte man auch bequem über die ID eines Elements direkt zugreifen. Der Inhalt des Rubrikenfelds könnte mittels einer Auswahlliste festgelegt werden, die sich aus den im NestedSet-Baum bereits vorhandenen Begriffen zusammensetzt. Das Ganze könnte per distinct vorwärts wie rückwärts funktionieren:
   "Zeige alle Unterrubriken dieses Beitrages, also im unteren Teilbaum".
   "Zeige alle Rubriken an, in denen mein Begriff noch vorkommt."
   Das passende SQL kann ich nun nicht aus dem Ärmel schütteln, ich nehme an, daß es für geübte SQL-Akrobaten eine leichte Übung ist.
   
   Wikigedanke:
   Der Vorteil des NestedSet-Modells ist ja, daß ja ganze Teilbäume mit einer SQL-query einfach umgehängt werden können. Ist nun einer der Auffassung, der Artikel über den Boxmodelhack gehört nicht nach "CSS", sondern unter "Browser
   Bugs", kann er ihn gerne umhängen. Der Wikigedanke, daß jeder Vollzugriff hat und die vernünftigen am längsten dabei sind, sollte verhindern, daß interessante Artikel ins Nirvana gehängt werden. Genauso sollte es möglich sein, einen Artikel unterhalb eines anderen einzuhängen. So könnte ein Artikel zunächst nur an der Oberfläche kratzen und die Kindelemente geben dem Surfer den Rest.
   
   FAQ-Funktion:
   Den entstandenen Artikeln müssten nur noch typische Fragen zugeordnet werden, die sich fleißige Autoren nach dem Wikiprinzip ausdenken. Auch hier wieder eine Extratabelle.
   
   Fürs erste langts...
   freu mich auf Reaktionen!
   mfG
   Carsten.

9. Re: Community Konzeptansatz

   amanojaku.org 08. Juli 2004, 09:46

   @drwitt:
   Riesen Respekt erstmal und danke für soviel Input.
   
   > * Diskussionsbäume - Kommentarlisten sind entartete Bäume
   
   Sie gehen das technisch an, ich erstmal nur konzeptionell. Mein nächster Schritt währe gewesen scribbles für mögliche screens zu machen um sich zu überlegen was konzeptionell gegeben sein muss um daraus später überhaupt eine brauchbare GUI zu machen.
   
   Hier ist dann auch schon das Problem wegen dem ich nur schwer auf Ihr vieles Input eingehen kann was aber alles supergut durchdacht und auch zu 99% richtig ist.
   
   Um aber dennoch darauf einzugehen stelle ich mal kurz dar wie ich mir das technisch vorgestellt habe.
   - Nested Sets (iss klar, was sonst)
   - 5 verschiedene Grunddarstellungen:
   -- 1. Startseite / Weblog (cvhronologische Auflistung aktueller Artikel und Diskussionen)
   -- 2. Artikelansicht (mit querverweisen, diskussionen, kommentaren, trackback etc.tt. dazu möglichkeiten den artikel zu bearbeiten, zu verschieben etc.tt.)
   -- 3. Diskussuionsansicht (mit querverweisen, diskussionen, kommentaren, trackback etc.tt. und eingabefeld für neue Kommentare)
   -- 4. Rubrikansicht (Index aller Inhalte unterhalb der angewählten Rubrik bis zu einer tiefe von ca. 3 Ebenen)
   -- 5. Sitemap (Headlines aller Inhalte strukturiert ausgegeben als Liste, Hauptgruppen aufteilung in einzelne Listen durch root id des nested set baums möglich)
   
   Das würde ich gerne erstmal gut visualisieren und mir auch noch mehr gedanken dazu machen und dann erst wirklich auf die technik bzw. das technische konzept eingehen. oder ist diese herangehensweise irgendwie blöde?

10. Re: Community Konzeptansatz

    drwitt 08. Juli 2004, 10:10

    Moin amano,
    
    >stelle ich mal kurz dar [...] vorgestellt habe.
    also, so verschieden sind wir garnicht davor.
    Ich habe gestern u.a. deswegen sehr viel auf dem NSet-Bäumen rumgeritten, weil vorher kurz anklang, daß der Strukturbaum so komplex, oder auch zu komplex sein würde. Und das mag ich nicht so recht glauben... wollte nur sagen, Leute, so verschieden ist das gar nicht, das könnte fast alles in eine Tabelle passen. Wie gesagt, weil die Inhaltsarten voneinander abgeleitet werden können, wären auch die PHP(?)-Klassen voneinander ableitbar. Insofern könnte man ganz einfach deine 5 verschiedenen Ansichten auf der Startseite einrichten.
    
    > Sie gehen das technisch an
    och, so technisch finde ich das garnicht. Waren ja nur ein paar Gedanken zur Datenstruktur.
    Und hör mal auf, die Leute zu siezen, ist ja fürchterlich! ;-)
    
    >visualisieren
    Denn mach das. Diese Herangehensweise ist nicht blöde. Ich find nur, man kann irgendwie zielgerichteter "visualisieren" oder "screenscribbeln", wenn man ein bißchen Datenstruktur oder technische Möglichkeitem im Hinterkopf hat.
    bye
    Carsten.

11. Re: Community Konzeptansatz

    amanojaku.org 08. Juli 2004, 13:45

    > ... werden können, wären auch die PHP(?)-Klassen voneinander ableitbar.
    Ieeeeehhh Klassen. Aber okay, da muss ich wohl einsteigen.
    
    > Und hör mal auf, die Leute zu siezen, ist ja fürchterlich! ;-)
    
    Entschuldigen Sie, zuviel antville gelesen/geschrieben in den letzten Tagen.
    
    > ... wenn man ein bißchen Datenstruktur oder technische Möglichkeitem im Hinterkopf hat.
    
    Ja, da sitzt bei mir auch schon ein wenig was rum, das ist klar, wer nicht weiß wozu die reifen bei einem auto sind macht sich schlau bevor er eines entwickelt, aber ich suche keine spezielle gummisorte raus bevor ich nicht weiß wie das fahrzeug überhaupt aussehen wird ;)
    
    Aber ist ja auch okay was sie da geschrieben haben, gab mir einen schönen "jemand versteht mich" anschub. wie gesagt: danke!