molily: CodeGen 1.4 dank euch released - DANKE!

Beitrag lesen

Hallo, Phil,

Priorität 1 heißt Fehler, der unbedingt gefixt werden muss (imho), 2 dass die Änderung nötig ist, 3 dass die Anmerkung lediglich ein Verbesserungsvorschlag ist.

-- Interface

[3] Ich würde die Benutzerführung einfacher und verständlicher machen. Viele Formularfelder werden nur in der Hilfe erklärt. Stell dir vor du würdest CodeGen als HTML-Seite in JavaScript schreiben, dann müsstest du die Erklärungen auch "linearisiert" einbinen, sodass die einzelnen Funktionen als "Wizards" bzw. "Assistenten" agieren sollten.

-- Scrollbar

[2] Die erläuternde Grafik ist sehr unverständlich, da die Pfeile extrem verzweigt sind. Zwei oder drei Verzweigungen sind höchstens mit dem Auge nachvollziehbar. Richte den Text anders aus oder mache die Grafik größer, sodass die Beschreibungen beidseitis durch einfache Linien auf die Flächen zeigen können.

[3] Wenn man ein Hexcode eingibt oder durch den Farbwähler wählt, könnte sich die Hintergrundfarbe der Farbwählerbox der gewählten Farbe anpassen.

[3] Die eingegebenen Werte könnten geprüft werden: entweder drei- oder sechsstellig und bestehend aus [0-9a-fA-f].

[2] Der erzeugte Quellcode ist nicht XHTML-kompatibel.
Vgl. http://www.w3.org/TR/xhtml1/#C_13: "CSS style sheets for XHTML should use lower case element and attribute names."

-- Popup

[1] Es wird weiterhin href="JavaScript:PopUp()" erzeugt. Deren Problematk habe ich schon einmal erläutert. Vgl. erneut http://home.t-online.de/home/dj5nu/js-popup.html.

[3] Wenn man "javascript:" als Linkziel verwendet, dann würde ich es kleinschreiben, als nicht "JavaScript:". Ich weiß nicht, wie es mit der Kompatibilität aussieht. Für gewöhnlich wird es klein geschrieben.

[2] Das Eingabefeld "Titel" würde ich mit "Fenstername" benennen. Auch bei "Jedes PopUp muss einen Titel besitzen".

[2] Die Event-Handler onLoad und  onunLoad würde ich klein schreiben. Vgl. http://www.w3.org/TR/xhtml1/#h-4.2 "XHTML documents must use lower case for all HTML element and attribute names."

[3] Dass du die Erstellung von sich selbst öffnenden Popup-Fenster unterstützt und vereinfachst, finde ich persönlich bedenkenswert.

-- Metatags

[1] Es heißt richtig name="revisit-after", mit Bindestrich anstatt einem Blank.

[3] Das mit dem Wiederbesuch könntest du herausnehmen. Es gibt meiner Erfahrung nach keine Suchmaschine, welche diesen Metatag beachtet. Der Googlebot kommt wieder, wann er Lust hat bzw. je nach Popularität der Seite.

[3] Die Erläuterungen zu den einzelnen Feldern sind zwar gut und detailliert in der Hilfe nachzulesen, aber vielleicht könnte man sie durch Mouseover oder so etwas anzeigen lassen. Niemand schaut in die Hilfe bzw. erst wenn wirklich etwas schiefläuft.

[3] Ob <meta http-equiv="pragma" content="no-cache"> überhaupt einen Sinn hat und ob Browser sich danach richten, weiß ich nicht. Muss ich mich mal erkundigen.

[3] <meta name="generator" content="CodeGen"> finde ich nicht toll. :) Schließlich wird schon der Kommentar <!-- MetaTags erstellt mit CodeGen @ http://www.yubb.de --> eingebunden.

[3] "Sprache der Webseite" ist nicht ganz zutreffend. Eigentlich handelt es sich um den Zeichensatz, wie du auch in der Hilfe geschrieben hast.

-- Formular

[1] "Wie" würde ich umbennen. Mir fällt aber auch kein besserer Titel ein. :) "Herkunft" ist ja schon belegt (kollidiert mit "Ort ds Besuchers").

[3] MSN Messenger==MSM? In demn Falle würde ich "MSN-Nickname" oder so etwas als Bezeichnung verwenden. Genauso ICQ-Nummer und AIM-"Screenname" oder wie sich das nennt.

[3] Code ist immer noch suboptimal. Du könntest mit dem label-Element arbeiten und strong anstatt b verwenden. Die Tabelle müsste sich eigentlich einfach linearisieren lassen.

[1] Der erzeugte Code sieht wie ein komplettes HTML-Dokument aus. Nach Ende des form-Element bricht es jedoch ab. Ich würde dazu tendieren, nur das form-Element auszugeben.

-- Pulldown

[?] Das Pulldownfeld ist per se untauglich, wenn JavaScript abgeschaltet ist. Du müsstest das ganze Konzept ändern. Deshalb bemängele ich das nicht grundsätzlich.
Vielleicht könnte man ein noscript-Element als Abhilfe dazumachen, indem drinsteht, dass die Dropdown-Linkliste nur mit JavaScript funktioniert.

[3] Selbst mit JavaScript fände ich eine Lösung, bei der man die Seite auswählt und dann auf einen OK-Button klicken muss benutzerfreundlicher. Man würde dynamisch bei onchange die action des form auf den value der ausgewählten option setzen. Kryptisch gesprochen. :)

[1] Das mit dem document.location.replace ist m.E. extrem schwachsinnig, weil es den momentanen Eintrag in der History überschreibt. Stell dir vor jemand macht eine Dropdown-Liste mit verschiedenen externen Seiten - dem Benutzer wäre es nicht möglich, mit dem Back-Button auf die Seite zurückzukehren. document.location.href wäre afaik die bessere Variante

[1/?] Irre ich mich oder referenziert man auf ein Frame völlig anders als mit document.[fenstername]!?! Auf Popups und abhängige Fenster wird einfach mit [fenstername].location.href und bei Frames über top bzw. parent referenziert. Vgl. http://aktuell.de.selfhtml.org/tippstricks/javascript/fensterzugriff/index.htm
Da ist auf jeden Fall etwas faul, ich werde es morgen mal genauer ausprobieren, werde es dann mailen oder posten, je nachdem ob der Thread noch da ist.

-- ICQ

Nichts zu meckern, meine geforderten Verbesserungen wurden vorgenommen.

-- Links

[2] Die Problematik des der Regel bzw. des Selektors a { ... } habe ich schon geschildert (-> wirkt auch auf Anker). Ich würde es einfach weglassen. IMHO reicht
a:link, a:visited und a:hover. Für a:active ist im Interface leider kein Platz mehr, aber da würde ich ganz einfach a:hover und a:active die gleichen Regeln zuweisen, also mit den Eingaben bei a:hover auch a:active füllen. Hilfetexte und Formulareingabefeldbeschreibungen müsstest du entsprechend anpassen.

[3] Ich persönlich notiere keine Leerzeichen zwischen Attributname und Attributwert, also "color:#132456;" anstatt "color : #132465;". Spart Bandbreite. Bei den paar Definitionen würde ich auch die unnötigen Line Feeds wegmachen, also kurz und bündig:
  a:hover {color:#13456; text-decoration:none;}

-- Frames

[2] An sich eine gute Idee, jedoch müssten die Beispiele interaktiv erstellt werden. Vorschläge:

  • URIs der Frames sollten über Eingabefelder wählbar sein.
  • Die Framenamen *müssen* bezeichnend für den Frame sein ("navigation", "inhalt", "logo" usw.), deshalb muss man irgendwie den Zweck des Frames angeben können (vielleicht durch Radiobutton?).
  • Eingabefeld für den Seitentitel anstatt <title>Index</title>.
  • Der Inhalt des noframes-Elements könnte dann generiert werden.

[2] Eventuell sollte man per default für jeden Frame marginwidth="0" und marginheight="0" setzen. Für das ganze Frameset frameborder="0" framespacing="0" border="0", vgl http://selfhtml.teamone.de/html/frames/eigenschaften.htm#rahmen.
Ich gebe immer einen Mix zwischen proprietären und standardkonformen Attributen an, bspw.:
<frameset cols="50%,50%" border="0" frameborder="0" framespacing="0">
<frame name="navigation" src="navigation.html" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" noresize="noresize">  <frame name="inhaltsframe" src="murks.html" frameborder="0" marginwidth="0" marginheight="0" scrolling="auto" noresize="noresize">
</frameset>
Ob das alles sinnvoll ist, weiß ich nicht. Ich hatte immer Probleme mit Netscape. Laut Spezifikation http://www.w3.org/TR/html401/present/frames.html ist folgendes aus Selfhtml falsch: "Bei der Syntax, die von den Browsern unterstützt wird, werden die dazu nötigen Attribute im einleitenden <frameset>-Tag desjenigen Framesets notiert, für das die Angaben dann gelten - sie betreffen dann also alle Rahmen innerhalb des Framesets." Ich würde jedes Frame einzeln mit W3C-Attributen auszeichnen, wie es die Spezifikation vorsieht.

[1] <noframes>Ihr Browser unterstützt keine Frames!</noframes>
Jetzt machst du mich wütend! :) Bitte mache hier Links zu den Unterseiten, also mindestens
  <h1>{Seitentitel eingeben}</h1>
  <p><a href="{...}.html">{Frametitel}</a><br /> ...Links zu den Frames auflisten... </p>
Das könntest du ja wie oben beschrieben generieren. Die Inhalte müssen auf jeden Fall auch ohne Frames zugänglich sein.

[1] Das noframes-Element muss innerhalb des obersten frameset-Elements stehen, siehe http://www.w3.org/TR/html401/present/frames.html#h-16.4 und http://selfhtml.teamone.de/html/frames/definieren.htm#noframes.

[1] <body></body> muss rausfliegen.

[2] Die Dokumenttypdefinition sollte angegeben werden, auch wenn der Aufbau nur beispielhaft ist, es ist ja ein vollständiges Dokument. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> wäre die passende.

-- TXT->HTML

[2] Aus <h2>dddd</h2> sollte logischerweise <h1> werden. Wenn es dir zu groß ist, bieg es mit <font> oder Inline Styles (style="font-size:XXem") um.

[2] Das p-Element wird nicht geschlossen.

[3] (\r)\n -> <br>\r\n ist natürlich die einzige Art, wie man Fließtext einfach HTML-gerecht aufbereiten kann, aber vielleicht sollte man mit Absätzen (p-Elementen) arbeiten. Wäre natürlich komplizierter. Ich denke, für's erste reicht die simple Umwandlung.

-- Hilfe

[2-3] In der Hilfe sind mir einige Fehler bzw. eher sprachliche Ungenauigkeiten aufgefallen. Ich schreibe den Rest dazu morgen und poste oder maile es dir.

So, das war es für's Erste... für den Rest bin ich zu müde. :)
Ich überlege mir gerade, wieviel Arbeit du wohl darein gesteckt hast, ich habe von der Programmierung von Interfaces wenig bis gar keine Ahnung, habe mich immer geweigert, mit bspw. Delphi zu arbeiten (war mir zuviel Klickibunti, zu oberfkächenfixiert).
Eine JavaScript-Version wäre sehr aufwendig, aber möglich... diesen Frame-Algorithmus könnte ich vielleicht mal in JavaScript entwerfen...

Besonders ein Dank an ... ... ... (mist, nachricht kann nicht gefunden werden) denjenigen, der mir Fehler in den Codes aufgezeigt hat. Ich habe sie zum größten Teil zu Herzen genommen und versucht zu ändern... :)

War ich gemeint? :) Ach, helfe immer gerne...

Mathias