Suchmaschinentauglichkeit und
Web-Grundprinzipien erhalten
Ajax Technologie-Konferenz, Zürich 21. Juni 2006
Bernhard Seefeld, Endoxon
Jürg Stuker, namics
Für ein und alle Mal
- Per Heute
- sind Suchmaschinen-Crawler faul
- und
- führen kein JavaScript (JS) aus.
Fit für Suchmaschinen: Was ist wichtig?
- Vollständigkeit
- Selektivität
- Aktualität
- Trefferzitat
- Rang
- http://blog.namics.com/2006/06/optimale_websit.html
Beispiel: Vollständigkeit und Selektivität
- Ist das "richtig"
- oder das?
Beispiel: Trefferzitat (1 von 2)
- Dieselbe URL (mit zwei verschiedenen Queries)
Beispiel: Trefferzitat (2 von 2)
- Wer macht es besser?
Verschiedene Einsatzmöglichkeiten von AJAX
- AJAX als Zusatz
- Zusatz (z.B. "Suggest")
- *echter* Zusatz?
- AJAX Anwendung
- "One Page Website"
- "One Page Website"
- Grundfrage ist
- Welche Seiten URLs gehören in die Suchmaschine?
- Wie sollen die Seiten zitiert werden?
Test, test, test, test (mit dem Ziel zu Verstehen)
- Wie: Tools
- Lynx Browser (Site anschauen)
- wget (Base Page downloaden)
- Xenu's Link Sleut (Link Extraktion)
- Was: So tun, also ob ich ein Crawler bin...
- kein JavaScript
- keine Cookies
- Und: Im Serverlog schauen, was indexiert wird
Trefferzitat: Was steht drin?
- Page Title
- Inhaltszitat: Je nachdem
- Zitat aus dem Seitentext
- oder META Description
- oder Feed (RSS / Atom)
- oder aus einem Verzeichnis wie dmoz.org
- URL
Und wenn alles andere stimmt: Der Rang
- On Page Kriterien (in der Base Page)
- Häufigkeit: Text (Suchwort 3-5% des Textkorpus)
- Auffälligkeit: URL, Page Title, H1, H2 und oben im Text
- Reputation
- Verlinkung (insb. extern)
- Link Kontext
- Popularität
- Erstellen Sie häufig Inhalte, welche viele Menschen gerne lesen...
- Erstellen Sie häufig Inhalte, welche viele Menschen gerne lesen...
- http://blog.namics.com/seosem/
Also...
- Jede Seite (die ich in der Suchmaschine will)
- hat eine stabile und *eineindeutige* URL
- ist mit <a href="http://... verlinkt
- bringt (ohne JS, ohne Cookies und ohne Frameset) brauchbares (X)HTML zurück
- hat eine vernünftige (REST-)URL (möglichst ohne oder <2 Query Parameter)
- On Page Kriterien
- valides XHTML
- Page Title
- Suchworte im Text (3-5%)
- Link Building mit gutem Kontext
- Erstellen Sie häufig Inhalte, welche viele Menschen gerne lesen...
Links
Nebenwirkung AJAX?
User Erwartungen ..
User klicken auf einer Webseite
- auf etwas von dem sie hoffen, dass es sie ihrem Ziel näher bringt
- oder auf den Back Button
Und mit etwas Glück machen sie
- ein Bookmark, um später wiederzukommen
- verschicken die Seite an Freunde
- oder machen gar einen Link auf ihrer Seite
All das sollte wegen AJAX nicht aufgegeben werden!
.. erfüllen
Principle Of Least Surprise
Soll gleich wie bisher funktionieren:
- Bookmarks und Links
- Back Button
- Reload
- Open in New Window
Referenz
Architecture of the World Wide Web http://www.w3.org/TR/webarch/
Global naming leads to global network effects.
- Assign distinct URIs to distinct resources.
- A URI owner SHOULD provide representations of the identified resource consistently and predictably.
(Cool URIs don't change)
Bonus:
- A URI should make lossless transportation over the telephone at least worth a try
Links & Bookmarks
- Bookmarks (aus Browsermenu!)
- Seite per Mail verschicken
- Links
Geht das überhaupt?
Wie ändere ich die URI ohne Page Reload?
- Der #-Teil der URI.
Genannt "fragment identifier", aber meist "hash" - Konzipiert für in-page Navigation. Passt!
Referenz
Architecture of the World Wide Web:
"The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations."
Code!
- Setzen:
window.location.replace( window.location.search + '#' + state);
- Lesen: Beim laden der Seite und danach regelmässig überprüfen:
- State in URI = zuletzt geschriebener State?
Falls nein: State von URI auf Applikation übertragen
- State in URI = zuletzt geschriebener State?
State?
State enthält alles was es braucht um die Ansicht wieder herzustellen.
D.h. nicht die Daten selber.
State enthält nicht:
- Session ID
- Random IDs
Also gleich wie eine sauber geschriebene Webapplikation: Die komplette URI addressiert einen wiederherstellbaren Zustand der Applikation.
Test: URI in neues Browserfenster copy&pasten
Komplexe States
Was ist wenn der State zu lang für die URI ist?
- Eindeutiger Identifier als Teil der URI (addressierbarer (!) "Filenamen")
- Sonst lieber gar keinen State in URI als unvollständigen
Beispiele:
- Don't: example.com/spreadsheet#page1
(völlig verschiedene Spreadsheets haben die gleiche URI) - Do: example.com/spreadsheet/teilnehmer#page1
Links++
- AJAX = Web 2.0 Technologie? Vernetzung!
- AJAX über "Applikation im Browser statt Desktop" hinaus:
- example.com/mail#msgid=423784242@example.com via IM/Mail statt nochmals forwarden
- Spreadsheets: Interne Links ja bekannt. Jetzt auch 2-way Web-integriert?
- Kalender: Timeslots per Mail und IM
- youtube.com & co: mit #3:45 auf die beste Stelle linken?
- Ref: Doug Engelbart's Vision im Umgang mit Daten. Ende 60er!
Häufig ändernde States
- Müsste eigentlich funktionieren, oder?
- location.replace Technik: Keine History Einträge
- Aber: Default-IE macht Klickgeräusche
- Daher: Keine häufigen Änderungen in URI
- Kein Stand der Animation
- Cursor-/Scrollposition
- Evtl. Tree Aufklappzustand
Back Button
- Pflicht:
- Mit Back-Button zurück auf die AJAX Applikation verliert State nicht ("back-into-page")
- Kür:
- Back-Button innerhalb der AJAX Applikation
Pflichtteil
- State in URI löst das Problem
- Löst sogar Reload
- Falls State nicht (vollständig) in URI
- State in hidden fields speichern
- Geht aber bei Reload verloren
- Wirklich ein Problem?
- Sessioncookie oder Flash Storage
- Löst auch Reload
- Normaler Wiedereinstieg nur über #hash von Reload unterscheidbar
- State in hidden fields speichern
Kür
- Idee: Anklicken von Links simulieren ohne die Seite zu verlassen
- Technik 1: IFrames (IE 5.5+, Firefox)
- Technik 2: Hash in URI (Firefox, Safari)
IFrame Technik
Grundidee: Verstecktes IFrame, dessen Location neu gesetzt wird
- IFrame muss im HTML kreiert werden: Dynamisch erzeugte IFrames werden beim zurückkommen neu kreiert (-> Pflichtteil!)
- <title> im IFrame bestimmt Eintrag im History Menu
Implementation
- Schreiben
- Firefox/Safari: Reales Dokument laden,
- z.B. empty.html?ping und empty.html?pong und State im Hash
- z.B. form.html?<random> mit State in Form Variablen (copy state onLoad())
- IE:
- document.open(),
document.write(...state...),
document.close() - (Geht in Firefox nicht wegen Access Violation)
- document.open(),
- Firefox/Safari: Reales Dokument laden,
- Lesen:
- onLoad() im IFrame meldet sich beim parent
Hash in URI Technik
- Weil es zu schön und einfach wäre: IFrame History und Hash ändern vertragen sich in Firefox nicht
- Idee: #-link anspringen, mit location.href =
- Macht aber nur History-Eintrag, wenn Link auch existiert -> Link kreieren
- Link mit position=absolute auf aktuelle Scrollposition setzen
- Lesen: Timer überprüft regelmässig Inhalt von location.hash
Browsercheck
- IE sieht location.hash-Änderungen nicht...
- Kombination mit IFrame-Technik geht aber. Also Hashes setzen und History über IFrame handlen.
- Safari? location.hash lesen geht auch nicht.
- IFrames auch nicht
- Safari-Bug: history.length wird bei Back kleiner!
- States in hidden fields speichern (!), history.length als Index verwenden
Links
Links zu Libraries
Frameworks mit History Support
Open in New Window?
hrefs in Links nicht auf 'javascript:' oder '#' setzen, sondern auf Zielstate. Interaktion via onclick event machen.
- User sieht in Statuszeile was passieren wird (bei schönen URIs)
- Open in New Window, Copy Link, etc. funktionieren!
# vs /
- "Normale" Links haben / statt #
- Spätestens nach dem sie durch IPoV übertragen wurden haben das auch AJAX Links
- -> Redirect auf #-URL; serverside oder falls non-javascript Variante implementiert, clientside
- Hilft bei Pagerank und vor allem Anchors (Hallo Jürg)
- Diese URI in hrefs, ausgeschrieben URLs (printview!), etc. verwenden
Web Infrastruktur
Das war auf der Bühne. Was gibt es hinter der Bühne?
Ganz kurz: Webprinzipien beachten und ganze Internet Infrastruktur für sich arbeiten lassen!
- GET vs POST
- Caching
- Compression
Credits
Vorherige Publikationen von:
- Kevin Lynch
- Brad Neuberg
- Kewin Newman
- John Hornsy