Saubere Technik f├╝r ein sauberes Netz - Kampf dem Spacerframe

und wie baut man so ein web?

Nicht nur um behinderten das Netz nutzbar zu machen, sondern auch auch aus ├Ąsthetischen Gr├╝nden ist Suchmaschinen) eines der wichtigsten Gebote. Sie spielt in der schnellen Darstellung, der maschinellen Indizierung (howto:web:www die tragende Rolle. Gutes Design ist wichtig, aber wirklich gutes Design ist auch barrierefrei. Wer Informationen in Bildern oder prosperit├Ąren gro├čvolumigen Dateien versteckt, vergeht sich an der ├ästethik. Schminken ist ein Kunst, vor allem im Netz.

Handwerk

Webseiten sind grunds├Ątzlich in offenen und freien Formaten zu schreiben. Die Betonung liegt auf selbst zu schreiben! Niemand will das gewurschtel aus irgendwelchen Wysiwig-Editoren sehen. Ordentliche Arbeit ist Handarbeit. Nichts gegen Contentmanagemntsysteme, darum geht es hier nicht. Denn auch diese brauchen templates udn die sind eben in Handarbeit ztu erstellen.

html & css

.html kombiniert mit howto:css steht f├╝r schnelle, sauberer vielschichtige Webseiten. How Many HTML Elements Can You Name in 5 Minutes?

Warum ist logisches html sinnvoll, warum soll man nicht f├╝r alles ein div nehmen und dann hin und her schieben. Mit den (wenigen) logischen html Elementen k├Ânnen ''die Maschinen'' einfach besser umgehen, so gibts viele Beispiele

  • eines der h├Ąufigsten Argumente f├╝r eine html ├ťberschrift (h2) ist meistens die Lesbarkeit durch eine Suchmaschine, (auch wenn diese Tatsache auch wieder zu komischen Ausw├╝chsen f├╝hrt=
  • letztens hab ich festgestellt das mein Druckertreiber einen ''tablehead'' als solchen erkennt und den Spaltenkopf auf jede gedruckte Seite schreibt;)

und nat├╝rlich javascript.

Responsive

[kleine elektronische Ger├Ąte](./p:Responsive Webdesign)) f├╝r ((howto:mobile) ist gar nicht so einfach, vor allem kann man soooo viel machen was oft gar nicht gut ist. Darum w├Ąre wichtig

testen

Persistenz

Persistenz ist so ein sch├Ânes Wort;) Aber bei aller der Frage nach rendereing, events und laufzeit. Es geht immer noch um Inhalte und die m├╝ssen irgendwo gespeichert werden * file * db * mails

Maschine

CMS oder Framework

html und JS zu verstehen ist wichtig, genauso wie ein Schreiner ein St├╝ck Holz auch mit Hand Werkzeugen bearbeiten k├Ânnen muss. Nat├╝rlich aber ist f├╝r vieles ein Content-Management-System eine strukturierte und arbeitserleichternde Anwendung.

Es erm├Âglicht vor allem den Inhalt (Texte erstellen, redigieren, kommentieren etc) von der Darstellung und der Funktion zu l├Âsen. Was zwar nicht immer funktioniert und viele Enduser eben kein content einpflegen, aber k├Ânnten.

Ich selbst nutze inzwischen gern Wordpress, da die User schnell eigene normale Dokumente schreiben kann. So kann die klassiche Pressemitteilung, der Blogbeitrag, Stellen-Ausschreibung oder Newsletter aber auch die "statischere" Seite von der jeweiligen Fachperson geschrieben und ver├Âffentlich werden. Ich kann mich dennoch ausenrum um Spezialit├Ąten wie API-Anbindungen, Abh├Ąngikeiten etc k├╝mmern.

Empfehlbar sind noch so Systeme MODx oder Drupal f├╝r speziellere Anwendung. Und im ''Im Endeffekt z├Ąhlt aber nicht nur die reine Qualit├Ąt, sondern eben auch die Verbreitung eines Systems, denn je mehr Entwickler sich auf eine Plattform einschie├čen, desto besser f├╝r den Kunden, weil er leichter gute Entwickler f├╝r sein laufendes Projekt findet...''

Was soll ein CMS k├Ânnen * Inhalt * Einzelseiten (inkl Metaseiten, Systemseiten) und Listen (aus Kategorien) * in einfachen html ohne unn├Âtige classen und divsuppen * eine vereinfachte Auszeichnungssprache am besten markdown * URLs organisieren (p:Clean_URL, sparsame Kategorisierung) * eine optionale Indexstruktur mit Tags oder Kategorien (keine aufzwingende) * und ein mindestens ein frontside editor (verwurschtelte adminbackends kann man sich sparen) * Zugriffsrechte * optional fremdusermanagement (OpenID) * Versionierung * rss (von mir aus auch so nen automatic twitterdingens) Nicht nur blogs leben von der Ver├Ąnderung * redirect * Fehlerverwaltung (404 etc) * Suche (evtl extern) * Kommentare (evtl extern Disqus Comment System) * dann mit mit Spam Abwehr (CAPTCHA, dnsbl etc) * nette Fetaures die nativ oder per plugin umsetzbar sind * Table of Contents * Katgorie in Seite auflisten (aka DPL)

Um Webseiten zu bauen nutz ich gern ,

  • wordpress wenn es vor allem um regelm├Ą├čige Ver├Âffentlichungen geht.
  • wikis wenn user zusammenh├Ąngende Seiten bearbeiten sollen, denn ein Wiki folgt ganz dem dokumentenorientieretn Ansatz und der ist dem User einfach erkl├Ąrbar. Wenn man editbutton und die Funktion f├╝r neue Seiten verstanden hat, weis er alles was er braucht. (In Joomla m├╝sste er erst das backend und darin den Men├╝punkt und die 2-3 dazugeh├Ârigen Contents finden dohhh). F├╝r kleinere Webseiten gern Dokuwiki (z.B. barbarasailer.de, inicon.com), was den Vorteil hat keine Datenbank zu ben├Âtigen, f├╝r gr├Â├čere Webseiten aber auch gern Mediawiki (elta-rhine.de)
  • am liebsten aber mein staticsitegenerator drfrederson, der kann das gleiche wie ein Wiki (editbutton) braucht wie dokuwiki keine Datenbank, nutzt markdown und kommt auf dem Server sogar ohne php aus. Au├čerdem kann man mehr konfigurieren.

Alternativ k├Ânnte man ein nosql-cms nutzen.

w3techs.com gibt eine ganz gute ├ťbersicht wer wie was verwendet, aber leider ohne subdomains (dohh) sprich de.wikipedia.org wird nicht ber├╝cksichtigt.

Interaktion

Wer auf einer Webseite nicht nur lesen will, sondern auch eine bestimmte Prozess durchlaufen will beginnt eine Interaktion (vulgo web2.0) mit dieser * Anmelden * Shops * Abstimmung (Polls oder doddle)

das kann nat├╝rlich auch durch Plugins erf├╝llt werden (wenn se sauber sind)

technisch: * API * saubere hooks f├╝r plugins * MVC unf so kram * theming * natives jQuery (schon mal f├╝r fancyboxes und slideshows) * https * Export/Importe * Backup

Seltene Zusatzfunktonen, die man nicht unbedingt immer braucht * surveys * shops

Webserv{er|ice}

Zwar k├Ânnen die meisten CMS immer nicht nur Texte ausliefern sondern auch Bilder, Dateien ausliefern und sogar verwalten, aber eben nicht alles. Oft ist es sehr praktikabel sich eine Webanwendung aus verschiedenen Webservice zu kombinieren.

Dateien und Bilder

Bilder sind ja auch nur Dateien

Was w├╝rde ich mir von einem Dateiserver erwarten * der upload sollte einerseits ├╝ber (httpinterface (evtl auch im Bulk, was derzet nur per flash m├Âglichist) aber auch zus├Ątzlich +ber Filetransferschnitstellen wie ftp oder ssh m├Âglich sein (wenn man mal richtig viel hat) * Dateinamen wie ''├ľsterreich im Herbst.jpg'' sollten automatisch auf eine URL lesbares und eventuell ver├Ąndertes Format gebracht werden(z.B. ''2011_oesterreich_im_herbst.jpg'') * die Gesamte URL verk├╝rzen k├Ânnen * sharding und syncing (homerechner, webfreigabe, handythumbs)

und was zus├Ątzlich von einem Bilderserver und per dev:standardimageurl bilderapi

  • resize per URL (dokuwiki) ''example.net/imager.php?pic=1234&width=250'' (auch f├╝r thumbs)
  • Cropping auch per URL ''example.net/imager.php?pic=1234&width=250&height=50&x=190&y=125''
    • zur Not auch per css

Und das alte spacergif bekommt man auch per base64, holft aber auch wenn man auf dem background linien braucht (mit repeat-x oder x kombinieren)

Galerien

Galerie ist nicht gleich Galerie, es gibt unterschiedliche Anforderungen

  • hat man viele Bilder oder unterschiedliche (Einzleforts von Personen anstatt ein paar Impressionen) so k├Ânnen thumbnails helfen galleria.io
  • automatisches Abspielen der Bilder (autoplay)
  • ├ťberg├Ąnge
  • Zoom (fancybox)
  • URLs mit hashtag (''hausbau.html#2'')

Bildergalerien kann man in zwei Varianten angehen:

  • Alle Bilder der Galerie als html-Bilder () (z.B. mit einer html liste) und dann per JS als klickbare Galerie ├╝bereinander gelegt. galleria.io cdn ist ein einfaches Non-Obstrusiv Plugin.
  • Bilder als html Links () mit Ziel auf das Bild in voller Gr├Â├če. Dabei kann man ein thumbnail als "linktext" nutzen.

Die linkversion hat den Vorteil dass nonJS user thumbnails bekommen und per tabbrowsing einzelne Bilder laden, w├Ąhrend beid er img-L├Âsung immer alle Bilder vorgeladen werden.

Nicht verwenden sollte man flash oder JS-JSON L├Âsungen.

Entwickler

''In der Nacht als ich PHP gelernt habe, dachte ich: morgen baue ich das beste CMSCRMERPshopAPIservi-System ever!!'', die ern├╝chterung das man nicht alle Problem so eifnach l├Âsen kann ohnenicht gelich weider neue zu erschaffen kam am n├Ąchsten morgen. Bei manchen kommt sie nie.

Bei der Auswahl eines SoftwareSystems muss man vor allem den Erschaffer betrachten. Egal ob es sich um eine Herstellerfirma handelt oder eine Developercommunity- * Developer: ist die Community oder Firma, gro├č genug um alle anstehenden Aufgaben zu erf├╝llen, aber klein genug um Feinstes abzuliefern * Bekommt man ausreichenden unabh├Ąngigen und unterschiedlichen (Niveau) Support? Bei den wirklich gro├čen OpenSource Systemen findet man mit einer Googel Anfragen meist mehr udn bessere Antworte als bei einem kommerziellen Support. * Fehelermanagement, wo k├Ânne Fehler gemeldet werden (Bugtracker) und wie werden diese verarbeitet * Schnittstelle * Code: Alter, Qualit├Ąt, Ver├Ąnderung

Ein System selbst, innerhalb einer Firma aufzubauen, zu pflegen und anzupassen ist quasi unm├Âglich. Es fehlt meist an Entwickler (gro├če Systeme haben 10 - 20 Vollzeit├Ąquivalententwickler drauf). Und echtem harte feedback.

tectec

  • Model View Controller
  • Darstellung
    • falsh nur wenns nicht anders geht (kopieren, derezit noch videos)
  • logik jquery
    • selektieren
    • absenden
    • sortieren
  • persistenz
    • weniger serialisieren (magento, wordpress, medaiwiki??)
    • Dokumenten-Datenbanken die direkt JSON fressen
      • CouchDB
      • MongoDB
      • ... ?

Qualit├Ąt

Auf eine sauberer Einhaltung aller Seiten und css dateien ist zu achten. Das kann man nat├╝rlich einfach mit den Validierungstools des w3c.org ├╝berpr├╝fen. *validator.w3.org - Markup Validation Service *jigsaw.w3.org - W3C CSS-Validierungsservice *Offline multipage analyse * * Weiter kann man sich mit browsershots.org screenshots mit den g├Ąngigsten browsern anzeigen lassen.

bloat

Here is what I recommend for a balanced website in 2015: A solid base of text worth reading, formatted with a healthy dose of markup. Some images, in moderation, to illustrate and punch up the visual design. A dollop of CSS. And then, very sparingly and only if you need it, JavaScript.