nicht angemeldet
SELFHTML:Linkliste
Matthias Scharwies
0 Fred
1 3
SELFHTML:Linkliste
Matthias Scharwies
Auge
Matthias Apsel
Der Martin
TabellenkalkServus!
aus den Tagen der alten Doku übernommen, fristet die Linkliste eher ein Schattendasein im Wiki:
Wie nützlich sind solche Linksammlungen heute denn noch?
Könnten zumindest die letzten Kapitel 8-30 raus?
Die Kapitel 1-6 habe ich schon in die einzelnen Inhaltsbereiche ausgegliedert und wieder eingebunden, sodass sie leichter gepflegt werden können.
Herzliche Grüße
Matthias Scharwies
-
Guten Morgen,
Könnten zumindest die letzten Kapitel 8-30 raus?
ich finde (bzw. fand) diese Kapitel hilfreich und sollten drin bleiben:
11.1
11.2
15
21 (Die Fragen dazu tauchen hier immer wieder auf)
23Gruß
Fred
--
" " (Douglas Fairbanks Senior)-
Servus!
ich finde (bzw. fand) diese Kapitel hilfreich und sollten drin bleiben:
Vielen Dank für Deine Rückmeldung! Ich habe die Links in die eigentlichen Seiten ausgelagert und dann wieder mit <onlyinclude> in die Linkliste eingebunden:
11.1
15
21 (Die Fragen dazu tauchen hier immer wieder auf)
-
Code-Editoren Stimmt, da gibt es immer wieder Fragen und Diskussionen.
Wer Lust hat, kann bestehende auf Relevanz prüfen (tote Links dürften keine dabei sein) und weitere Links hinzufügen.
Herzliche Grüße
Matthias Scharwies
-
Lieber Matthias,
- Code-Editoren Stimmt, da gibt es immer wieder Fragen und Diskussionen.
habe Geany hinzugefügt.
Wer Lust hat, kann bestehende auf Relevanz prüfen (tote Links dürften keine dabei sein) und weitere Links hinzufügen.
Vivaldi ist doch der Opera-Nachfolger, oder habe ich das falsch in Erinnerung? Jedenfalls habe ich ihn hinzugefügt. Brauchen wir für ihn bald auch ein Iconset?
Liebe Grüße,
Felix Riesterer.
-
Servus!
Vielen Dank für die Änderungen!
Vivaldi ist doch der Opera-Nachfolger, oder habe ich das falsch in Erinnerung? Jedenfalls habe ich ihn hinzugefügt. Brauchen wir für ihn bald auch ein Iconset?
Der hat die gleiche Rendering Engine wie Opera:
"Gleichwohl setzt auch Vivaldi aus Kapazitätsgründen auf die quelloffene WebKit-Abspaltung Blink des von Google initiierten Open-Source-Projekts Chromium, das unter anderem von Opera, Yandex, Samsung, Intel und Nvidia unterstützt wird."
Insgesamt wird die Vorlage:Iconset angesichts der guten Browserunterstützung langsam nur Dekoration, die Einbindung von caniuse aber ungleich nützlicher.
Herzliche Grüße
Matthias Scharwies
-
Hallo
Vivaldi ist doch der Opera-Nachfolger, oder habe ich das falsch in Erinnerung?
Ja, hast du. Vivaldi wird von einem Team eines der Opera-Gründer entwickelt und soll mittelfristig das bieten, was der alte Opera (vor der Blink-Engine) mal konnte. Beide benutzen, wie @Matthias Scharwies schon schrieb, aber die nämliche Engine, weshalb ein eigenes Icon-Set nicht gebraucht wird.
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*
-
-
-
aus den Tagen der alten Doku übernommen, fristet die Linkliste eher ein Schattendasein im Wiki:
Wie nützlich sind solche Linksammlungen heute denn noch?
Kann nur für mich sprechen, aber ich finde gut-strukturierte und durchdachte Linksammlungen bei der chaotischen Informationsflut von heute eigentlich wichtiger denn je.
-
Servus! Herzlich willkommen im Forum!
Wie nützlich sind solche Linksammlungen heute denn noch?
Kann nur für mich sprechen, aber ich finde gut-strukturierte und durchdachte Linksammlungen bei der chaotischen Informationsflut von heute eigentlich wichtiger denn je.
Ja, aber wo sollen sie platziert werden?
Mir gefällt der untere Abschnitt auf den jeweiligen Portalseiten und die anschließende Einbindung in die Gesamtliste ganz gut - aber vielleicht gibt es Alternativen?
Herzliche Grüße
Matthias Scharwies
-
Vielen Dank Matthias!
Ich bin noch ganz neu hier bei SelfHTML, bin also nicht so die Expertin. Aber du hast recht, die Linkliste ist schwer zu finden. Eventuell könnte man die Linkliste auf der Wiki Startseite unter Werkzeuge aufführen. Aber wie geschrieben, bin noch ganz neu hier, ist nur so was mir spontan eingefallen ist :)
Liebe Grüße, Annika
-
Hallo Annika,
Eventuell könnte man die Linkliste auf der Wiki Startseite unter Werkzeuge aufführen.
Die Idee ist gut.
Bis demnächst
Matthias-
Hallo Matthias Apsel, @Annika
Eventuell könnte man die Linkliste auf der Wiki Startseite unter Werkzeuge aufführen.
Die Idee ist gut.
Unter Werkzeuge geht es technisch nicht, ich habe es zunächst unter Schnellindex platziert. Dort passt es imho thematisch am besten. Denkbar wären auch andere Überschriften bzw. Linktexte. Vielleicht hast du da ja auch noch eine Idee.
Bis demnächst
Matthias-
Freut mich, dass ich helfen konnte Matthias!
Vielleicht ist es ja sogar gar nicht so schlecht, wenn mal jemand einen unbefangenen Blick auf die Seite wirft. Bei der Wiki Startseite fällt mir auf, dass man extra nochmals auf "Vollständiges Inhaltsverzeichnis anzeigen" klicken muss, um unter anderem auch die Linkliste zu sehen.
Vielleicht wäre es ja sinnvoll, dass auf der Wiki Startseite schon standardmäßig das komplette Inhaltsverzeichnis angezeigt wird. Das Suchfeld "Im Wiki suchen" könnte man dann sicherlich oben platzieren, da ist ja noch jede Menge Platz.
Hoffe, die Vorschläge sind einigermaßen verständlich.
Liebe Grüße, Annika
-
Servus!
Freut mich, dass ich helfen konnte Matthias!
Vielleicht ist es ja sogar gar nicht so schlecht, wenn mal jemand einen unbefangenen Blick auf die Seite wirft.
Auf jeden Fall. Das gilt allgemein beim Webseiten entwickeln und im Besonderen auch für's Wiki.
Bei der Wiki Startseite fällt mir auf, dass man extra nochmals auf "Vollständiges Inhaltsverzeichnis anzeigen" klicken muss, um unter anderem auch die Linkliste zu sehen.
Ja, anfangs wollten wir einerseits HTML, CSS und JavaScript betonen und andererseits weniger Wichtiges nach hinten schieben.
Vielleicht wäre es ja sinnvoll, dass auf der Wiki Startseite schon standardmäßig das komplette Inhaltsverzeichnis angezeigt wird.
Ja, vor allem, weil die anderen Bereiche wie Grundlagen, Hilfsmittel, etc immer unbedeutender geworden sind und in anderen Bereichen wie HTML/Tutorials oder dem Glossar zu finden sind.
Das Suchfeld "Im Wiki suchen" könnte man dann sicherlich oben platzieren, da ist ja noch jede Menge Platz.
Dann beschwerten sich viele, dass man die Suche nicht finden würde. Sie ist ja schon rechts oben und hier noch einmal doppelt angelegt. Eigentlich könnte sie wohl weg.
Hoffe, die Vorschläge sind einigermaßen verständlich.
Ja, vielen Dank!
Wie wär'S mit diesem Vorschlag: mögliche Startseite
Vorteile: weniger Menüpukte, alphabetisch
Nachteile: keine Referenzen, sind aber sowieso in der Sidebar.
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias Scharwies,
Vielleicht wäre es ja sinnvoll, dass auf der Wiki Startseite schon standardmäßig das komplette Inhaltsverzeichnis angezeigt wird.
Ja, vor allem, weil die anderen Bereiche wie Grundlagen, Hilfsmittel, etc immer unbedeutender geworden sind und in anderen Bereichen wie HTML/Tutorials oder dem Glossar zu finden sind.
Ich denke nicht. Die Komprimierung der Startseite war ein langer Prozess. Es gab sogar den Vorschlag, ausschließlich das zusätzliche Suchfeld anzuzeigen, weil wohl kaum jemand im Wiki von der Startseite beginnend stöbert, sondern es wird wahrscheinlich ein konkretes Problem geben, sodass das Suchfeld im Fokus sein sollte.
Über die Struktur des Inhaltsverzeichnisses lässt sich diskutieren, deinen Vorschlag finde ich gut, ich würde allerdings wirklich nur die Punkte HTML, CSS, JavaScript (oder sogar SVG) initial anzeigen. Wir sollten die Startseite nicht überfrachten.
Dann beschwerten sich viele, dass man die Suche nicht finden würde. Sie ist ja schon rechts oben und hier noch einmal doppelt angelegt. Eigentlich könnte sie wohl weg.
Sie sollte unbedingt im Zentrum der Startseite bleiben.
Vorteile: weniger Menüpukte, alphabetisch
ob alphabetisch tatsächlich ein Vorteil ist?
Nachteile: keine Referenzen, sind aber sowieso in der Sidebar.
also kein Nachteil.
Bis demnächst
Matthias-
Hallo,
Vielleicht wäre es ja sinnvoll, dass auf der Wiki Startseite schon standardmäßig das komplette Inhaltsverzeichnis angezeigt wird.
dafür. Wobei ... ohne Javascript ist das ja sowieso schon so.
Ja, vor allem, weil die anderen Bereiche wie Grundlagen, Hilfsmittel, etc immer unbedeutender geworden sind und in anderen Bereichen wie HTML/Tutorials oder dem Glossar zu finden sind.
Ich denke nicht. Die Komprimierung der Startseite war ein langer Prozess.
Das glaube ich gern, aber es gibt unterschiedliche Herangehensweisen.
Es gab sogar den Vorschlag, ausschließlich das zusätzliche Suchfeld anzuzeigen, weil wohl kaum jemand im Wiki von der Startseite beginnend stöbert, sondern es wird wahrscheinlich ein konkretes Problem geben, sodass das Suchfeld im Fokus sein sollte.
Genau das meine ich: Ja, ich kann mir vorstellen, dass viele so vorgehen; ich bin es eher gewöhnt, in Nachschlagewerken hierarchisch-systematisch zur gesuchten Information vorzudringen. Das wird durch ein vollständiges Inhaltsverzeichnis erleichtert; alternativ ein Inhaltsverzeichnis, das nur die Überschriften der ersten Ordnung enthält und pro Abschnitt wieder auf untergeordnete Verzeichnisse für den jeweiligen Abschnitt verlinkt.
Eine Suche innerhalb der Site ist für mich immer nur das allerletzte Mittel, bevor ich aufgebe. Die Notwendigkeit, eine Site-interne Suche zu nutzen, ist IMO ein Indiz für eine ungünstige Struktur.Ich finde den momentanen Stand eigentlich ganz okay, auch wenn "Vollständiges Inhaltsverzeichnis" eine wesentlich detailliertere Liste erwarten lässt.
Kann man eigentich sowas wie eine Sitemap für das Wiki generieren?Dann beschwerten sich viele, dass man die Suche nicht finden würde. Sie ist ja schon rechts oben und hier noch einmal doppelt angelegt. Eigentlich könnte sie wohl weg.
Sie sollte unbedingt im Zentrum der Startseite bleiben.
Kann sie ja gern, aber sie sollte IMO ein geordnetes, strukturiertes Inhaltsverzeichnis nicht ersetzen, sondern nur ergänzen.
Vorteile: weniger Menüpukte, alphabetisch
ob alphabetisch tatsächlich ein Vorteil ist?
Vermutlich nicht. Eine Gruppierung nach Themengebieten wäre vielleicht günstiger.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
Servus!
ich bin es eher gewöhnt, in Nachschlagewerken hierarchisch-systematisch zur gesuchten Information vorzudringen. Das wird durch ein vollständiges Inhaltsverzeichnis erleichtert; alternativ ein Inhaltsverzeichnis, das nur die Überschriften der ersten Ordnung enthält und pro Abschnitt wieder auf untergeordnete Verzeichnisse für den jeweiligen Abschnitt verlinkt.
Ich finde den momentanen Stand eigentlich ganz okay, auch wenn "Vollständiges Inhaltsverzeichnis" eine wesentlich detailliertere Liste erwarten lässt.
ob alphabetisch tatsächlich ein Vorteil ist?
Das ist der jetzige Inhaltsbereich: Inhalt
Vermutlich nicht. Eine Gruppierung nach Themengebieten wäre vielleicht günstiger.
Welche Themengebiete sollten das sein?
evtl:
-
Webdesign mit Webstandards
-
Programmiersprachen
-
Webserver
wie viel Unterseiten / würdest Du aufnehmen wollen? 2-3 Hierarchieebenen?
Kann man eigentich sowas wie eine Sitemap für das Wiki generieren?
Du kannst dir in den Spezialseiten alle Unterseiten eines suchbegriffs angeben lassen.
So long,
MartinHerzliche Grüße
Matthias Scharwies
-
Hallo,
Das ist der jetzige Inhaltsbereich: Inhalt
öhm, ich bin ... irritiert. Das ist doch ein Duplikat der Wiki-Startseite, nur dass hier die Top-Kategorien HTML, CSS und Javascript (und Wiki) fehlen. Finde ich seltsam.
Vermutlich nicht. Eine Gruppierung nach Themengebieten wäre vielleicht günstiger.
Welche Themengebiete sollten das sein?
Ausgehend von der jetzigen Gliederung würde ich SVG und Perl nicht als eigene Kategorien erwarten, sondern eher unter Weitere Sprachen vermuten; unter_Webstandards_ würde ich eigentlich das erwarten, was derzeit unter Referenzen steht, die derzeitigen Referenzen würde ich eher Best Practices nennen und die Gestaltung von Webseiten mit dort hineinnehmen. Dann vielleicht noch Webserver-Praxis, Grundlagen und Fachartikel.
Also eigentlich gar nicht so viel anders wie die bestehende Lösung. ;-)
wie viel Unterseiten / würdest Du aufnehmen wollen? 2-3 Hierarchieebenen?
Zwei sollten allgemein okay sein, für besonders komplexe Themen vielleicht mal drei.
Kann man eigentich sowas wie eine Sitemap für das Wiki generieren?
Du kannst dir in den Spezialseiten alle Unterseiten eines suchbegriffs angeben lassen.
Interessant, danke!
Ciao,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
Hallo Der Martin,
Das ist der jetzige Inhaltsbereich: Inhalt
öhm, ich bin ... irritiert. Das ist doch ein Duplikat der Wiki-Startseite, nur dass hier die Top-Kategorien HTML, CSS und Javascript (und Wiki) fehlen. Finde ich seltsam.
Nö. Das ist das, was nach „vollständiges Inhaltsverzeichnis anzeigen“ angezeigt wird, falls man JS aktiviert hat.
Welche Themengebiete sollten das sein? Also eigentlich gar nicht so viel anders wie die bestehende Lösung. ;-)
Ja, wir haben uns da schon Mühe gegeben ;-)
Bis demnächst
Matthias -
Servus!
Vermutlich nicht. Eine Gruppierung nach Themengebieten wäre vielleicht günstiger.
Welche Themengebiete sollten das sein?
Ausgehend von der jetzigen Gliederung würde ich SVG und Perl nicht als eigene Kategorien erwarten, sondern eher unter Weitere Sprachen vermuten;
Ja.
unter_Webstandards_ würde ich eigentlich das erwarten, was derzeit unter Referenzen steht,
Aber die Webstandards sind doch seit 15 Jahren so (Usability, accessibility,etc) definiert, oder?
die derzeitigen Referenzen würde ich eher Best Practices nennen,
Das sind doch eher Referenztabellen wie in der alten Doku, nur stark erweitert.
und die Gestaltung von Webseiten mit dort hineinnehmen. Dann vielleicht noch Webserver-Praxis, Grundlagen und Fachartikel.
Also eigentlich gar nicht so viel anders wie die bestehende Lösung. ;-)
Finde ich jetzt schon. Habe eine Thematische Gliederung vorgenommen, bin mit der 3. Spalte aber nicht glücklich.
Herzliche Grüße
Matthias Scharwies
-
Hallo,
unter_Webstandards_ würde ich eigentlich das erwarten, was derzeit unter Referenzen steht,
Aber die Webstandards sind doch seit 15 Jahren so (Usability, accessibility,etc) definiert, oder?
ähm, weiß ich nicht. Aber unter Standards verstehe ich klare, harte Spezifikationen, nicht gute Ratschläge oder Empfehlungen.
Um es auf ein anderes Thema zu projizieren: Die StVO würde ich als verbindlichen Standard sehen, als feste Spezifikation. Die Devise "Fahre immer vorsichtig und rücksichtsvoll" hat dagegen, auch wenn sie zweifellos gut und richtig ist, nur Empfehlungscharakter.die derzeitigen Referenzen würde ich eher Best Practices nennen,
Das sind doch eher Referenztabellen wie in der alten Doku, nur stark erweitert.
Sorry, mein Fehler: Ich meinte: Die bisherigen Webstandards würde ich ...
und die Gestaltung von Webseiten mit dort hineinnehmen. Dann vielleicht noch Webserver-Praxis, Grundlagen und Fachartikel.
Also eigentlich gar nicht so viel anders wie die bestehende Lösung. ;-)
Finde ich jetzt schon. Habe eine Thematische Gliederung vorgenommen, bin mit der 3. Spalte aber nicht glücklich.
Damit könnte ich mich prinzipiell auch anfreunden, wobei ich SVG auch unter XML einordnen würde. Schließlich ist SVG eine XML-Anwendung.
Ähm, welche dritte Spalte? Die Angabe ist aufgrund des Fließverhaltens der Blöcke nicht eindeutig. Meinst du Webserver und unsortierbar? Denn die beiden stehen bei mir in der dritten Spalte.Übrigens stehe ich generell auf Kriegsfuß mit spaltenweise angeordneten Blöcken verschiedener Höhe. Das sieht immer aus wie Kraut und Rüben, und ich habe Mühe, bei so einem Layout die Blöcke noch als solche zu erkennen.
So long,
Martin--
Ich nehme keine Drogen, ich bin die Droge. (gelesen auf einem entgegenkommenden T-Shirt)-
Servus!
Damit könnte ich mich prinzipiell auch anfreunden, wobei ich SVG auch unter XML einordnen würde. Schließlich ist SVG eine XML-Anwendung.
Ja, aber dann HTML und MathML auch :-)
SVG ist ein eigener Bereich geworden, der schon 116 Unterseiten hat. Durch die direkte Einbindung in HTM5 tritt m.E. der XML-Charakter langsam zurück.
Ähm, welche dritte Spalte? Die Angabe ist aufgrund des Fließverhaltens der Blöcke nicht eindeutig. Meinst du Webserver und unsortierbar? Denn die beiden stehen bei mir in der dritten Spalte.
Genau.
Übrigens stehe ich generell auf Kriegsfuß mit spaltenweise angeordneten Blöcken verschiedener Höhe. Das sieht immer aus wie Kraut und Rüben, und ich habe Mühe, bei so einem Layout die Blöcke noch als solche zu erkennen.
Ja, Das ist m.E genau das Problem an diesen thematischen Zusammenstellungen. Lassen wir auf einer Seite künstlich wichtige Seiten weg, um anderenorts was Unwesentliches hinzuzufügen, nur um die Bereiche gleich groß zu machen?
Nur 1 Spalte wie auf der mobilen Ansicht?
Bei einer alphabetischen Gliederung der Oberpunkte könnte man anstelle der festen Spalten columns verwenden.
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias,
Damit könnte ich mich prinzipiell auch anfreunden, wobei ich SVG auch unter XML einordnen würde. Schließlich ist SVG eine XML-Anwendung.
Ja, aber dann HTML und MathML auch :-)
ähm, MathML ja, HTML nicht (XHTML dagegen schon). HTML ist zwar von SGML abgeleitet, aber nicht von XML. Aber das wird jetzt Haarspalterei.
SVG ist ein eigener Bereich geworden, der schon 116 Unterseiten hat. Durch die direkte Einbindung in HTM5 tritt m.E. der XML-Charakter langsam zurück.
Okay, kann man so sehen. Ein zusätzlicher Verweis von der XML-Übersicht aus wäre dennoch sinnvoll, ebenso wie für MathML.
Übrigens stehe ich generell auf Kriegsfuß mit spaltenweise angeordneten Blöcken verschiedener Höhe. Das sieht immer aus wie Kraut und Rüben, und ich habe Mühe, bei so einem Layout die Blöcke noch als solche zu erkennen.
Ja, Das ist m.E genau das Problem an diesen thematischen Zusammenstellungen.
Muss aber nicht. Was wäre, wenn man einfach primär horizontal ordnet? Also etwa so:
|Überschrift| |Kapitel 1|Kapitel 2|Kapitel 3| |Kapitel 4|Kapitel 5|Kapitel 6| |Kapitel 7|
Man muss das ja nicht als Tabelle auszeichnen; dem fließenden Layout zuliebe würde ich das in etwa so auszeichnen:
<section> <h2>Überschrift</h2> <ol> <li>Kapitel 1</li> <li>Kapitel 2</li> <li>Kapitel 3</li> <li>Kapitel 4</li> <li>Kapitel 5</li> <li>Kapitel 6</li> <li>Kapitel 7</li> </ol> </section>Anstatt section könnten die Container auch li-Elemente einer übergeordneten Liste sein.
Jetzt noch die li-Elemente als inline-block mit Breitenangabe in em, und fertig ist ein Layout, das sich mit mehreren Spalten der verfügbaren Breite anpasst. Die Themenblöcke gehen dann halt über die ganze Breite, und die Spalten sind zwar visuell noch dam aber nicht mehr betont.So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy -
Lieber Matthias,
hier ein paar Korinthen von mir: ;-)
Damit könnte ich mich prinzipiell auch anfreunden, wobei ich SVG auch unter XML einordnen würde. Schließlich ist SVG eine XML-Anwendung.
Ja, aber dann HTML und MathML auch :-)
HTML und XML sind beide SGML-basierte Sprachen. HTML (bis einschließlich HTML5) ist von seiner Syntax allerdings "freier" als XML und würde von einem XML-Parser sicherlich oft nicht verstanden, da Elemente wie
<meta>,<img>oder<input>ohne schließendes Tag notiert werden dürfen, ebenso inhaltsleere Attribute ohne Istgleichzeichen und Stringbegrenzern (<input required>versus<input required="required" />).HTML5 kann man analog zu XHTML wohlgeformt notieren, damit es von einem XML-Parser fehlerfrei geparst werden kann, was den HTML5-Parser auch nicht stören würde, ist aber (absichtlich) kein XML-Dialekt wie z.B. SVG oder MathML.
Liebe Grüße,
Felix Riesterer.
-
Hallo
hier ein paar Korinthen von mir: ;-)
Jetzt noch ein paar Nüsschen und wir könnten intellektuell tun. ;-)
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*
-
-
-
Hallo Der,
ähm, weiß ich nicht. Aber unter Standards verstehe ich klare, harte Spezifikationen, nicht gute Ratschläge oder Empfehlungen.
Um es auf ein anderes Thema zu projizieren: Die StVO würde ich als verbindlichen Standard sehen, als feste Spezifikation. Die Devise "Fahre immer vorsichtig und rücksichtsvoll" hat dagegen, auch wenn sie zweifellos gut und richtig ist, nur Empfehlungscharakter.Dieser Irrtum erklärt die Weise, in der sich viele Verkehrsteilnehmer fortbewegen.
MfG, at
-
-
-
-
-
-
Servus!
Hallo Matthias Scharwies,
Vielleicht wäre es ja sinnvoll, dass auf der Wiki Startseite schon standardmäßig das komplette Inhaltsverzeichnis angezeigt wird.
Ich denke nicht. Die Komprimierung der Startseite war ein langer Prozess.
Ja, das stimmt schon. Andererseits ändern sich Gewohnheiten und Strukturen immer wieder. So war der Grundlagen-Bereich früher die Einführung in alles, was heute als Selbstverständlich gilt: Hypertext, HTTP, etc. Diese Artikel sind heute häufig im glossar zu finden.
Es gab sogar den Vorschlag, ausschließlich das zusätzliche Suchfeld anzuzeigen, weil wohl kaum jemand im Wiki von der Startseite beginnend stöbert, sondern es wird wahrscheinlich ein konkretes Problem geben, sodass das Suchfeld im Fokus sein sollte.
Dann beschwerten sich viele, dass man die Suche nicht finden würde. Sie ist ja schon rechts oben und hier noch einmal doppelt angelegt. Eigentlich könnte sie wohl weg.
Sie sollte unbedingt im Zentrum der Startseite bleiben.
Ja, auch Annika hat es ja nicht als duplicate content angesehen, sondern nur verschieben wollen.
Andererseits hat z.B. die Wikipedia dort News und zufällige, bzw. exzellente Artikel und kein Inhaltsverzeichnis. Wäre das was für uns?
Über die Struktur des Inhaltsverzeichnisses lässt sich diskutieren, deinen Vorschlag finde ich gut, ich würde allerdings wirklich nur die Punkte HTML, CSS, JavaScript (oder sogar SVG) initial anzeigen. Wir sollten die Startseite nicht überfrachten.
ok. Und die meisten Nutzer kommen ja eh über google auf bestimmte Unterseiten (bei der nytimes.com 63%, bin nur zu faul den Artikel rauszusuchen)
Vorteile: weniger Menüpukte, alphabetisch
ob alphabetisch tatsächlich ein Vorteil ist?
Keine Ahnung, aber die Einteilung in Webdesign / Programmiersprachen / Referenzen ist auch nicht das Gelbe vom Ei.
Nachteile: keine Referenzen, sind aber sowieso in der Sidebar.
also kein Nachteil.
ich habe jetzt Länderkürzel, Sprachkürzel und MIME-Typen mal mit aufgenommen. Und den Klappmechanismus.
Herzliche Grüße
Matthias Scharwies
-
Hallo
Andererseits hat z.B. die Wikipedia [auf der Startseite] News und zufällige, bzw. exzellente Artikel und kein Inhaltsverzeichnis. Wäre das was für uns?
MMn nein. Dort erwarte ich einen Überblick über die Angebote, nicht irgendeinen Artikel, den ich mit an Sicherheit grenzender Wahrscheinlichkeit nicht gesucht habe. Und so oft, wie das Blog mit Inhalten beschickt wird, wird das wohl auch nichts mit „News“ im eigentlichen Sinne.
Vorteile: weniger Menüpukte, alphabetisch
ob alphabetisch tatsächlich ein Vorteil ist?
Keine Ahnung, …
Ich halte eine alphabetische Auflistung (als Startpunkt) in einem themengeordneten Angebot für fehl am Platze.
… aber die Einteilung in Webdesign / Programmiersprachen / Referenzen ist auch nicht das Gelbe vom Ei.
Ich halte diese Einteilung grundsätzlich für zielführend. Komme ich über ein Suchergebnis auf die Doku, interessiert mich die Startseite nicht die Bohne. Komme ich hingegen über den Link im Forenkopf oder auf ähnlichen Wegen zur Doku, lande ich auf dessen Startseite. Dann will ich auf die dortige Suche oder ein thematisch geordnetes Menü zum durchklicken zugreifen. Das sollte natürlich nicht mit gefühlten 100 Ebenen daherkommen, aber zwei bis vier Ebenen, die so benannt sind, dass man sich nicht „verläuft“, sind schon o.k..
Was bedeutet denn für dich „nicht das Gelbe vom Ei“ bei diesem Thema?
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*-
Servus!
Ich halte eine alphabetische Auflistung (als Startpunkt) in einem themengeordneten Angebot für fehl am Platze.
ok
Ich halte diese Einteilung [in Themen] grundsätzlich für zielführend. Komme ich über ein Suchergebnis auf die Doku, interessiert mich die Startseite nicht die Bohne.
Full ACK!
Komme ich hingegen über den Link im Forenkopf oder auf ähnlichen Wegen zur Doku, lande ich auf dessen Startseite. Dann will ich auf die dortige Suche oder ein thematisch geordnetes Menü zum durchklicken zugreifen.
Ja!
Das sollte natürlich nicht mit gefühlten 100 Ebenen daherkommen, aber zwei bis vier Ebenen, die so benannt sind, dass man sich nicht „verläuft“, sind schon o.k..
Was bedeutet denn für dich „nicht das Gelbe vom Ei“ bei diesem Thema?
Na ja, wir haben hier [Inhalt] im Augenblick (zu) viele Themen in 2, bzw. 4 Spalten
Fachartikel kann weg, das gibt's nicht mehr (sind jetzt thematisch einsortiert)
Glossar und Referenzen sind schon links in der Sidebar vorhanden.
Wie der Martin schon sagte, sind SVG und Perl zu prominent, obwohl sie natürlich auch mehr Inhalte als die anderen Bereiche haben. Andererseits ist SVG/Anwendung und Praxis auch in SVG eingebunden und deshalb nicht notwendig. Ein Bereich weitere Sprachen mit 6-7 Unterpunkten wäre da besser.
Wie könnte man da die Themen so sortieren, dass sie anstatt aus 12 wie heute aus 3-4 bestehen, dass sie sofort ins Auge springen und mit ihren Unterpunkten leicht zu finden sind?
Herzliche Grüße
Matthias Scharwies
-
Hallo
Was bedeutet denn für dich „nicht das Gelbe vom Ei“ bei diesem Thema?
Na ja, wir haben hier [Inhalt] im Augenblick (zu) viele Themen in 2, bzw. 4 Spalten
…
Wie der Martin schon sagte, sind SVG und Perl zu prominent, … Ein Bereich weitere Sprachen mit 6-7 Unterpunkten wäre da besser.
ACK, damit wären drei Blöcke zu einem verschmolzen, also zwei wären weg.
Wie könnte man da die Themen so sortieren, dass sie anstatt aus 12 wie heute aus 3-4 bestehen, dass sie sofort ins Auge springen und mit ihren Unterpunkten leicht zu finden sind?
Ich halte auch die Doppelung des Viewport-Emulators für falsch. Er taucht einmal im Block „Gestaltung von Webseiten“ als Unterpunkt von „Hilfsmittel, Software & Onlinetools“ und ein weiteres Mal als einziger Menüpunkt im Block „Hilfsmittel“ auf. Der Emulator mag wichtig genug sein, um direkt vom Inhaltsverzeichnis aus aufrufbar zu sein. Das muss aber nicht in einem eigenen Block sein. Er könnte genauso gut im Block „Gestaltung von Webseiten“ stehen. Damit wäre ein dritter Block weg.
Verschwinden zudem die von dir genannten Blöcke „Fachartikel“ sowie „Glossar“ und „Referenzen“ erhöhte sich die Zahl der wegfallenden Blöcke schon auf sechs. Von den 14 auf der von dir verlinkten Seite vorhandenen Blöcken blieben so acht übrig. Das sind zwar nicht die von dir angestrebten drei bis vier Blöcke, aber ein Vorschlag.
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*
-
-
-
Hallo Matthias Scharwies,
ich habe jetzt Länderkürzel, Sprachkürzel und MIME-Typen mal mit aufgenommen. Und den Klappmechanismus.
Die weiteren drei Punkte initial anzuzeigen, finde ich ebenfalls gut. Allerdings sollte das unterhal des Suchfeldes stehen.
Bis demnächst
Matthias
-
-
-
Das Suchfeld "Im Wiki suchen" könnte man dann sicherlich oben platzieren, da ist ja noch jede Menge Platz.
Dann beschwerten sich viele, dass man die Suche nicht finden würde. Sie ist ja schon rechts oben und hier noch einmal doppelt angelegt. Eigentlich könnte sie wohl weg.
Servus Matthias :)
du hast recht, ich hätte noch fragen sollen, ob es beide Male das gleiche Suchfeld ist. Hatte mich schon gewundert, dachte aber, dass das Suchfeld oben für die gesamte Seite gilt, das Suchfeld unten nur für den Wiki-Bereich. Da aber beide Suchfelder für den Wiki-Bereich sind, könnte man das untere Suchfeld sicher ganz rausnehmen.
Wie wär'S mit diesem Vorschlag: mögliche Startseite
Vorteile: weniger Menüpukte, alphabetisch
Nachteile: keine Referenzen, sind aber sowieso in der Sidebar.
Herzliche Grüße
Matthias Scharwies
Ich finde die Startseite, wie du sie jetzt vorgeschlagen hast, sehr viel besser als die Ursprungsversion. Man sieht in deiner Version gleich, dass die Wiki-Seite eine größere Themenbandbreite abdeckt.
Wie ich sehe ist in deiner Version aber noch die Option "Vollständiges Inhaltsverzeichnis anzeigen" präsent. Ich weiß nicht, ob gerade Nutzer, die noch nicht auf der Seite waren, auch auf diese Option klicken. Aber ja ich finde deine Version der Startseite schon sehr viel besser und auch benutzerfreundlicher.
Herzliche Grüße! Annika
-
Servus!
Hatte mich schon gewundert, dachte aber, dass das Suchfeld oben für die gesamte Seite gilt, das Suchfeld unten nur für den Wiki-Bereich.
Das ist angedacht EINE Suche für Wiki und Forumsarchiv einzurichten, genauso wie EINE Anmeldung für beide Welten.
Da aber beide Suchfelder für den Wiki-Bereich sind, könnte man das untere Suchfeld sicher ganz rausnehmen.
Oder drinlassen, wie Matthias Apsel sagt.
Wie wär's mit diesem Vorschlag: mögliche Startseite
Ich finde die Startseite, wie du sie jetzt vorgeschlagen hast, sehr viel besser als die Ursprungsversion. Man sieht in deiner Version gleich, dass die Wiki-Seite eine größere Themenbandbreite abdeckt.
Danke, da hätten wir auch selber drauf kommen können, waren aber betriebsblind.
Wie ich sehe ist in deiner Version aber noch die Option "Vollständiges Inhaltsverzeichnis anzeigen" präsent. Ich weiß nicht, ob gerade Nutzer, die noch nicht auf der Seite waren, auch auf diese Option klicken.
Das ist genau die Frage, wie man das macht. Eigentlich warnt man bei Akkordeons und Slidern ja davor, dass Inhalte versteckt werden. Hier wollte man die Seite aber so übersichtlich wie möglich machen, was dazu führte, dass Inhalte teils nicht gefunden wurden (früher war der Button rechts und ich selbst hatte es nicht als button erkannt).
Vielleicht erst HTML, CSS & JS, dann die Suche und darunter die weiteren Seiten?
Herzliche Grüße
Matthias Scharwies
-
-
-
-
Servus!
Hallo Matthias Apsel, @Annika
Eventuell könnte man die Linkliste auf der Wiki Startseite unter Werkzeuge aufführen.
Die Idee ist gut.
Unter Werkzeuge geht es technisch nicht, ich habe es zunächst unter Schnellindex platziert. Dort passt es imho thematisch am besten. Denkbar wären auch andere Überschriften bzw. Linktexte.
Ich würde die Linkliste „Linkliste“ und nicht „weiterführende Links“ nennen, damit der Wiedererkennungswert höher ist.
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias Scharwies,
Ich würde die Linkliste „Linkliste“ und nicht „weiterführende Links“ nennen, damit der Wiedererkennungswert höher ist.
Ok. Auf der anderen Seite ist „Linkliste“ natürlich auch ein doofes Wort.
Bis demnächst
Matthias-
Servus!
Hallo Matthias Scharwies,
Ich würde die Linkliste „Linkliste“ und nicht „weiterführende Links“ nennen, damit der Wiedererkennungswert höher ist.
Ok. Auf der anderen Seite ist „Linkliste“ natürlich auch ein doofes Wort.
Sollen wir sie dann umbenennen? Früher hieß sie „Linkverzeichnis“, was ich auch nicht besser finde.
Bis demnächst
MatthiasHerzliche Grüße
Matthias Scharwies
-
Hallo Matthias Scharwies,
Sollen wir sie dann umbenennen? Früher hieß sie „Linkverzeichnis“, was ich auch nicht besser finde.
Linktipps?
Bis demnächst
Matthias -
Hallo Matthias,
da gleich ein wenig Kritik folgt und ihr ohnehin zu wenig Lob bekommt, möchte ich mich nur kurz für euer enormes Engagement, die offene Diskussion über eure Arbeit und nicht zuletzt das beeindruckende Ergebnis bedanken.
Ich würde die Linkliste „Linkliste“ und nicht „weiterführende Links“ nennen, damit der Wiedererkennungswert höher ist.
Ok. Auf der anderen Seite ist „Linkliste“ natürlich auch ein doofes Wort.
Sollen wir sie dann umbenennen? Früher hieß sie „Linkverzeichnis“, was ich auch nicht besser finde.
Ich finde all diese Bezeichnungen nicht sonderlich hilfreich, weil sie syntaktisch statt semantisch orientiert sind.
Auch die Startseite des Wiki ist eine Linkliste und auf vielen Seiten gibt es Linklisten zum jeweiligen Thema. Nur heißen diese Linklisten dort Inhaltsverzeichnis, Quellen, Weblinks oder „Siehe auch“ beziehungsweise „siehe auch“.
Wenn ihr also Regelwerke, Dokumentationen, Werkzeuge und Hilfestellungen sammelt, dann nennt sie doch auch als Seiten und in der Navigation so. – Oder so ähnlich. Mir geht es nicht um die konkreten Begriffe.
Ich sehe auch nur wenig Sinn darin, das alles auf eine gefühlt 2,70 Meter lange Seite zu quetschen, deren Inhaltsverzeichnis nicht in meinen Viewport passt. Warum nicht vier Seiten nach den genannten Kategorien? Dass beispielsweise ein HTML-Validator dann unter Regelwerke und unter Werkzeuge auftauchen könnte, ist sicher zu verschmerzen.
Oder man sortiert die weiterführenden Informationen zu Themen, die im Wiki ohnehin behandelt werden, beispielsweise HTML oder CSS, gleich auf den Portalseiten des jeweiligen Themas ein.
Oder man macht beides. Und nein, das ist kein Arbeitsauftrag an euch. Ich würde mich durchaus maßgeblich an der Umsetzung beteiligen. Aber das setzt voraus, dass ihr zumindest grundsätzlich meine Meinung teilt.
Und eine Kleinigkeit noch: Den Punkt „Sonstiges“ sollte man entweder grundsätzlich streichen oder ihm konsequenterweise ausschließlich den Punkt „Allgemeines“ gegenüberstellen.
MfG, at
-
Servus!
Hallo Matthias,
da gleich ein wenig Kritik folgt und ihr ohnehin zu wenig Lob bekommt, möchte ich mich nur kurz für euer enormes Engagement, die offene Diskussion über eure Arbeit und nicht zuletzt das beeindruckende Ergebnis bedanken.
Vielen Dank, das hört man gerne!
Ich würde die Linkliste „Linkliste“ und nicht „weiterführende Links“ nennen, damit der Wiedererkennungswert höher ist.
Ok. Auf der anderen Seite ist „Linkliste“ natürlich auch ein doofes Wort.
Sollen wir sie dann umbenennen? Früher hieß sie „Linkverzeichnis“, was ich auch nicht besser finde.
Ich finde all diese Bezeichnungen nicht sonderlich hilfreich, weil sie syntaktisch statt semantisch orientiert sind.
Ja, das Problem der Linkliste ist eher ein historisches. Es gab sie in der alten Doku, also wurde sie ins Wiki gezoegen und dort nur unzureichend gepflegt.
Auch die Startseite des Wiki ist eine Linkliste und auf vielen Seiten gibt es Linklisten zum jeweiligen Thema. Nur heißen diese Linklisten dort Inhaltsverzeichnis, Quellen, Weblinks oder „Siehe auch“ beziehungsweise „siehe auch“.
Ja, das haben wir von der großen Schwester Wikipedia übernommen.
-
Quellen sind Referenzen/Fußnoten aus dem Text, die mit
<references/>automatisch aufgelistet werden -
Siehe auch (Die Schreibweise ist noch nicht überall berichtigt) sind interne Links innerhalb des Wikis
-
Weblinks sind die "Weiterführenden Links" der alten Doku auf externe Seiten
Wenn ihr also Regelwerke, Dokumentationen, Werkzeuge und Hilfestellungen sammelt, dann nennt sie doch auch als Seiten und in der Navigation so. – Oder so ähnlich. Mir geht es nicht um die konkreten Begriffe.
Ich sehe auch nur wenig Sinn darin, das alles auf eine gefühlt 2,70 Meter lange Seite zu quetschen, deren Inhaltsverzeichnis nicht in meinen Viewport passt.
Du hast recht, darin wenig Sinn zu sehen. Wie gesagt ist die Linkliste ein Überbleibsel aus der Zeit als z.B. SVG einen kurzen Absatz unter "technische Ergänzungen" einnahm und keinen eigenen Bereich mit 100 Unterseiten.
Warum nicht vier Seiten nach den genannten Kategorien? Dass beispielsweise ein HTML-Validator dann unter Regelwerke und unter Werkzeuge auftauchen könnte, ist sicher zu verschmerzen.
Oder man sortiert die weiterführenden Informationen zu Themen, die im Wiki ohnehin behandelt werden, beispielsweise HTML oder CSS, gleich auf den Portalseiten des jeweiligen Themas ein.
Genau so! Du antwortest hier auf einen anderthalb jahre alten Beitrag.
Die für uns gefundene Lösung ist, dass wir zu jedem Bereich eine eigene Seite haben, die dann in die Linkliste und in die jeweilige Portalseite eingebunden ist:
Quellcode der Seite Linkliste:
== HTML == {{:HTML/Linkliste}} == CSS == {{:CSS/Linkliste}} == JavaScript == {{:JavaScript/Links}} == PHP == {{:PHP/Links}} == XML, DTDs und XSL(T) == {{:XML/Linkliste}}Oder man macht beides. Und nein, das ist kein Arbeitsauftrag an euch. Ich würde mich durchaus maßgeblich an der Umsetzung beteiligen. Aber das setzt voraus, dass ihr zumindest grundsätzlich meine Meinung teilt.
Ich sehe grad, dass das noch nicht überall auf den jeweiligen Portalseiten angekommen ist. Wer das nachholen möchte, bitte gerne!
Und eine Kleinigkeit noch: Den Punkt „Sonstiges“ sollte man entweder grundsätzlich streichen oder ihm konsequenterweise ausschließlich den Punkt „Allgemeines“ gegenüberstellen.
ist gelöscht.
Grundsätzlich wird uns die Linkliste nur in Erinnerung gerufen, wenn wieder irgendjemand seine eigene Seite zu Werbezwecken verlinkt haben möchte.
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste-
Hallo Matthias.
da gleich ein wenig Kritik folgt und ihr ohnehin zu wenig Lob bekommt, möchte ich mich nur kurz für euer enormes Engagement, die offene Diskussion über eure Arbeit und nicht zuletzt das beeindruckende Ergebnis bedanken.
Vielen Dank, das hört man gerne!
Und leider zu selten.
Ja, das Problem der Linkliste ist eher ein historisches. Es gab sie in der alten Doku, also wurde sie ins Wiki gezoegen und dort nur unzureichend gepflegt.
Habt ihr wenigstens eine technische Möglichkeit, Links regelmäßig automatisch darauf zu prüfen, ob die Ressource noch existiert?
Auch die Startseite des Wiki ist eine Linkliste und auf vielen Seiten gibt es Linklisten zum jeweiligen Thema. Nur heißen diese Linklisten dort Inhaltsverzeichnis, Quellen, Weblinks oder „Siehe auch“ beziehungsweise „siehe auch“.
Ja, das haben wir von der großen Schwester Wikipedia übernommen.
-
Quellen sind Referenzen/Fußnoten aus dem Text, die mit
<references/>automatisch aufgelistet werden -
Siehe auch (Die Schreibweise ist noch nicht überall berichtigt) sind interne Links innerhalb des Wikis
-
Weblinks sind die "Weiterführenden Links" der alten Doku auf externe Seiten
Das ist in sich auch schlüssig, wenn man nicht für andere Linkliste den Begriff Linkliste verwendet.
Warum nicht vier Seiten nach den genannten Kategorien? Dass beispielsweise ein HTML-Validator dann unter Regelwerke und unter Werkzeuge auftauchen könnte, ist sicher zu verschmerzen.
Oder man sortiert die weiterführenden Informationen zu Themen, die im Wiki ohnehin behandelt werden, beispielsweise HTML oder CSS, gleich auf den Portalseiten des jeweiligen Themas ein.
Genau so! Du antwortest hier auf einen anderthalb jahre alten Beitrag.
Yep! Aber ich habe dann wohl …
Ich sehe grad, dass das noch nicht überall auf den jeweiligen Portalseiten angekommen ist. Wer das nachholen möchte, bitte gerne!
… zufällig auf einer Seite nachgesehen, auf der das noch nicht behoben worden ist, und das Ergebnis für allgemeingültig gehalten, ohne es zu prüfen.
Die für uns gefundene Lösung ist, dass wir zu jedem Bereich eine eigene Seite haben, die dann in die Linkliste und in die jeweilige Portalseite eingebunden ist:
Quellcode der Seite Linkliste:
== HTML == {{:HTML/Linkliste}} == CSS == {{:CSS/Linkliste}} == JavaScript == {{:JavaScript/Links}} == PHP == {{:PHP/Links}} == XML, DTDs und XSL(T) == {{:XML/Linkliste}}Das sieht nach einem sehr sinnvollen Konzept aus.
Und eine Kleinigkeit noch: Den Punkt „Sonstiges“ sollte man entweder grundsätzlich streichen oder ihm konsequenterweise ausschließlich den Punkt „Allgemeines“ gegenüberstellen.
ist gelöscht.
Besten Dank!
Grundsätzlich wird uns die Linkliste nur in Erinnerung gerufen, wenn wieder irgendjemand seine eigene Seite zu Werbezwecken verlinkt haben möchte.
Nur interessehalber: Wie häufig kommt so etwas vor? Und wie häufig müsst ihr ungefragte Werbeeinträge dort löschen?
MfG, at
-
Servus!
Ja, das Problem der Linkliste ist eher ein historisches. Es gab sie in der alten Doku, also wurde sie ins Wiki gezoegen und dort nur unzureichend gepflegt.
Habt ihr wenigstens eine technische Möglichkeit, Links regelmäßig automatisch darauf zu prüfen, ob die Ressource noch existiert?
Nein. Kennst Du da eine Möglichkeit?
Die für uns gefundene Lösung ist, dass wir zu jedem Bereich eine eigene Seite haben, die dann in die Linkliste und in die jeweilige Portalseite eingebunden ist:
Quellcode der Seite Linkliste:
== HTML == {{:HTML/Linkliste}} == CSS == {{:CSS/Linkliste}} == JavaScript == {{:JavaScript/Links}}Das sieht nach einem sehr sinnvollen Konzept aus.
Ich sehe grad, dass das noch nicht überall auf den jeweiligen Portalseiten angekommen ist. Wer das nachholen möchte, bitte gerne!
Hab ich jetzt nachgeholt.
Grundsätzlich wird uns die Linkliste nur in Erinnerung gerufen, wenn wieder irgendjemand seine eigene Seite zu Werbezwecken verlinkt haben möchte.
Nur interessehalber: Wie häufig kommt so etwas vor?
Alle 6-12 Monate.
Und wie häufig müsst ihr ungefragte Werbeeinträge dort löschen?
Seit wir die Linkliste mit einem Seitenschutz versehen haben, der nur angemeldeten Nutzern Änderungen ermöglicht, nicht mehr so oft.
Ein Beispiel, das die Problematik externer Links aufzeigt, hier:
Fazit: Wir sollten nur auf Referenzen und nicht auf externe Dokumentationen, höchstens jedoch auf einzelne gute Tutorials und Aufsätze verlinken.
Häufiger (monatlich) gibt es Anfragen, Blog-Artikel mit backlinks zu platzieren. Damit haben wir ebenfalls sehr durchwachsene Erfahrungen gemacht. Entweder sind es reine Einführungsartikel oder sie erfordern viel Nacharbeit, wo der Aufwand für uns in keinem Verhältnis zum Ergebnis steht.
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste
-
-
Hallo Matthias Scharwies,
Sollen wir sie dann umbenennen? Früher hieß sie „Linkverzeichnis“, was ich auch nicht besser finde.
Ich finde all diese Bezeichnungen nicht sonderlich hilfreich, weil sie syntaktisch statt semantisch orientiert sind.
„externe Quellen“?
== HTML == {{:HTML/Linkliste}} == CSS == {{:CSS/Linkliste}} == JavaScript == {{:JavaScript/Links}} == PHP == {{:PHP/Links}} == XML, DTDs und XSL(T) == {{:XML/Linkliste}}Ich sehe grad, dass das noch nicht überall auf den jeweiligen Portalseiten angekommen ist. Wer das nachholen möchte, bitte gerne!
Welche fehlen noch?
Bis demnächst
Matthias--
Rosen sind rot.-
Servus!
Ich sehe grad, dass das noch nicht überall auf den jeweiligen Portalseiten angekommen ist. Wer das nachholen möchte, bitte gerne!
Welche fehlen noch?
Hab ich dann doch selbst in die Hand genommen. (Ist das wirklich erst 4 Wochen her?)
Bis demnächst
MatthiasHerzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste
-
-
-
-
-
Hallo,
Ok. Auf der anderen Seite ist „Linkliste“ natürlich auch ein doofes Wort.
Aber „Linkliste“ kann man sehr schön zu „Lili“ abk.
Gruß
Kalk
-
-
-
-
-
-
-
-
Hallo Matthias,
Wie nützlich sind solche Linksammlungen heute denn noch?
Als Nachschlagewerk weiterhin durchaus sinnvoll.
Zur XSL-Familie sollte aktualisiert werden:
XSL 1.0 (Recommendation) -> Derzeit aktuell ist Version 1.1. http://www.w3.org/TR/xsl11/
XSLT 1.0 (Recommendation) -> Derzeit aktuell ist Version 3.0. http://www.w3.org/TR/xslt-30/
XPath 1.0 (Recommendation) -> Derzeit aktuell ist Version 3.1. http://www.w3.org/TR/xpath-31/
Grüße,
Thomas-
Servus!
Danke! Werde ich am Montag machen, wenn ich wieder in der Zivilisation bin.
Herzliche Grüße
Matthias Scharwies
--
Es gibt viel zu tun: ToDo-Liste
-