Diskussion:Hauptseite/ Schwesterprojekte

Die Vorlage wurde aus der Wikipedia übernommen. Autoren dort:

Triebtäter, Bdk, Elian, Trainspotter

Siehe auch dortige Versionsgeschichte

Wikivoyage fehlt noch

Mir fällt allerdings keine gute Idee ein, um es einzubinden. --NeuerNutzer2009 22:34, 26. Feb. 2013 (CET)

Zitat von der Diskussion auf der Hauptseite

Schwesterprojekte auf der Hauptseite Auf der Hauptseite fehlt noch ein Link zu Wikivoyage (und Wikidata). Ich habe keine gute Idee, wie man den Layout-technisch schön einfügen könnte. Oder kopieren wir die Leiste einfach aus der Wikipedia? --NeuerNutzer2009 15:25, 1. Mär. 2013 (CET) Eigentlich gefällt mir unsere Darstellung besser. Aber fünf Einträge pro Zeile dürfte etwas eng aussehen. Wenn niemand eine bessere Idee hat, ist das Kopieren wohl praktischer. -- Jürgen 16:24, 1. Mär. 2013 (CET) Ich habe mal 3 Vorschläge: Diskussion:Hauptseite/_Schwesterprojekte#Layoutvorschlag_1. Seht dieses als Arbeitsgrundlage, oder nutzt es als Vorlage für eigene Ideen. --mjchael 23:13, 1. Mär. 2013 (CET)

Michaels Vorschlag 1 gefällt mir am besten: deutlich, übersichtlich, erweiterungsfähig. Erst auf schmalen Bildschirmen bzw. Fenstern (unter 800 Pixel Breite) wirkt es gedrungen und wird nicht vollständig angezeigt. (Wie sieht es auf mobilen Geräten aus?) Ich hatte kurz überlegt, ob man die beiden letzten Einträge über colspan anders verteilt oder zentriert; aber das sieht eher schlechter aus. -- Jürgen 10:27, 2. Mär. 2013 (CET)

Anmerkung zum Vorschlag 4: Das könnte ein sinnvoller Kompromiss sein zwischen der möglichen Bildschirmgröße und der gesamten Anzeige. Allerdings ist der Informationsgehalt nach dem Ausklappen nicht so viel größer.

Eine bessere Lösung liefert übrigens Vorlage:Klappbox, die seit einiger Zeit existiert und ohne das Problem mit dem automatischen Ein-/Ausklappen auskommt. (Warum mein erster Kommentar die Anzeige völlig durcheinander gebracht hat, ist mir schleierhaft; deshalb setze ich diese Anmerkung hierher.) -- Jürgen 12:59, 3. Mär. 2013 (CET)

Mir gefällt ebenfalls Vorschlag 1 am Besten, ich würde allerdings vorschlagen, statt einer Tabelle die CSS3-Eigenschaften "column-width" und "column-gap" zu verwenden. So kann der Browser abhängig von der Breite des Fensters die Anzahl der Spalten anpassen. Eventuell sollte für sehr breite Monitore mit "max-width" (für das umschließende Element) eine Maximalbreite festgelegt werden, mit der die Anzahl der Spalten nach oben begrenzt werden könnte. ("display" müsste dann wahrscheinlich auf "inline-block" stehen.) Gruß --Prog 19:10, 3. Mär. 2013 (CET)

Von der Vorschlägen würde ich auch die Nr. 1 vorziehen, könntest du die CSS-Änderungen umsetzen? --NeuerNutzer2009 13:11, 4. Mär. 2013 (CET)

Layout 4 ist auch nur eine Idee, die sich aber weiter ausbauen ließe. (Sollte ja bloß Brainstorming sein.) Auf die CSS3-Methode bin ich neugierig, jedoch sollte diese CSS2-Kompatibel sein für Leute, die noch keinen CSS3-fähigen Browser haben. Ich habe schon mit dem Gedanken Div- oder Span-Container mit der CSS-Float-Eigenschaft gespielt, hatte dann aber keine Zeit mehr dieses umzusetzen. Wenn es aber mit CSS3 besser geht, bin ich mal auf das Ergebnis gespannt. Gruß --mjchael 18:12, 4. Mär. 2013 (CET)

Hab es unter Layoutvorschlag 5 umgesetzt. Getestet mit Firefox und Chrome. Opera sollte das ebenfalls können, allerdings habe ich den derzeit nicht installiert. Außerdem stellen die sowieso gerade auf Webkit als Unterbau um, so dass er sich zukünftig wie Chrome verhalten sollte. Den Internet Explorer müsste mal noch jemand prüfen, der is ja immer das größte Problem.

Die Kombination von "display:inline-block;" und "width:100%;" könnte man in diesem Fall eigentlich auch kurz als "display:block;" schreiben, allerdings geht Webkit dann ziemlich brutal bei der Trennung vor. (Die Elemente werden beim Spaltenumbruch einfach in der Mitte durchgeschnitten.)

Gecko (Firefox), Webkit (Chrome, Safari, zukünftig Opera) und Presto (aktuell Opera) unterstützen dass glaube ich schon eine ganze Weile. Bei Trident (Internet Explorer) kenne ich den Stand der Dinge nicht. Da alle verbreiteten Desktop-Browser (mit Ausnahme des IE) sich unzwischen selbst aktuell halten, sollten wir eigentlich auch keine großen Probleme mit veralteten Browsern haben. Im Mobil-Bereich sieht das zwar etwas anders aus, aber da wird es vermutlich ohnehin nur auf eine Spalte hinauslaufen. Das entspricht praktischerweise genau dem Verhalten bei fehlender CSS3-Unterstützung. Gruß --Prog 23:51, 6. Mär. 2013 (CET)

IE macht Ärger: IE 9.0.13 (KB 2792100) unter Win7 Home Premium 64-bit zeigt alles in einer einzigen Spalte untereinander - unabhängig von der Breite des Fensters.

Ansonsten sieht Vorschlag 5 fast sehr gut aus. Lediglich die vertikalen Abstände sind für meinen Geschmack etwas zu groß; aber das sollte sich regeln lassen (wenn meine CSS-Kenntnisse auch nicht weit genug reichen). -- Jürgen 08:57, 7. Mär. 2013 (CET)

Vielleicht sollte man im Sinne des Konzeptes des gesichterten Wissens von wikibooks erstmal abwarten, wann solch ein CSS3-Spaltenlayout wirklich zur Empfehlung wird, dann kann man die experimentellen Präfixe auch weglassen. Zumal der Vorschlag ja auch Tabellen verwendet. Eine tabellenartige Darstellung ohne Verwendung von Tabellen kann man ja auch mit den entsprechenden Werten für display erreichen, die gibt es bereits in CSS2 ;o) Die eigentliche Umsetzung gemäß dem Arbeitsentwurf für CSS3 für ein Spaltenlayout sollte natürlich ohne eine Tabelle auskommen, das ist ja der Sinn des Arbeitsentwurfes, den Mißbrauch von Tabellen für sowas zu reduzieren. Weitere Möglichkeiten sind die Verwendung von display 'inline-block' oder auch eine Kombination von display 'block' mit float, was den Vorteil hat, daß sich die Anzahl der Blöcke pro Zeile automatisch aus der verfügbaren Breite ergibt. Doktorchen 11:28, 7. Mär. 2013 (CET)

Gute Idee, ich hab mal noch eine Version 6b entworfen, bei der die Höhe angegeben wird, was etwas sauberer aussieht. Mit Firefox hatte ich das CSS3 noch mal in Version 10 getestet, der kann das bereits, aber wenn der IE Version 9 da noch nicht mitspielt, dann sollten wir momentan noch darauf verzichten. Vorschlag 6 sieht ja ohnehin ähnlich aus. (Vertikale Abstände bei 5 hab ich noch mal angepasst.)

Die Verwendung von Tabellen zur Darstellung lehne ich in normalen HTML auch vollständig ab, da gäbe es in jedem Fall bessere Varianten. Hab sie hier (wenn auch mit Bauchschmerzen) verwendet, weil Wiki-Quelltext einfach kürzer und vor allem leichter zu verstehen ist. ;) --Prog 01:38, 8. Mär. 2013 (CET)

Ich weiß nicht ob das so beabsichtigt ist, aber bei meinem FF (aktuell Ver. 19) wird der Vorschlag 5 und 6b nur zweispaltig angezeigt, der Vorschlag 6a dagegen (wie beabsichtigt) fünfspaltig. (breiter Bildschirm). --mjchael 06:32, 8. Mär. 2013 (CET)

Das sollte eigentlich nicht so sein. Es gibt aus meiner Sicht keinen technischen Grund für genau 2 Spalten. Ich habe mal mit http://browsershots.org getestet, wie Version 6b unter verschiedenen auch älteren Browsern aussieht. In keinem dieser Fälle scheint es Probleme mit der Anzeige zu geben. Vielleicht gibt es bei dir aus irgendeinem Grund ein störendes Element, welches die float-Elemente daran hindert, sich korrekt anzuordnen. Versuch mal Rechtsklick -> "Element untersuchen" und dann in der erscheinenden Leiste auf "3D-Ansicht", da sollte man so was sehen. Die Tabellen sollten bei 6b im Gegensatz zu 6a jeweils die gleiche Höhe und Breite haben. --Prog 23:03, 8. Mär. 2013 (CET)

Irgendetwas scheint zu breit zu sein. Bei normaler Schrift (<Strg>+<0>) erscheinen bei mir nur 2 Spalten. Verkleinere ich die Schrift um einen Grad (<Strg>+<->) dann habe ich gerade mal 3 Spalten (trotz Whide-Screen). Die Anzahl zu 6a ist also deutlich niedriger. Es sieht aber mit weniger Zeilen für meinen Geschmack besser aus. --mjchael 23:29, 8. Mär. 2013 (CET)

Bei meiner Schriftgröße sind das auch eher zwei Spalten, mache ich das Fenster allerdings breiter als 1400px, werden es drei. Ist denn bei deiner Schriftgröße überhaupt nach rechts noch ausreichend Platz (gut 20em) für eine dritte Spalte, wenn nur zwei angezeigt werden? Bei mir kommt das ungefähr so hin. Bei Anwensenheit von Tabellen kann der browser natürlich auch einige Breitenangaben ignorieren, um die Tabelle besser lesbar zu machen, ist hier aber wohl eher unwahrscheinlich. Wegen der Kombination von Pixelgraphik mit Text läßt sich die Breite ja weder in px noch in em ordentlich abschätzen - und das CSS3-Modul, welches eine additive Kombination von px und em bei einer Längenangabe erlauben würde (calc(70px + 10em)), ist auch erst auf dem Niveau eines 'Candidate Recommendation' - kann man also schonmal ausprobieren, aber eher noch nicht auf normalen Seiten verwenden, daher eher wie unten skizziert vorgehen, um eine bessere Schätzung der benötigten Breite zu erhalten. Bei meiner Schriftgröße reichen vermutlich auch 15em statt 20em, bei kleinerer Schrift spielt natürlich die Pixelgraphik eine größere Rolle, da kann es sein, daß 20em gerade ausreichen. Von daher also nicht so überraschend, daß bei dem Inhalt eine Breitenangabe nur in em oder px nicht sonderlich sinnvolle Ergebnisse liefert. Doktorchen 13:02, 9. Mär. 2013 (CET)

Wie Jürgen unter 6a richtig anmerkt, kann es bei dieser Version Probleme mit der Anordnung geben. Ich habe das mal in einem Bild deutlich gemacht, bei dem ebenfalls 4 Spalten zum Einsatz kamen: http://img835.imageshack.us/img835/5120/vergleichlayout6a6bschw.png

In der 3D-Ansicht darunter (die wurde mit 5 Spalten erstellt) sieht man bei 6a, dass die einzelnen Tabellen zwar alle die gleiche Breite haben, aber eine unterschiedliche Höhe. (Rote Markierungen.) In Kombination mit "float" führt das etwa bei 4 Spalten zu dieser seltsamen Anordnung.

Außerdem habe ich in 6b den Grafiken allen die gleiche Breite bei zentrierter Anordnung eingeräumt, was zwar mehr Platz braucht, aber meiner Meinung nach schöner aussieht. (Blaue Markierungen.)

Der zweite Grund, warum 6b pro Spalte mehr Platz benötigt, ist der größere Wert bei "width". 6a geht da an die untere Grenze, bei der Breite. Leider kann die Breite von Schrift je nach Betriebssystem und Browser leicht Variieren. Wenn also bei irgendjemandem die Schrift geringfügig breiter ist, wird "Wikimedia Commons" als der breiteste Schriftzug auf zwei Zeilen umgebrochen. Da durch erhöht sich wiederum die Höhe des Elements. Bei 6b gebe ich aber eine feste Höhe an, wenn da also ein Umbruch stattfinden kann, müsste die Höhenangabe noch größer gewählt werden. Ich werde das unten mal noch demonstrieren. --Prog 16:52, 9. Mär. 2013 (CET)

Layoutvorschlag 1

	Meta-Wiki Projektkoordination		Wikipedia Enzyklopädie		Wikimedia Commons Mediensammlung		Wiktionary Wörterbuch
	Wikisource Quellensammlung		Wikiquote Zitate		Wikinews Nachrichten		Wikiversity Lerninstitution
	Wikidata Wissensdatenbank		Wikivoyage Reiseführer

Layoutvorschlag 2

Meta-Wiki Projektkoordination	Wikipedia Enzyklopädie
Wikimedia Commons Mediensammlung	Wiktionary Wörterbuch
Wikisource Quellensammlung	Wikiquote Zitate
Wikinews Nachrichten	Wikiversity Lerninstitution
Wikidata Wissensdatenbank	Wikivoyage Reiseführer

Layoutvorschlag 3

Meta-Wiki   Wikipedia   Wikimedia Commons   Wiktionary   Wikisource   Wikiquote   Wikinews   Wikiversity   Wikidata   Wikivoyage  

Layoutvorschlag 4

Dieser Vorschlag macht nur Sinn, wenn man eine zweite Navigationsleisten auf der Hauptseite anbringt:

andere Navigationsleiste

anderer Inhalt

 

Ohne diese zweite Navigationsleiste ist die Box nicht eingeklappt.

Hier sollte man nicht die Vorlage "Navigationsleiste" verwenden, damit der Inhalt leichter zu bearbeiten sind. Sonst müsste man die Tabellen mit {{!}} statt | und {{!!}} statt || und {{!-}} statt |- zeichnen, was die Sache nur verkomplizieren würde.

Meta-Wiki  Wikipedia  Commons Wiktionary  Wikisource
Wikiquote  Wikinews  Wikiversity  Wikidata  Wikivoyage

Schwesterprojekte

	Meta-Wiki Projektkoordination		Wikipedia Enzyklopädie		Wikimedia Commons Mediensammlung		Wiktionary Wörterbuch
	Wikisource Quellensammlung		Wikiquote Zitate		Wikinews Nachrichten		Wikiversity Lerninstitution
	Wikidata Wissensdatenbank		Wikivoyage Reiseführer

Hier ist eine Navigation auch im eingeklaptem Zustand möglich.

Layoutvorschlag 5

Nutzt die CSS3-Eigenschaften "column-width" und "column-gap" um die Anzahl der Spalten dynamisch an die Fensterbreite anzupassen. Browser die dies noch nicht unterstützen, zeigen die Elemente alle untereinander an.

Meta-Wiki Projektkoordination

Wikipedia Enzyklopädie

Wikimedia Commons Mediensammlung

Wiktionary Wörterbuch

Wikisource Quellensammlung

Wikiquote Zitate

Wikinews Nachrichten

Wikiversity Lerninstitution

Wikidata Wissensdatenbank

Wikivoyage Reiseführer

Layoutvorschlag 6

Version 6a

Nutzt Div-Container mit style="float:left; min-width:200px;". Eine Breite festzulegen ist aber wegen den unterschiedlichen Schriftauflösungen ein wenig risikoreich. Die Commons müssen am Schluss bleiben. Durch die breitere Schrift kann sie sonst das Design zerschießen. --mjchael 20:33, 7. Mär. 2013 (CET)

Auf die Breite habe ich schon mal bei 6a verzichtet, aber dann stimmt die Ausrichtung bei den einzelnen Boxten nicht mehr. Ich habe also bei der Schrift auf die "em" Angabe verzichtet, aber genug Luft gelassen, damit auch große Schriften funktionieren. Auch bei sehr großer Schrift sieht es bei mir ordentlich aus. Gab es da bei jemanden Darstellungsprobleme? --mjchael 15:44, 9. Mär. 2013 (CET)

Ja, bei mir sieht es nicht korrekt aus. Unter FF 19.0.2 (Win7 Home Premium 64 bit) mit etwa 1200 Pixel Breite werden die Blöcke wie folgt auf 4 Zeilen mit insgesamt 4 Spalten aufgeteilt (rechts bleibt Platz für nicht ganz eine weitere Spalte): -- Jürgen 16:11, 9. Mär. 2013 (CET)

 Meta-Wiki   Wikipedia     Wiktionary   Wikisource
                                        Wikiquote
 Wikinews    Wikiversity   Wikidata     Wikivoyage
 Commons

Bei mir ragt der Text teilweise nach rechts in die benachbarte Pixelgraphik rein, was an der Dimensionierung in px liegt, unten als Variante 6c mal mit getrennten Abmessungen und ohne Tabelle. Doktorchen 16:36, 9. Mär. 2013 (CET)

Ich müsste jetzt dieses Problem gelöst haben; und zwar durch einen Style-Eintrag von min-height:47px; (das entspricht der Höhe des größten Icons). In den von mir getesteten Browsern wird nun alles fehlerfrei angezeigt. --mjchael 00:12, 10. Mär. 2013 (CET)

Das kann ich für mich bestätigen. Jetzt gibt es eine kleine "Unschönheit": Wenn der Platz für vier Spalten gerade nicht reicht, dann werden die Blöcke neu angeordnet. Dann sieht es aber so aus, als wenn rechts noch Platz für eine weitere Spalte wäre. Schöner wäre dann eine prozentuale Verteilung, was aber zurzeit vermutlich nicht möglich ist. Deshalb kann man dieses neue Darstellungsproblem auch ignorieren. -- Jürgen 11:29, 10. Mär. 2013 (CET)

Bei mir ragt wie gehabt 'Projektkoordination' in die Wikipedia-Kugel rein und 'Wissensdatenbank' in das Symbol von Wikivoyage. Ich glaube auch nicht, daß sich daran etwas ändern läßt, wenn man eine minimale Höhe angibt. Wie bei Vorschlag 6c oder auch 7 läßt sich das vermeiden, wenn man die Breite jeden Eintrages nicht in Pixeln (oder auch em wie in 6b) festlegt. Ich verwende z.B. eine Auflösung von 120dpi und eine entsprechend große Schrift. Bei anderen Rechnern mit einer anderen Kombination von Auflösung, Schriftgröße und typischen Betrachtungsabstand sehe ich das auch nicht. Gleichwohl, wenn Leute, die nicht so gut gucken können, eine wirklich große Schrift gleich bei welcher Auflösung eingestellt haben, wird der Effekt zwangsläufig noch viel dramatischer auftreten. Das läßt sich also generell auch nicht vermeiden, wenn man jetzt eine Breite von 240px oder sowas angibt, was auch bei mir reichen würde, aber eben bei Leuten mit Sehschwäche immer noch nicht. Die min-height in Pixeln könnte hingegen bei 6c und kleiner Schrift sinnvoll sein, damit da durch die unterschiedlichen Höhen der Graphiken keinen Blödsinn produzieren, den ich nur mit einem anderen Rechner mit niedrigerer Auflösung und kleinerer Schrift sehen kann - die Ergebnisse dort würden es wohl auch nahelegen, bei 6c die Breite des Textes für 'Wikimedia Commons' noch etwas großzügiger zu dimensionieren oder das auf 'Wikimedia' zu kürzen. 7 läßt sich sicher auch noch leicht an weitere Bedürfnisse einer regelmäßigen Anordnung anpassen, bei 6a und 6b sehe ich da wenig Chancen, daß das allgemein funktionieren kann. Doktorchen 15:25, 10. Mär. 2013 (CET)

Wir können statt "width" "min-width" verwenden, dann werden die Elemente nötigenfalls breiter, sind dann aber bei deinen Einstellungen nicht mehr sauber in Spalten eingeordnet. Trotzdem wäre das besser als diese Version. --Prog 18:38, 10. Mär. 2013 (CET)

Erledigt. Ich habe den Quellcode vereinfacht (Divs entfernt), width durch min-width ersetzt, und alle Logo-Zellen auf die Breite des breitesten Logos gesetzt und zentriert. Ich hoffe damit alle derzeitigen Probleme beseitigt zu haben. --mjchael 00:56, 18. Mär. 2013 (CET)

Meta-Wiki Projektkoordination

Wikipedia Enzyklopädie

Wiktionary Wörterbuch

Wikisource Quellensammlung

Wikiquote Zitate

Wikinews Nachrichten

Wikiversity Lerninstitution

Wikidata Datenbank

Wikivoyage Reiseführer

Wikimedia Commons Mediensammlung

Version 6b

Arbeitet nur mit Tabellen. Mit "display:block;" um eine Höhe definieren zu können, was eine saubere Anordnung der Elemente gewährleistet. "width:20em;" und "height:4.3em;" in "em" um die Werte rellativ zur Schriftgröße zu setzten. Sollte auch mit allen älteren Browsern funktionieren, trotzdem sind die Wertangaben weiter etwas problematisch. --Prog 01:38, 8. Mär. 2013 (CET)

Das Problem von 6 a und b hängt damit zusammen, daß zum einen Tabellen verwendet werden, zum anderen innerhalb der Größenangabe sowohl eine Pixelgraphik als auch Text steht - zu Pixelgraphik paßt einen Breitenangabe in px gut, zu Text eine in em oder ex.

Eine Lösung könnte darin bestehen, natürlich keine Tabellen zu verwenden und die Breite für eine Box mit der Graphik in px anzugeben, was ja bereits gemacht wird, und eine Box daneben mit einer Breite in em. Die Gesamtbreite kann das Darstellungsprogramm dann automatisch bestimmen, wenn man display 'inline-block' verwendet oder auf bei der Verwendung von float - da ist es also in diesem Falle sinnvoll, nicht die Breite des Elementes festzulegen, wo float wirksam wird, sondern für die darin befindlichen Kindelemente. Details sind wie immer bei CSS ein kurzweiliges Puzzle-Spiel ;o) Doktorchen 10:48, 8. Mär. 2013 (CET)

Meta-Wiki Projektkoordination

Wikipedia Enzyklopädie

Wiktionary Wörterbuch

Wikisource Quellensammlung

Wikiquote Zitate

Wikinews Nachrichten

Wikiversity Lerninstitution

Wikidata Wissensdatenbank

Wikivoyage Reiseführer

Wikimedia Commons Mediensammlung

Mit geringer Breite, bei einer Höhe, die einen Zeilenumbruch erlaubt:

Meta-Wiki Projektkoordination

Wikipedia Enzyklopädie

Wiktionary Wörterbuch

Wikisource Quellensammlung

Wikiquote Zitate

Wikinews Nachrichten

Wikiversity Lerninstitution

Wikidata Wissensdatenbank

Wikivoyage Reiseführer

Wikimedia Commons Mediensammlung

Version 6c

Mal als div+style-Orgie, leider kann man das hier kaum eleganter machen, weil offenbar der wiki-parser kräftig was ändert und zusätzliche Elemente einfügt - beziehungsweise deswegen auch Absätze im Bedarfsfalle vorzeitig schließt / schließen muß. Das beinhaltet dann die Idee, beim float keine Breite zu setzen, sondern bei der Pixelgraphik in px und dem Text in em. Den letzte Eintrag mit recht viel Text habe ich mal etwas breiter gewählt, um einen Dreizeiler zu vermeiden... Doktorchen 16:36, 9. Mär. 2013 (CET)

Meta-Wiki
Projektkoordination

Wikipedia
Enzyklopädie

Wiktionary
Wörterbuch

Wikisource
Quellensammlung

Wikiquote
Zitate

Wikinews
Nachrichten

Wikiversity
Lerninstitution

Wikidata
Wissensdatenbank

Wikivoyage
Reiseführer

Wikimedia
Mediensammlung

Layoutvorschlag 7

Ich hab auch noch mal was mit inline-block gemacht, hat aber aus meiner Sicht zwei Nachteile

1. Anordnung ist nicht regelmäßig
2. "inline-block" wird von Firefox < Version 3 noch nicht unterstützt. Bei IE < Version 8 könnte das ebenfalls der Fall sein, sofern "div" verwendet. ("span" müsste er können.)

Meta-Wiki
Projektkoordination

Wikipedia
Enzyklopädie

Wiktionary
Wörterbuch

Wikisource
Quellensammlung

Wikiquote
Zitate

Wikinews
Nachrichten

Wikiversity
Lerninstitution

Wikidata
Wissensdatenbank

Wikivoyage
Reiseführer

Wikimedia Commons
Mediensammlung

Welche Variante gefällt euch am besten

Um ein wenig die Meinungen zusammenzutragen, habe ich mal diese Überschrift eröffnet. Da dies der Übersicht dienen soll, schlage ich vor, Diskussionen weiter oben zu führen. Einen Kommentar zur Begründung kann jeder zu seinem Votum angeben. --Prog 18:38, 10. Mär. 2013 (CET)

Layout 6a

• IMHO das beste Verhältnis zwischen Breite, Höhe und Leerraum (ohne Berücksichtigung möglicher Darstellungsprobleme). -- Jürgen 09:19, 11. Mär. 2013 (CET)
• Gefällt mir auch am besten. „Wissensdatenbank“ könnte m.M.n. auch einfach nur „Datenbank“ heißen, Wikidata bezeichnet sich immerhin selbst so. --NeuerNutzer2009 16:45, 11. Mär. 2013 (CET)
• 6a. Nachdem ich den Quellcode nach Vorlage von 6b vereinfacht habe, und die Breiten und Höhen nach den Tipps von meinen Kollegen angeglichen habe, „Wissensdatenbank“ zu „Datenbank“ gekürzt habe, gefällt es mir auch am besten. --mjchael 01:04, 18. Mär. 2013 (CET)

Layout 6b

• Die Anordnung der Grafiken gefällt mir besser als bei 6a und 6c. Das Design funktioniert auch mit alten Browsern. Höhe und Breite der einzelnen Einträge lässt sich nötigenfalls noch anpassen. --Prog 18:38, 10. Mär. 2013 (CET)
• 6b hat den einfacheren Quelltext, der Rest ist nur noch eine Frage der Breite und Höhe. Mir gefällt es aber etwas dichter wie bei 6a (reine Platzgründe) --mjchael 07:13, 11. Mär. 2013 (CET)

Entscheidung?

Hat noch jemand Darstellungsprobleme oder Einwände gegen den Vorschlag 6a? Soweit ich es beurteilen kann, gibt es inzwischen keine Darstellungsprobleme mehr, und auch die Symbole sind korrekt untereinander ausgerichtet. Ansonsten würde ich diese Diskussion gerne zu einem vorläufigen Abschluss bringen, und den Vorschlag umsetzen. --mjchael 09:04, 19. Mär. 2013 (CET)

Von meiner Seite aus gibt es keinerlei Einwände mehr gegen 6a, lediglich noch eine kleine Anmerkung/Frage zum Quelltext: Innerhalb der Icons taucht der Teil |<nowiki></nowiki> auf. Gibt es dafür einen technischen Grund? Ich habe das bei meinen Beispielen immer weggelassen, weil es – soweit ich es überblicke – keinerlei Unterschied macht. Wäre noch mal eine Vereinfachung, falls es tatsächlich keinen Grund dafür gibt. Gruß --Prog 21:51, 21. Mär. 2013 (CET)

Die min-width in 6a stellt immerhin sicher, daß es leserlich bleibt, eine regelmäßige Anordung in Zeilen und Spalten, wie teilweise wohl gewünscht, gibt es so aber nicht - von daher ist die Darstellung so nicht sonderlich übersichtlich für eine zügige Auswahl. Es werden zudem immer noch Tabellen verwendet, wobei das wikibooks-Projekt wohl ohnehin durch Fehler und falsche Verwendung von Elementen auch anderweitig so pessimiert ist, daß es keinen großen Unterschied mehr macht, ob man das mit Tabellen macht oder aufgrund der Einschränkungen der Möglichkeiten des Projektes mit noch mehr style-Attributen um sich wirft, um ein ähnliches Ergebnis zu erzielen. Von daher paßt das alles immerhin stimmig zusammen ;o) Doktorchen 14:21, 22. Mär. 2013 (CET)

Man muss die Schrift schon extrem groß machen, damit die Schrift weiter als 200px wird. Auch die Höhe ist überall gleich, mit Ausnahme des letzten Eintrags, was dort aber vom Layout nicht weiter stört. Das |<nowiki></nowiki> hatte ich aus einem Link übernommen. Möglicherweise dachten sich die Leute was dabei. Habe es aber jetzt weggelassen. Ich setze jetzt einmal 6a um, mit der Bereitschaft, es wieder zu ändern, falls Einwände oder Verbesserungen kommen. --mjchael 16:14, 22. Mär. 2013 (CET)

Ich hab noch ein paar Kleinigkeiten angepasst, die wahrscheinlich durch die globalen CSS-Regeln zu Fehlern geführt haben. Der Commons-Eintrag hat bei mir 201px Breite, aber da er der Letzte ist, stört das nicht. Was die Tabellen angeht können wir aus meiner Sicht nur warten, bis die "Scoped Styles" aus HTML5 endlich funktionieren und die Browser hinreichend verbreitet sind, aber ich fürchte, dass wird noch ein paar Jahre dauern. Mit diesem Feature wird es deutlich einfacher, innerhalb von Softwarelösungen wie MediaWiki "umfangreiche" individuelle Styles zu erstellen, die den Quelltext nicht verkomplizieren. Gruß --Prog 20:07, 1. Apr. 2013 (CEST)