Michael Kirchner schrieb: > wir diskutieren hier vier miteinander verkn�pfte Dinge: > > a) Profile und Verteilung der Besucher unserer Seiten > b) Gestaltung unserer Hauptseiten, um den Besuchern gerecht zu werden > c) (Neu)Gestaltung der Navigationsleiste(n) auf allen Seiten > d) Anpassung an das neue, internationale Design > > Bevor wir uns �ber a) einig sind, k�nnen wir b) nur im luftleeren Raum > diskutieren.
Genau. > Nur wenn wir uns einig sind, dass die Navigationsleisten f�r alle > Besucher gleich sein sollen, k�nnen wir mit c) weitermachen Du sprichst hier von den Navigationsleisten der von der Startseite abzweigenden Seiten, richtig? > bevor a) und > b) gekl�rt sind. > d) ist an f�r sich unabh�ngig von den anderen Punkten, jedoch m�sste > alle Arbeit sp�ter doppelt gemacht werden, daher warten wir besser. Das sehe ich auch als klug an. > Andreas Borutta wrote: > [Zum Thema Hauptseite b)] >> Wenn Michaels Einsch�tzung zutrifft, dass 75% der Besucher Downloader >> und/oder Neulinge sind, ist jetzt die Frage, wie man dieser gr��ten >> Nutzergruppe besonders dienen kann. > > �h, jein. Ich sehe da immer mindestens eine Doppelfunktion. Gerne soll > der richtige Download-link schnell gefunden werden. Aber irgendwo auf > dem Weg muss auch das "Join" auftauchen. Du meinst wahrscheinlich keine k�nstliche Verl�ngerung des Weges, richtig? So etwas erlangt schnell den Status einer "Erziehungsma�nahme". "Lese erst, was wir Dir zur Mitarbeit sagen wollen, dann sind wir so gn�dig und zeigen Dir den Downloadlink." (Ich �berspitze bewu�t etwas) Ansonsten stimme ich zu: ein Link, der M�glichkeiten zur Mitarbeit erl�utert sollten /neben/ dem Downloadlink sichtbar sein. >> In Michaels aktuellem Ansatz kommt "Download" z.B. nicht an einer >> exponierten Stelle vor. > > �h, wie jetzt? Ich kann mir im Moment nicht vorstellen wie man den Link > zentraler platzieren kann. (NB: Hast du dir das Attachment angeschaut > oder nur den Text gelesen?) Ich habe nur den Text gelesen, weil das heruntergeladene Attachement "hauptseite.odp.sxi" nur eine leere Seite zeigt. > [Zum Thema Nutzerprofil a)] >> Was haltet ihr davon, zun�chst einmal zu sammeln, welche Nutzergruppen >> wir sehen und welche Bed�rfnisse wir bei Ihnen vermuten? > > OK. Ich hatte �ber den Text im Issue in der urspr�nglichen Mail noch > etwas mehr geschrieben, bei Bedarf maile ich das auch gerne nochmal. Du > unterteilst etwas gr�ber als ich. Die Unterteilung ist ein Kompriss. Ich habe auf eine feinere Unterteilung verzichtet, weil sonst die �berschneidung bei den Bed�rfnissen zu reichlich aufgetreten w�ren. >> 1 Neulinge und "Nur-Anwender" >> * Sie wollen erfahren, was Openoffice �berhaupt ist. > > Das w�re der reine Neuling. > >> * Sie wollen die (neueste) Anwendung herunterladen. > > Das w�re ein reiner Downloader. > >> * Sie suchen Unterst�tzung bei Fragen. > > Das w�re ein Supportsuchender > >> * Sie m�chten die aktuellen f�r sie relevanten Neuigkeiten erfahren. > > Hm, OK. Wieviele sind das wohl pro Jahr. Ich jedenfalls surfe nur extrem > selten Webseiten an, um Neues zu erfahren. Du hast wohl Recht. Ich dachte dabei auch mehr an ein Bed�rfnis, welches erst besteht, wenn die Nutzer eh schon (aus anderen Gr�nden) die Seite aufgesucht haben. Was folgt denn f�r Dich aus dem relativ niedrigen Rang dieses "Neuigkeitsbefriedigungsbed�rfnisses"? Sollten Neugikeiten am besten auf der Startseite keinen Raum erhalten und erst auf einer Unterseite pr�sentiert werden? >> * Sie m�chten sich grunds�tzlich �ber eine m�gliche Mitarbeit >> informieren. >> * Sie w�nschen sich eine interessante kommentierte Linkliste zu >> Seiten mit interessanten oder weiterf�hrenden Informationen >> * ... > > Hm. OK. > >> 2 Mitarbeiter >> * Sie m�chten die aktuellen f�r sie relevanten Neuigkeiten erfahren. > > s.o. > >> * Sie m�chten wissen, f�r welche konkreten Aufgaben noch Mitarbeiter >> gesucht werden. > > Dies w�rde im Moment eher �ber die dev-Liste laufen, zumindest f�r > aktuelle Aufgaben. F�r Mitarbeiter auf der Webseite stehen eher > Aufgabengruppen und Ansprechpartner. Ich verstehe den Hauptseitentext > "Aufgaben" eher als Lockmittel f�r Neulinge, die eben nicht wissen, um > was es etwa gehen k�nnte bei der Mitarbeit. Seht ihr Mitarbeiter es denn als w�nschenswert (f�r die Zukunft) an, dass aktuell anstehende Aufgaben auf einer Webseite �bersichtlich strukturiert �ffentlich pr�sentiert werden? (Ein Wiki mit Anmeldung w�re hierf�r IMO der technische K�nigsweg - aber das nur am Rande) Ich k�nnte mir vorstellen, dass es einem potentiell an Mitarbeit Interessierten lieber ist eine solche Liste erstmal in Ruhe zu lesen, anstatt sich diese Informationen "was alles zu tun ist" in einer Mailingliste zu beschaffen. >> * Sie m�chten Kontaktlinks zum internationalen Projekt finden. >> * ... > > Da kann ich dir nicht ganz folgen. Damit spiele ich auf die Navigationslinks aus den toptabs und dem footer an. Das war mein Einstieg in die Diskussion, denn genau diese Navigationsleisten halte ich f�r Neulinge und "Nur-Anwender" f�r regelrecht sch�dlich, weil sie die �bersicht auf der Startseite erheblich verschlechtern. Bis hin zu doppelt vorkommenden Linktexten wie z.B. "Download". Das verwirrt. > Ich denke Mitarbeiten wollen eben die Reihe von Dokumentationen der > Mitarbeitertools ansehen: CVS, mailinglisten, issuezilla, etc. Verst�ndlich. Wir reden aber zur Zeit �ber die Startseite, oder? > [Thema Arbeitsmethodik] >> Was haltet ihr weiterhin davon, wenn wir dieses Sammeln im Wiki >> erledigen, dann k�nnte jeder die Liste erweitern und wir behalten viel >> einfacher die �bersicht als in einer Abfolge von Postings in einer >> Mailingliste oder in Issuezilla? > > Als jemand, dem Onlinearbeit hohen Kosten und Zeitaufwand verursacht, > kann ich diesen Vorschlag nur zur�ckweisen. Meinst Du damit die Kosten f�r eine Onlineverbindung per Modem? Ich bin nicht sicher, ob hier ein Missverst�ndnis vorliegt. Das Wiki h�tte in der Diskussion um die Gestaltung der Website eine sehr simple Rolle: �ffentliche Tafel. Da kann gewischt werden. Issuezilla oder die Mailingliste stellen per Design ein ganz andere Funktion bereit. Sie sind "schwarze Bretter" auf denen nur neue Zettel angepinnt werden k�nnen. Aber wenn hier Vorbehalte gegen das Wiki bestehen - kein Problem. Es handelte sich um ein kleine Anregung unsere Diskussion zu erleichtern. >> Das Medium Issuezilla finde ich, zugegeben, im Vergleich zum Medium >> Mailingliste sehr umst�ndlich in der Nutzung. > > Ein wenig, ja. Es gibt in der Mitarbeiterfaq ein paar S�tze zum > Issuezilla. Wesentlich ist, dass man angemeldet ist, Cookies aktiviert > hat, sich in das "CC:"-Feld eintr�gt und "submit" dr�ckt. Dann werden > alle �nderungen am Issue an dich geschickt. Es gibt kein Threading um nur einen wichtigen Nachteil zu nennen. Wie schon gesagt, mir leuchtet der Gebrauch von Issuezilla f�r den Zweck einer Diskussion wie wir sie f�hren nicht ein. Aber lassen wir das. >> Aber ich kenne die Gepflogenheiten hier und daher auch die Gr�nde >> nicht, warum die Umgestaltung statt in der Mailingliste in Issuezilla >> diskutiert wird - bzw. an beiden Orten. > > In einem Task-Issue, so wie wir ihn nutzen, k�nnen die Arbeitsschritte > sehr gut dokumentiert und gespeichert werden. Dies ist wichtig, um > Zusammenarbeit zu erm�glichen und zu garantieren, dass beim Ausfall > eines Mitarbeites nicht gleich die Weiterarbeit in Frage steht. So > genutzt ist ein Issue ein Werkzeug zur Arbeitsorganisation. Ich sehe keine Vorteile gegen�ber einer Mailingliste. Sie wird doch archiviert. > In einem Issue Entscheidungen herbeizuf�hren oder gar zu diskutieren, > ist eher ungl�cklich, da ist eine Mailingliste besser geeignet. Ich habe > meist zwei Vorgehensweisen mit Task-Issues hier beobachtet: > > - - auf der Mailingliste findet sich eine Gruppe, die kurz diskutiert und > feststellen, dass sie gemeinsame Ziele hat, die Arbeit beginnen kann und > alles weitere findet im Issue statt, bis auf gelegentliche > Zwischenerfolgsmeldungen. > > - - auf der Mailingliste stellt sich heraus, dass die an einer Aufgabe > Interessierten keine �bereinstimmenden Vorstellungen und Ziele haben. > Die Diskussion auf der Liste geht weiter, bis sich eine �bereinstimmung > herstellt (oder sich zumindest zeigt, dass keine �bereinstimmung > gewonnen werden kann). Der Issue wird dann verwendet um die sich > entwickelnden Gegenvorschl�ge zu dokumentieren. Ich nehme diese Tradition einfach als etabliert hin, auch wenn ich die Vorteile bisher nicht nachvollziehen kann. Andreas -- http://ooowiki.de http://borumat.de/openoffice-writer-tipps http://borumat.de/firefox-browser-tipps http://borumat.de/thunderbird-email-tipps --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
