Kritik gefragt (www.die-schnauzer.de)

[Christoph G.]

Guten Nachmittag,

ich war letzte Woch mal wieder kreativ tätig und stelle das Ergebnis meines Schaffens hiermit zur Diskussion.
Viele Augen sehen bekanntlich mehr als wenige, deshalb hoffe ich auf einiges an konstruktiver Kritik.
Die zu bewertende Seite: http://www.die-schnauzer.de/

Gruß
 Christoph G., der mit diversen Namensvettern weder verwandt noch verschwägert ist

ps: etwas weniger Wind, und das Wetter wäre echt optimal - viel zu schön, um hier vorm Rechner zu versauern...

[Mathias G]

gutten nachmittag mein lieber,
also hier ein kleiner vorschlag
-bei dem Kartenvorverkauf nicht durchstreichen sondern nur
 hinschreiben das entweder momentan nicht die möglichkeit besteht und
 das es in arbeit ist oder das es nichts zum vorverkauf gibt.

ansonsten ganz gut hätte es nicht besser machen können ;)

MFG

Mathias

Guten Nachmittag,

ich war letzte Woch mal wieder kreativ tätig und stelle das Ergebnis meines Schaffens hiermit zur Diskussion.
Viele Augen sehen bekanntlich mehr als wenige, deshalb hoffe ich auf einiges an konstruktiver Kritik.
Die zu bewertende Seite: http://www.die-schnauzer.de/

Gruß
 Christoph G., der mit diversen Namensvettern weder verwandt noch verschwägert ist

ps: etwas weniger Wind, und das Wetter wäre echt optimal - viel zu schön, um hier vorm Rechner zu versauern...

[Dave]

Hi Chris*dernichtmitdiversennamensvetternverwandtoderverschwägertist*toph,

tolle seite, und der counter is genial! (zur info: letzteres war ironisch gemeint *g*) Also bis auf den counter eine sehr schöne seite.

Frohe Western,
Dave

[Dave]

Mir fällt gerade noch auf: der Titel sollte wohl eigentlich "die Schnauzer" heissen, nicht "die Schnauer"...

Dave

[Christoph G.]

hi.

Mir fällt gerade noch auf: der Titel sollte wohl eigentlich "die Schnauzer" heissen, nicht "die Schnauer"...

ups...

Soetwas sollte eigentlich nicht passieren...
Danke erstmal, wär auch zu peinlich, wenn das noch lange so stehn geblieben wäre - ich hätte das nie bemerkt...;)

Gruß
 Christoph

[Friedel]

Ich finde Das Design sehr gut. Aber mich stören die Cookies. Wenn du schon Cookies auf den Rechnern deiner Besucher speichern willst, solltest du sie darüber aufklären. Auch darüber, wozu die Cookies gut sind. Falls die Cookies vom Counter sind, würde ich den Counter an deiner Stelle entfernen. Es gibt mindestens genug Counter die keine Cookies verwenden. Ansonsen ist ein eigener Counter immer vor zu ziehen, wenn man überhaupt einen verwenden will. (Wozu? Der Webmaster kann das aus der Serverstatistik erkennen, der Besucher interessiert sich nicht dafür.)

[Christoph G.]

G'day

Erstmal Danke für das Lob, hört man immer gern...
Der Counter war eine Vorgabe des Auftraggebers, die Seite liegt bei Freecity -> kein php oder anderweitiges cgi, was aber bisher auch nicht nötig war.
Auf der Seite ist es bei aktiviertem Javascript möglich, die Schriftgröße zu variieren (die beiden Lupen in der rechten oberen Ecke).
Die Schriftgröße wird in einem Cookie gespeichert, sodass die gewählte Größe auch auf allen weiteren Seiten zur Verfügung steht.
Ich selbst finde Cookies nicht so problematisch - wer sie nicht will, deaktiviert sie halt - aber ich lasse mich da gerne eines besseren belehren: Was spricht denn gegen den Einsatz von Cookies?

Gruß
 Christoph

[molily]

Hallo, Christoph,

Der Counter war eine Vorgabe des Auftraggebers, die Seite liegt bei Freecity -> kein php oder anderweitiges cgi, was aber bisher auch nicht nötig war.

Ist es dann nötig, den Counter sichtbar einzubinden? Wenn er nur die Zugriffe zwecks interner Auswertung zählt, wäre ja auch eine unsichtbare Grafik (display:none) angemessen.

Die Schriftgröße wird in einem Cookie gespeichert, sodass die gewählte Größe auch auf allen weiteren Seiten zur Verfügung steht.
Ich selbst finde Cookies nicht so problematisch - wer sie nicht will, deaktiviert sie halt - aber ich lasse mich da gerne eines besseren belehren: Was spricht denn gegen den Einsatz von Cookies?

In dem Fall ist es m.E. sinnvoll und zumutbar, Session Cookies zu verwenden.

Die generellen Nachteile von Cookies kannst du im Forumsarchiv recherchieren... Der größte Nachteil im Bezug auf deine konkrete Anwendung ist wahrscheinlich, dass du damit rechnen musst, dass Cookies nicht angenommen werden, speziell nicht über JavaScript, und damit die Schriftgrößenveränderung nicht dokumentübergreifend gleichbleibt.

Grüße,
Mathias

[Christoph G.]

Hallo Mathias

Ist es dann nötig, den Counter sichtbar einzubinden? Wenn er nur die Zugriffe zwecks interner Auswertung zählt, wäre ja auch eine unsichtbare Grafik (display:none) angemessen.

Da habe ich mich wohl undeutlich ausgedrückt: ein SICHTBARER Counter war die Vorgabe; mir persönlich ist schon klar, dass der Nutzen / die Aussagekraft eines Webcounters gegen Null tendiert, aber meine Meinung ist da nicht ausschlaggebend...

Die generellen Nachteile von Cookies kannst du im Forumsarchiv recherchieren... Der größte Nachteil im Bezug auf deine konkrete Anwendung ist wahrscheinlich, dass du damit rechnen musst, dass Cookies nicht angenommen werden, speziell nicht über JavaScript, und damit die Schriftgrößenveränderung nicht dokumentübergreifend gleichbleibt.

Ich bin da einfach mal so frei anzunehmen, dass wer Javascript bzw. Cookies deaktivieren kann auch dazu in der Lage ist, die Schrift der Webseite zu skalieren. Da ich jedoch (jedenfalls einmal) px-Angaben verwende, wird es wohl Probleme mit dem IE geben - was mir aber eigentlich vollkommen egal ist - und sooo winzig sind 13px nun auch wieder nicht... (hätte ich das jetzt nicht sagen sollen - man wird sehen ;))

Gruß
 Christoph

[molily]

Hallo Christoph,

http://www.die-schnauzer.de/

Technisch gibt es wenig zu beanstanden (du ahntest es bereits).

Im Opera 5.12 und 6.06 funktioniert das Überschreiben der Hintergrundfarbe von Tabellenzellen im @media-Bereich nicht (im Opera 7.10 schon), ein Beispielscreenshot:
<img src="http://home.t-online.de/home/dj5nu/fanhost/schnauzer.jpg" border="0" alt="">
Wenn du die Zeile 229 des Stylesheets durch background-color:transparent ersetzt - momentan steht dort background:transparent -, dann sollte es funktionieren.

Ferner finde ich es unnötig, die JavaScripts über drei Ressourcen zu verteilen - vor allem wenn das Script nur eine oder wenige Zeilen lang ist, dann ist der HTTP-Overhead wahrscheinlich zigmal so groß. Falls du die einzelnen Scripts nur auf bestimmten Dokumenten der Site brauchst (es sieht aber nicht so aus, falls ich mich nicht irre), würde ich ein serverseitiges Script benutzen, um je nach Parameter ein externes JavaScript mit dem jeweiligen Code in einer Ressource zu liefern (natürlich mit richtigem Content-Type).

Links mit dem Linktext »hier« würde ich immer vermeiden, auch wenn du zusätzlich einen aussagekräftigeren Link kurz danach anbietest. Eventuell den Satz umformulieren. Zugegeben, es ist nicht sehr tragisch.

Inhaltlich fühle ich mich nicht rundum befriedigt, beispielsweise würden mich genauere Infos über die Veranstaltungen erfreuen (ich wohne nicht in Frankfurt, aber wie würde ich bspw. zu euerm Straßenfest kommen, was genau passiert da?). Aber wahrscheinlich werkelt ihr/werkelst du noch daran.

Vermutlich ist »Homepage« ein verwirrender Rubrikbezeichner, da man dort nicht das Impressum, das Gästebuch und eine Linkliste vermuten würde. »Impressum« würde ich, wenn du bei dieser Strukturierung bleibst, an das Ende der Rubriknavigation stellen, die Neuigkeiten rücken dann auf. Meintest du eigentlich Kontakt (und Impressum) und hast es deshalb an den Anfang gestellt? Vielleicht wären diese Meta-Inhalte passend für einen in jedem Dokument eingebundenen Fuß. Ein Kontaktformular samt Formmailer wäre dafür passend, das ist meiner Erfahrung nach immer gerne gesehen.
»Der Verein« würde ich an zweite Stelle bzw. bei einer Umstrukturierung weiter vorne in der Navigation stellen, sodass das Schema paraphrasiert in etwa lautet: Einleitung - Wer wir sind - Was wir (für Sie) machen - einzelne Aktivitäten (Gruppen).

Ich würde in einer Navigation keine Links auf das Dokument selbst einbinden, also anstatt einem hervorgehobenen Link in der Menüleiste schlichtweg ein hervorgehobenen (strong-Element) Text ohne Link hineinsetzen. Dasselbe gilt für die Rubriknavigation.
Das heißt <a>foo</a> | <strong>bar</strong> | <a>baz</a> et cetera, das Styling ist natürlich beliebig über CSS variierbar, wie du weißt.

Das Logo bzw. speziell dessen Schriftzug sieht m.E. ziemlich verpixelt aus, die Schattierungen und Verläufe wirken verwaschen. Frage mich aber nicht, wie man das konkret besser umsetzen könnte (Photoshop-technisch usw.).

Grüße,
Mathias

[Christoph G.]

Hi

Danke erstmal für die ausführliche Antwort. Also, los gehts:

Wenn du die Zeile 229 des Stylesheets durch background-color:transparent ersetzt - momentan steht dort background:transparent -, dann sollte es funktionieren.

Wird erledigt...

Ferner finde ich es unnötig, die JavaScripts über drei Ressourcen zu verteilen - vor allem wenn das Script nur eine oder wenige Zeilen lang ist, dann ist der HTTP-Overhead wahrscheinlich zigmal so groß.

[...]

Serverseitige Skripte stehen derzeit leider nicht zur Verfügung, und nur für die paar Javaskripte halte ich einen Providerwechsel für etwas übertrieben.
Aber werden die .js-Dateien nicht bei allen folgenden Seiten (außer der ersten) nicht ohnehin aus der Browsercache geladen, so dass die zwei HTTP-Header, die ich mir sparen könnte, sowieso nur einmal Versandt werden müssen?

[...]

Inhaltlich fühle ich mich nicht rundum befriedigt, beispielsweise würden mich genauere Infos über die Veranstaltungen erfreuen (ich wohne nicht in Frankfurt, aber wie würde ich bspw. zu euerm Straßenfest kommen, was genau passiert da?). Aber wahrscheinlich werkelt ihr/werkelst du noch daran.

Stimmt.

Das Logo bzw. speziell dessen Schriftzug sieht m.E. ziemlich verpixelt aus, die Schattierungen und Verläufe wirken verwaschen. Frage mich aber nicht, wie man das konkret besser umsetzen könnte (Photoshop-technisch usw.).

Ich habe von Grafikbearbeitung so gut wie keine Ahnung und benutze derzeit den GIMP, da kostenlos. Werde mich wohl nochmal mit dem Logo beschäftigen müssen, garantieren kann ich aber für nichts ;)

Alles, was ich jetzt unterschlagen habe, habe ich natürlich nicht vergessen und ich werde mich mit deinen Vorschlägen noch befassen, aber derzeit ist das Wetter viel zu gut (komme grade vom Radfahren), so dass ich wohl erst wenn es mal wieder etwas regnet viel Zeit in dieses Projekt investieren werde - als Schüler und Hobbyprogrammierer (nicht nur HTML - falls jetzt wieder einer kommt und meint, HTML würde ja gar nicht programmiert...) ist man da ziemlich flexibel...

Gruß
 Christoph

[molily]

Hallo,

Ferner finde ich es unnötig, die JavaScripts über drei Ressourcen zu verteilen - vor allem wenn das Script nur eine oder wenige Zeilen lang ist, dann ist der HTTP-Overhead wahrscheinlich zigmal so groß.

(...) Aber werden die .js-Dateien nicht bei allen folgenden Seiten (außer der ersten) nicht ohnehin aus der Browsercache geladen, so dass die zwei HTTP-Header, die ich mir sparen könnte, sowieso nur einmal Versandt werden müssen?

Stimmt - das sollte in der Regel so sein. Es ging mir auch nicht darum, dass die Dateien jedes Mal komplett neu übertragen werden. Ich habe eher Angst um Browser oder Proxies, welche mit jedem Request »Conditional Gets« senden, also mit jedem Dokument beim Server mindestens fünf bis achtmal zusätzlich anklopfen, ob die Titelgrafik und die paar kleinen Grafiken, das Stylesheet und die drei JavaScripts im Cache noch aktuell sind. Die Antwort fällt zwar kurz aus, weil der Server lediglich »Not Modified« senden sollte, aber pro Dokument würden zahlreiche Anfragen hinzukommen.

Grüße,
Mathias