Bleiwn
Stephan Huber
- design/layout
Hi!,
ich würde auch gern mal ein bißchen abgeflammt werden, (mist Herbst, ist so kalt hier im Moment ;-)), deswegen:
Ich habe letzte Woche eine Seite aktualisiert, und habe dabei wieder ein bißchen an dem Problem geknabbert, wie man viele Informationen/Links auf einer Seite unterbringt, ohne daß es eine "Bleiwüste" wird. Ich bin daran in gewisser Weise direkt gescheitert, ich finde meine Lösung betont einfach das "bleiwüstenhafte" ;-):
http://nanotec.de/page_zweiphasen_st4018_de.html
Ich könnte einen Teil der Downloadmöglichkeiten für pdfs und Zeichnungen in Dropdowns unterbringen, aber irgendwie fände ich das eher einen Verlust als einen Gewinn an Übersicht.
Oder? Was macht man in einem solchen Fall sonst?
Ansonsten freue ich mich auch über sonstige Kritik am *grafischen* Design. (Ich weiß, daß es nicht validiert, das ist ein Redesign von vier Jahre alten Seiten, die ich per Skript in die neue Struktur geschubst & gesäubert habe, da muß ich noch länger händisch nacharbeiten :-(). Aber mit IE5+ und Mozilla sollte es gut funktionieren. (NS4 bekommt eine automatisch erstellte Textversion, aber die hat noch Bugs, und deren Design ist wegen Nichtexistenz sowieso nicht diskussionswürdig ;-))
Viele Grüße
Stephan
Hallo Stefan,
da stand sicher ein Papierprospekt Pate, oder?
Ich finde es relativ gut gelöst, auch wenn die Seite eben internetmäßig leichter sein könnte. Man könnte Bereiche auf Extraseiten auslagern. Auf Papier geht das schlecht, weil jede Seite Extrageld kostet für Lithos, Druck und auch später neim Porto. Im Internet kostet aber eine Extraseite kaum Extraporto.
Wie gesagt, trotzdem finde ich es gut gelöst.
Habe mir auch gleich was abgeguckt: Linkes Frame, Lisate mit den OnMouseOver-Links. Frage dazu: ist es bei Tabellenzellen und OnClick immer so, dass die gesamte Zelle dann sensitiv ist? Das hat mich bei Links in Tabellen nämlich schon immer gestört, das nur der Text selbst Link war und nicht die ganze Zelle.
Grüße aus http://www.braunschweig.de
Tom
Hi Tom,
da stand sicher ein Papierprospekt Pate, oder?
Ich finde es relativ gut gelöst, auch wenn die Seite eben internetmäßig leichter sein könnte. Man könnte Bereiche auf Extraseiten auslagern. Auf Papier geht das schlecht, weil jede Seite Extrageld kostet für Lithos, Druck und auch später neim Porto. Im Internet kostet aber eine Extraseite kaum Extraporto.
Wie gesagt, trotzdem finde ich es gut gelöst.
ja, ich finde es auch "den Umständen entsprechend" gut... man hat halt die Links nicht vermeiden können. Wenn mir einer widerspricht mit der Begründung es seien zuviele Links, dann muss er eine halbe Stunde lang die ICQ-Homepage anschauen und alle Links abschreiben ;P
Habe mir auch gleich was abgeguckt: Linkes Frame, Liste mit den OnMouseOver-Links. Frage dazu: ist es bei Tabellenzellen und OnClick immer so, dass die gesamte Zelle dann sensitiv ist? Das hat mich bei Links in Tabellen nämlich schon immer gestört, das nur der Text selbst Link war und nicht die ganze Zelle.
da kann man schön spielen, mit solchen konstrukten.
beispiel:
#menue td a{display:block; background-color:transparent; width:100%; height:100%; color:blue;}
#menue td a:hover{display:block; background-color:lightblue; width:100%; height:100%; color:#ffffff;}
(solche konstrukte sind übrigens der grund, warum es _C_SS heißt und nicht SS ;-)))
das kommt IMO dem auch schon ziemlich nahe, ohne irgendwelche JS-Verenkungen zu machen ;-)
(von der space-minimierung will ich garnicht reden, wenn ich die eventhandler so umgehen kann... ;-) )
Fabian
Hallo, Fabian.
ist es bei Tabellenzellen und OnClick immer so, dass die gesamte Zelle dann sensitiv ist? Das hat mich bei Links in Tabellen nämlich schon immer gestört, das nur der Text selbst Link war und nicht die ganze Zelle.
da kann man schön spielen, mit solchen konstrukten. (...)
"Die Idee ist gut, doch die (Browser-)Welt noch nicht bereit." Opera dreht bei height:100% völlig am Rad, auch ohne das macht er probleme mit den Linkunterstreichungen.
Wenn man einen Rand zwischen Zellenrahmen und Text sowie einen beim Hovern sich ändernden Hintergrund möchte, muss man, wenn man deine Version verwendet, logischerweise td {padding:0} und td a {padding:[>0]} setzen, woraufhin bei height:100%; im Mozilla ein padding zwischen dem Blockelement und den Zellenrändern angezeigt wird. Das tritt natürlich nur auf, weil height:100% das padding nicht mit einschließt.
Also kann man die Hintergrundfarbe höchstens über td:hover ändern, womit aber nicht das Problem des paddings gelöst wäre. Egal wo man es unterbringt, es ist strenggenommen falsch, wenn es auf td a angewendet wird und gleichzeitig width/height:100% genutzt wird. Glücklicherweise ignorieren das scheinbar IE und Mozilla, sodass eine solche Lösung zumindest halb im IE und ganz im Mozilla funktionieren würde:
td {border:Xpx solid #XXX; padding:0; vertical-align:top; background-color:#XXX;}
td:hover {background-color:#XXX;}
td a {display:block; margin:0; padding:Xpx; color:#XXX; background-color:transparent; width:100%; height:100%;}
IE zeigt wie gesagt kein Hovereffekt an, und Opera spielt völlig verrückt. Was lernt uns das? ;) Mit einer feinen Dosis JavaScript kann man diese ganzen Probleme umgehen. CSS ist hier (noch) fehl am Platze.
das kommt IMO dem auch schon ziemlich nahe, ohne irgendwelche JS-Verenkungen zu machen ;-)
Ich würde konventionell mit <td onclick="window.location.href='...'" ><a href="...">...</a></td> arbeiten. Für die Effekte nimmt man AFAIR this.className - ich habe für das fanhost.de-Forum mal ein halbes Dutzend Versionen erstellt, welche genau einen solchen Effekt programmiert (Hintergrundfarbe und -bild sollten sich ändern bei Mouseover und die komplette Zelle anklickbar sein).
(von der space-minimierung will ich garnicht reden, wenn ich die eventhandler so umgehen kann... ;-) )
Die JavaScript-Version bereitet imho momentan weniger Probleme.
Grüße,
Mathias
Hi Mathias,
IE zeigt wie gesagt kein Hovereffekt an, und Opera spielt völlig
verrückt. Was lernt uns das? ;) Mit einer feinen Dosis JavaScript kann
man diese ganzen Probleme umgehen. CSS ist hier (noch) fehl am Platze.
http://www.schroepl.net/projekte/gzip_cnc/project.htm#credits
(um das Gegenbeispiel und die milden Spender mit einem einzigen Link zu nennen ... ;-)
Viele Grüße
Michael
Hi Michael,
IE zeigt wie gesagt kein Hovereffekt an, und Opera spielt völlig
verrückt. Was lernt uns das? ;) Mit einer feinen Dosis JavaScript kann
man diese ganzen Probleme umgehen. CSS ist hier (noch) fehl am Platze.
http://www.schroepl.net/projekte/gzip_cnc/project.htm#credits
(um das Gegenbeispiel und die milden Spender mit einem einzigen Link zu nennen ... ;-)
ja, das schwebte mir vor... ich war nur zu faul es ordentlich fertigzumachen, war nur ne vorlage ;-)
Fabian
Hallo, Michael,
IE zeigt wie gesagt kein Hovereffekt an, und Opera spielt völlig
verrückt. Was lernt uns das? ;) Mit einer feinen Dosis JavaScript kann
man diese ganzen Probleme umgehen. CSS ist hier (noch) fehl am Platze.
http://www.schroepl.net/projekte/gzip_cnc/project.htm#credits
(um das Gegenbeispiel und die milden Spender mit einem einzigen Link zu nennen ... ;-)
Es ging hier ja darum, wie man eine *Tabellenzelle* einer Datentabelle dazu bringen kann, anklickbar zu sein. Auf der genannten deiner Seite finde ich aber keine keine Tabellen. ;)
Bei einer Tabelle mit mehreren Spalten hilft eine Liste von a-Elemente mit display:block nicht weiter, siehe genanntes Beispiel http://www.partyof5.de/forum/ (geht AFAIR nicht mit Opera, dort ist noch eine alte Version in Verwendung, soll aber nur als Anwendungsbeispiel dienen).
Natürlich hast du recht, wenn es möglich ist, kann man es sich ganz einfach machen. Dass es bei diesem Problem jedoch wahnsinnig kompliziert ist, es mit CSS einigermaßen interoperabel zu lösen, habe ich versucht darzulegen. (Soll ich NS4.x ins Spiel bringen? *droh* ;))
Im Übrigen könnte man deine Navigation noch verbessern, denn ohne CSS ist sie schwer navigierbar. Ich nutze auf meiner Sterne-Seite eine ähnliche Navigation, meine Navigation degradiert aber zu:
--
Navigation: [ <strong>Aktuelles</strong> | <a>Tourtermine</a> | <a>Biografie</a> | <a>Diskografie</a> | <a>Liedtexte</a> | <a>Verknüpfungen</a> | <a>Gästebuch</a> | <a>Kontakt</a> ]
--
Während bei dir a) die Links zusammenkleben, b) die Grafik keinen Zeilenumbruch erzeugt (könnte man zumindest als unschönen Effekt bezeichnen) und c) die Auswahl in der Navigation nur suboptimal sichtbar wird:
--
gzip_cnc-Logo <a>gzip_cnc</a> <a>Cache</a> <a>Programmlogik</a> <a>Programm</a> <a>Status-Codes</a> <a>Protokoll</a> <a>Wirkung</a> <a>Installation</a> <a>Sicherheit</a>
Projekt
<a>Inhaltsverzeichnis</a> <a>Download</a>
--
Das <p>Projekt</p> zum kennzeichnen des ausgewählten Menüpunktes finde ich fehl am Platze, ich würde wie im Beispiel strong benutzen und dies dann bei aktiviertem CSS mit dem versehen, was du bereits für #nav p notiert hast (plus display:block latürnich).
Vorschläge: (Bitte als konstruktive Kritik verstehen. :))
1. alt-Attribut des Logos in eckige Klammern einschließen, damit die Grafik als solche erkennbar ist.
2. img-Element in ein div-Element einbetten.
3. unsichtbare Trennlinien zwischen die Links: <span style="display:none">|</span>. Siehe http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html#tech-divide-links, auch wenn ich den Server momentan nur über einen Proxy erreiche.
4. ausgewählten Menüpunkt mit einem Inline-Element kennzeichnen (em oder strong).
Grüße,
Mathias
Hallo Mathias,
(Soll ich NS4.x ins Spiel bringen? *droh* ;))
der fällt bei uns inzwischen unter "Kröten töten". ;-)
Vorschläge: (Bitte als konstruktive Kritik verstehen. :))
sehr gute Ideen - ist alles notiert.
(Herr, laß Zeit vom Himmel regnen ...)
Viele Grüße
Michael
Hi Mathias und Michael,
http://www.schroepl.net/projekte/gzip_cnc/project.htm#credits
(um das Gegenbeispiel und die milden Spender mit einem einzigen Link zu nennen ... ;-)
es ist eher umgekehrt, die meisten Missionare entpuppen sind als Spendenkeiler ;)
Im Übrigen könnte man deine Navigation noch verbessern, denn ohne CSS ist sie schwer navigierbar. Ich nutze auf meiner Sterne-Seite eine ähnliche Navigation, meine Navigation degradiert aber zu:
--
Navigation: [ <strong>Aktuelles</strong> | <a>Tourtermine</a> | <a>Biografie</a> | <a>Diskografie</a> | <a>Liedtexte</a> | <a>Verknüpfungen</a> | <a>Gästebuch</a> | <a>Kontakt</a> ]
Das ist eine Möglichkeit, mir gefallen hingegen Listen besser, da sie ohne CSS viel übersichtlicher sind (</archiv/2002/6/14094/#m80102>, letzter Absatz). Zwar nimmt die aktuelle Version weniger Platz in Anspruch, aber eine Liste... naja, Geschmackssache.
Das <p>Projekt</p> zum kennzeichnen des ausgewählten Menüpunktes finde ich fehl am Platze, ich würde wie im Beispiel strong benutzen und dies dann bei aktiviertem CSS mit dem versehen, was du bereits für #nav p notiert hast (plus display:block latürnich).
Die momentane Lösung finde ich sogar besser, weil ein Link auf die aktuelle Seite nicht sonderlich sinnvoll wäre.
- unsichtbare Trennlinien zwischen die Links: <span style="display:none">|</span>.
Das bläht den Code IMHO unnötig auf und wäre bei Listen nicht nötig. Ja Michael, ich weiß, dass sich redundante Teile sehr gut komprimieren lassen ;)
- ausgewählten Menüpunkt mit einem Inline-Element kennzeichnen (em oder strong).
Bei einer Liste ist das sinnvoll, nur als Ersatz für ein <p> hingegen nicht. IMHO.
LG Orlando
Hallo, Orlando,
Navigation: [ <strong>Aktuelles</strong> | <a>Tourtermine</a> | <a>Biografie</a> | <a>Diskografie</a> | <a>Liedtexte</a> | <a>Verknüpfungen</a> | <a>Gästebuch</a> | <a>Kontakt</a> ]
Das ist eine Möglichkeit, mir gefallen hingegen Listen besser, da sie ohne CSS viel übersichtlicher sind
Ja.
(</archiv/2002/6/14094/#m80102>, letzter Absatz).
Ich verstehe den Zusammenhang nicht ganz... naja.
Zwar nimmt die aktuelle Version weniger Platz in Anspruch, aber eine Liste... naja, Geschmackssache.
Ja, ich gebe dir vollkommen recht.
Das <p>Projekt</p> zum kennzeichnen des ausgewählten Menüpunktes finde ich fehl am Platze, ich würde wie im Beispiel strong benutzen und dies dann bei aktiviertem CSS mit dem versehen, was du bereits für #nav p notiert hast (plus display:block latürnich).
Die momentane Lösung finde ich sogar besser, weil ein Link auf die aktuelle Seite nicht sonderlich sinnvoll wäre.
Du hast mich falsch verstanden, das wollte ich keinesfalls vorschlagen: "ich würde wie im Beispiel strong benutzen". Kein a-Element, sondern strong, damit ersichtlich wird, welche Seite momentan ausgewählt ist.
Ich glaube, es herrscht Konsens darüber, dass an der Stelle, wo in der Navigation auf den übrigen Seiten der Link zur ausgewählten Seite steht, keine Lücke bleiben darf, sondern der Titel der ausgewählten Seite genannt wird, und das beste, dies bei einer Listennavigation zu kennzeichnen, ist em oder strong.
- unsichtbare Trennlinien zwischen die Links: <span style="display:none">|</span>.
Das bläht den Code IMHO unnötig auf
Das ist kein Argument wenn es um Zugänglichkeit geht. Überhaupt sind alle menschenlesbaren Markupsprachen im Vergleich zu Binärformaten extrem platzverschwendend. Die 243 Byte (strlen('<span class="inv">|</span>\n')*9) für die Navigation blähen ein Dokument nicht auf. Da könnte man auch argumentieren, dass eine Liste den Code aufbläht. ;)
und wäre bei Listen nicht nötig.
Du irrst. ;) Ich lese auf auf der W3C-WAI-DE Mailingliste mit, AFAIR tritt bei Listen dasselbe Problem in Verbindung mit Braille-Displays auf wie bei <a>Link 1</a> <a>Link2</a>, sie sind nicht voneinander unterscheidbar (Frage mich nicht nach den Details, die Liste hat AFAIK kein Archiv, sonst würde ich suchen).
<ul>
<li><a>Link 1</a></li>
<li><a>Link 1</a></li>
</ul>
Eine solche normale Linkliste hätte dieselben Probleme, auch wenn sie gegenüber Non-CSS-Browsern bzw. -Darstellungsarten sicherlich Vorteile hat und einfacher wahrgenommen werden kann (weshalb eine solche Liste vorzuziehen ist, das sehe ich ein).
IIRC bemängelt Bobby solche Listen auch. Hm, nee, anscheindend doch nich, aber das muss noch nichts heißen. :) Eine zugängliche Liste sollte Trennzeichen zwischen den Links haben, beispielsweise:
<ul>
<li>[<a>Link 1</a]</li>
<li>[<a>Link 2</a]</li>
</ul>
Durch eine Definitionsliste kann man sich das sparen:
<dl>
<dt><a>Seitentitel</a></dt>
<dd>Seitenbeschreibung</dd>
</dl>
- ausgewählten Menüpunkt mit einem Inline-Element kennzeichnen (em oder strong).
Bei einer Liste ist das sinnvoll, nur als Ersatz für ein <p> hingegen nicht. IMHO.
Ein p-Element hat in diesem Kontext keinen semantischen Wert, es ist sogar völlig fehl am Platze, es ist lediglich ein willkürlich ausgewähltes Blockelement, welches für die Darstellung benötigt wird.
Die Navigation wird dadurch völlig auseinandergerissen, weil in einer Liste von Inline-Links plötzlich ein Blockelement auftaucht, die Navigation jedoch nicht zuende ist. Als Container für <strong> wäre es vielleicht hilfreich (besser wäre dann div), aber dann müssten die a-Elemente auch in Blockelementen (div) untergebracht werden, damit der Zeilenumbruch keine Verwirrung stiftet. Folglich: eine Liste wäre, wie du sagst, das beste. Dennoch bleibt die Notwendigkeit, den ausgewählten Menüpunkt hervorzuheben:
<ul>
<li><a>Link</a></li>
<li><strong>Link</strong></li>
<li><a>Link</a></li>
</ul>
Ich persönlich setze sogar extra noch einen title dazu, à la "Sie sind hier".
Grüße,
Mathias
Hallo Tom,
da stand sicher ein Papierprospekt Pate, oder?
Jein. Das ganze ist natürlich nach dem Katalog aufgebaut, aber in dem Katalog ist es sehr viel weniger "bleiwüstig", weil nicht immer noch Navigation da ist, und vor allem nicht die vielen Links zu Zeichnungen, usw., im Katalog sind dann ein paar wichtige abgebildet, der ist deswegen eher eine CAD-Wüste.
Ich finde es relativ gut gelöst, auch wenn die Seite eben internetmäßig leichter sein könnte. Man könnte Bereiche auf Extraseiten auslagern.
Ja, habe ich mir auch schon überlegt, aber da gerate ich eben immmer in ein grundlegendes Dilemma: wenn ich das ganze auf eine andere Seite packe, und das z.B. mit "PDFs und Zeichnungen"
verlinke, dann sieht der User nicht, was es da noch geben könnte, und das ist je nach Seite verschieden, manchmal gibts gar nichts, manchmal ein paar PDFs, manchmal wie bei der Beispielseite auch sehr viele. Ich denke mir, wenn da ein PDF-Button ist, und ein User hat ein paarmal auf den Button geclickt, und nicht das gefunden, was er sucht, dann wird er den Button ignorieren. Ich könnte zwar noch die Anzahl der vorhandenen PDFs anzeigen lassen (die Seiten kommen sowieso aus einer Datenbank). Aber da bin ich mir dann grundlegend nicht so sicher, ob dieses "Verstecken" weiterer Informationen (bzw. in diesem Fall Downloadmöglichkeiten) hinter einem Link nicht einfach weniger Reaktionen des Users hervorruft. Irgendeinen psychologischen Grund muß es ja geben, daß z.B. Portalseiten wie Yahoo ihre Seite mit wahnsinnig vielen Links zukleistern, dort könnte man ja auch sehr vieles in Unterkategorien mit ein paar netten Buttons packen. Vielleicht vermitteln "Bleiwüsten" mit Links, auch wenn sie grafisch unschön sind, so ein unterschwelliges "Egal was Du suchst, wir haben hier genügend Informationen..." - Gefühl, aber ganz bin ich mir da auch noch nicht...
Ich hätte halt gerne eine (magische) Möglichkeit gehabt, diesen (vermuteten) Effekt beizubehalten, und trotzdem ein "locker-flockiges" Design zu haben ;-).
Wie gesagt, trotzdem finde ich es gut gelöst.
Danke :-)!
Habe mir auch gleich was abgeguckt: Linkes Frame,
Du denkst hoffentlich nicht, daß ich Frames benutze ;-)? Deine Frage wurde mittlerweile ja schon beantwortet, und, um ehrlich zu sein, ich habe mir den mouseover mit Tabellenzellen auch nur hier aus dem Archiv abgekuckt ;-)
Viele Grüße
Stephan
Hallo,
ich muß Dich "leider auch" enttäuschen. Ich empfinde diese Bleiwüste als überhaubt nicht störend. Ja, die Seite erstrahlt dadurch auch nicht gerade in Schönheit, aber daß ist auch nicht ihre erste Aufgabe. Es ist ja nicht so, daß sich "Schrittmotoren" eignen, um einen unbedarften, der sich bis dato sogar noch nicht mal für Schrittmotoren interesierte, eine spannede und leichte Einführung in die wunderbare Welt der Schrittmotoren zu präsentieren, leicht im Design, locker in der Aufmachung, voll Überraschungen.... ;-)))
Wer sich für Schrittmotoren interesiert, braucht einen ;-) Wenn ich einen Treiber suche, dann rattere ich auch freiwllig längere Linkliste mit dem Zeigefinger am Bildschirm klebend durch, und je genauer die VersionsInformationen sind, desto mehr freue ich mich. Textlastigkeit und eine relative Tristeste beim Design sind da wurscht. Nein, deine Seite gefällt mir so sehr gut. (wie gesagt, als Simulant eines Schrittmotorsucher....)
Wenn Du optisch schöne Seiten machen möchtest, dann such Dir ein anderes Thema ;-)))) (Nein nein, nicht ernst gemeint, denn auch "optisch schön" ist ein sehr relativer begriff und hängt eben auch damit zusammen, was man über die optik vermitteln will. Und Du willst "zugänglichkeit zu einer breiten Produktpallette" vermitteln..... ist gelungen.... (brauche nur leider keinen Schrittmotor ;-))))
Chräcker
Hallo Chräcker,
ich muß Dich "leider auch" enttäuschen.
Das ist ja nun auch egal, Bio hat Euch Nappsülzen sowieso alle entlassen ;-)
...spannede und leichte Einführung in die wunderbare Welt der Schrittmotoren zu präsentieren, leicht im Design, locker in der Aufmachung, voll Überraschungen.... ;-)))
Soll ich etwa jetzt das Projekt mit den netten jungen Frauen, die die Vorteile eines Schrittmotors in einer Flash-Animation erklären, wieder streichen ;-)?
Wer sich für Schrittmotoren interesiert, braucht einen ;-)
Aber vielleicht nicht einen von dieser Firma, prinzipiell ist das Problem da doch nicht anders als bei anderen Dingen, oder?
Wenn Du optisch schöne Seiten machen möchtest, dann such Dir ein anderes Thema ;-))))
Nein, das überlasse ich lieber denen, die es können, wie z.B. Dir ;-).
(brauche nur leider keinen Schrittmotor ;-))))
Bist Du Dir da wirklich sicher? Soll ich Dir nicht vielleicht doch mal eine Flash-Ani oder einen Werbefilm zeigen? Z.B. wie angenehm es sein kann, wenn ein Roboter die Post aufmacht, und mit der geballten Kraft eines Schrittmotors[tm] einen Eingangsstempel paßgenau in die rechte obere Ecke plaziert?
Viele Grüße
Stephan