netzbegruenung / green-spider Goto Github PK

Das ursprünglich von Facebook eingeführte OpenGraph-Protokoll legt einige Konventionen fest, um mit Meta-Tags bestimmte Informationen in eine Site einzubetten. Zu diesen Informationen gehört:

• og:title: Spezieller Titel zur Verwendung bei Verbreitung in Social Media Plattformen
• og:image: URL eines Vorschaubilds, für denselben Verwendungszweck
• og:type: Art der Seite
• og:url: Kanonische URL der Seite

Die sachgemäße Anwendung der beiden zuerst genannten Tags ermöglicht grundsätzlich eine verbesserte Darstellung bei der Verbreitung einer URL auf Plattformen wie Twitter oder Facebook. Ohne og:image wird beispielsweise der innerhalb der Seite nach einem geeigneten Bild gesucht. Dies führt nicht immer zu vorhersagbaren Ergebnissen.

Wer die Darstellung seiner Inhalte auf Social-Media-Kanälen professionell optimiert, muss auf diese Tags setzen. Daher sollte die Nutzung durch GREEN SPIDER geprüft und empfohlen werden.

Dieser Vorschlag kam von einem Verantwortlichen für die https://gruene-muenchen.de website.

Es wäre schön, wenn zu den Sites Screenshots der Startseite angezeigt würden. Damit bekäme man einen Eindruck des Design-Spektrums.

Wir können ermitteln, ob eine Site bei Aufruf einer nicht vorhandenen URL den erwarteten 404 Status Code ausgibt.

Mit netzbegruenung/green-spider-webapp#15 werden keine JSON-Exporte mehr erzeugt bzw. im GitHub repository veröffentlicht.

Der Screenshotter muss daher direkt die spider-results Datenbank auslesen, um an die Ziel-URLs der Sites zu kommen, für die Screenshots erstellt werden sollen.

Aktualität spielt für die Relevanz bei Nutzer*innen sowie Suchmaschinen eine bedeutende Rolle.

Bei Sites, die einen oder mehrere Feeds anbieten, können wir auf dieser Basis feststellen

• wann der letzte Artikel veröffentlicht wurde
• wie häufig im Durchschnitt neue Artikel veröffentlicht werden

Auf Basis eines Vergleichs mit anderen Sites sollte es möglich sein, hier einen Mindestwert für die Vergabe eines oder mehrerer Punkte festzulegen.

Der Wert für encoding scheint nur durch den charset im Content-type header beeinflusst zu werden. Ein charset Meta-Tag wird im Moment nicht berücksichtigt.

Das ist im Moment kein großes Problem, weil das Attribut nicht weiter ausgewertet wird.

In der Webapp passiert schon zu viel Logik. Eigentlich sollte es die Aufgabe der Webapp sein, die Spider-Ergebnisse anzuzeigen, wie sie sind. Tatsächlich passiert hier aber auch Daten-Aufbereitung. Das sollte sauberer getrennt werden.

Fehlermeldung:

INFO:root:Job http://gruene-cw.de/aktuelles/ writing to DB
ERROR:root:Could not write result: 503 Connect Failed
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/google/api_core/grpc_helpers.py", line 57, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/grpc/_channel.py", line 547, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/usr/local/lib/python3.6/site-packages/grpc/_channel.py", line 466, in _end_unary_response_blocking
    raise _Rendezvous(state, None, None, deadline)
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with:
	status = StatusCode.UNAVAILABLE
	details = "channel is in state TRANSIENT_FAILURE"
	debug_error_string = "{"created":"@1554227417.226137000","description":"channel is in state TRANSIENT_FAILURE","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":2918,"grpc_status":14}"
>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/cli.py", line 82, in <module>
    spider.work_of_queue(datastore_client, args.kind)
  File "/spider/spider.py", line 73, in work_of_queue
    job = jobs.get_job_from_queue(datastore_client)
  File "/usr/local/lib/python3.6/site-packages/tenacity/__init__.py", line 292, in wrapped_f
    return self.call(f, *args, **kw)
  File "/usr/local/lib/python3.6/site-packages/tenacity/__init__.py", line 358, in call
    do = self.iter(retry_state=retry_state)
  File "/usr/local/lib/python3.6/site-packages/tenacity/__init__.py", line 319, in iter
    return fut.result()
  File "/usr/local/lib/python3.6/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/lib/python3.6/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.6/site-packages/tenacity/__init__.py", line 361, in call
    result = fn(*args, **kwargs)
  File "/jobs/__init__.py", line 157, in get_job_from_queue
    with datastore_client.transaction():
  File "/usr/local/lib/python3.6/site-packages/google/cloud/datastore/batch.py", line 293, in __enter__
    self.begin()
  File "/usr/local/lib/python3.6/site-packages/google/cloud/datastore/transaction.py", line 210, in begin
    self.project)
  File "/usr/local/lib/python3.6/site-packages/google/cloud/datastore_v1/gapic/datastore_client.py", line 346, in begin_transaction
    request, retry=retry, timeout=timeout, metadata=metadata)
  File "/usr/local/lib/python3.6/site-packages/google/api_core/gapic_v1/method.py", line 143, in __call__
    return wrapped_func(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/google/api_core/retry.py", line 270, in retry_wrapped_func
    on_error=on_error,
  File "/usr/local/lib/python3.6/site-packages/google/api_core/retry.py", line 179, in retry_target
    return target()
  File "/usr/local/lib/python3.6/site-packages/google/api_core/timeout.py", line 214, in func_with_timeout
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/google/api_core/grpc_helpers.py", line 59, in error_remapped_callable
    six.raise_from(exceptions.from_grpc_error(exc), exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.ServiceUnavailable: 503 channel is in state TRANSIENT_FAILURE

Wir sollten es mit retries versuchen.

Unsere entscheidenden Funktionen sollten einfach granular getestet werden können. Dazu gehört:

• Auslesen einer HTML-Seite
• Berechnen der Punktzahl

Wir sollten erheben, womit die Site gehosted wird, z. B.

• GCMS Typo3 (http://gruenes-cms.de/)
• Typo3 Grüne (https://typo3-gruene.de/)
• Wordpress mit Urwahl3000 (https://www.urwahl3000.de/)
• Anderes Wordpress
• Anderes Typo3
• Sonstiges

Aktuell dauert es selbst über einen lokalen Server geladen 23 Sekunden, bis die Anwendung aufgebaut ist.

Lighthouse performance audit:

Performance profile

Hier kann einiges optimiert werden:

• Die spider_results.json sollte nur die benötigten Inhalte enthalten.
• Daten zu Screenshots können nach dem Rendern der Tabelle geladen werden.
• Das "lazy loading" von Icons scheint nicht zu funktionieren und muss gefixt werden.
• Das Erzeugen der Tooltips scheint sehr lang zu dauern. Hier müsste man sich ansehen, ob es das verzögert passieren kann, und ob es außerdem weiter optimiert werden kann.
• Möglicherweise sind andere Methoden zur Erzeugung der Tabelle performanter als jQuery append(htmlString). [1]
• Möglicherweise lassen sich Layout Reflows unterbinden, indem Größenangaben für Tabellenfelder schon vorher festgelegt werden. Oder indem Elemente erst ganz zum Schluss ins document eingehängt werden.

[1] https://howchoo.com/g/mmu0nguznjg/learn-the-slow-and-fast-way-to-append-elements-to-the-dom

Es sieht so aus, als würden in der Webapp nur Sites angezeigt, die erreichbar waren. Damit fallen einige mit schwerwiegenden Problemen leider durchs Raster. Wir sollten dafür sorgen, dass alle im Report landen und angezeigt werden.

Der Stand der Tabelle sollte nachvollziehbar sein.

Aktuell wird eine Liste aller Sites zum Client übertragen, bevor Nutzer mit der Webapp interagieren können. Das dauert inakzeptabel lang.

Wir sollten auf eine serverseitige Such-API auf Basis von ElasticSearch umstellen.

Damit würden erst Daten zum Client übertragen, sobald Nutzer einen Suchbegriff eingeben. Allerdings würden nur die zur suche passenden Treffer übertragen. Die dabei anfallenden Ergebnisgrößen sind in aller Regel nur ein Bruchteil der gesamten Liste. Ausnahmen sind Suchbegriffe wie gruen oder www, die viele Treffer erzeugen.

EIn weiterer Unterschied wäre, dass wir die Offline-Fähigkeit verlieren. Die hat aber ohnehin keinen hohen Stellenwert.

Indexierung

• Wir wollen die Daten im Suchindex so aktuell wie möglich halten. Aktuell arbeiten wir mit bis zu 15 Minuten Verzögerung durch Caching.
• Einfache Lösung: periodisch einen Job ausführen, der die neusten Datensätze aus der Ergebnis-Datenbank liest und in den Index schreibt.
• Zusätzlich sollten veraltete Ergebnisse aus dem Index entfernt werden.

TODO

• ElasticSearch Docker Image auswählen
• ElasticSearch Schema anlegen, Indexierung implementieren
• API umschreiben
• Webapp umbauen
• Deployment anpassen

Google interessiert sich bei (lokalen) Organisationen für strukturierte Daten. Siehe dazu https://developers.google.com/search/docs/guides/sd-policies

Unterstützte Formate:

• JSON-LD (recommended)
• Microdata
• RDFa

Beispiel für einen Eintrag mit JSON-LD:

<script type="application/ld+json">
{
  "@context" : "http://schema.org",
  "@type" : "Organization",
  "name" : "BÜNDNIS 90/DIE GRÜNEN Ortsverband Hintertupfingen",
  "url" : "https://gruene-hintertupfingen.de/",
  "logo": "https://gruene-hintertupfingen.de/logo.png",
  "contactPoint" : [{
    "@type" : "ContactPoint",
    "telephone" : "+49 1234 4940",
    "contactType" : "Allgemeiner Kontakt",
    "availableLanguage": ["German"]
  }],
  "sameAs" : [
    "http://www.twitter.com/gruene-hintertupfingen",
    "http://www.facebook.com/gruene-hintertupfingen"
  ]
}
</script>

Dazu kann beispielsweise auch eine Adresse angegeben werden.

Wir sollen hierfür eine Prüfung und idealerweise eine Validierung einbauen und einen Punkt vergeben.

Framesets und Frames sind nahezu grundsätzlich eine Einschränkung der Benutzerfreundlichkeit, der Barrierearmut, sowie der Suchmaschinentauglichkeit. Und es gibt sie tatsächlich noch. Zwar selten, aber es gibt sie.

Aktuell bekommt eine Seite wie https://gruene-ml.de/wordpress/strasslach/ die Höchstpunktzahl, obwohl sie keinerlei relevanten Inhalt enthält.

Wir sollten ein grundlegendes Kriterium im Sinne von "Seite enthält relevante Inhalte" einführen. Hierzu würde es reichen, die reinen Textmenge auf einer Seite zu messen. Im Vergleich unter allen Sites sollte ermittelbar sein, was ein typischer Wert und was ein Mindestwert sein dürfte.

Problem

Wir Laden jede Seite mehrfach. Bislang wurde jede geprüfte Seite (bis zu 4 je Site) durch requests geladen und mit BeautifulSoup verarbeitet.

Durch #29 wird jede geprüfte Seite ein weiteres Mal geladen und mit selenium verarbeitet. Hierbei werden auch verknüpfte Ressourcen geladen.

Dazu kommt noch die Screenshot-Funktion, durch die eine Seite je Site zwei weitere Male geladen wird, ebenfalls einschließlich der verknüpften Ressourcen.

Das macht je Site zwischen 4 und 10 Seitenaufrufen.

Lösungsvorschlag

Dies alles ließe sich wahrscheinlich gut über Selenium erledigen. Das Erstellen der Screenshots könnte ebenfalls durch Selenium auf Basis der einmalig geladenen Seite erledigt werden (Fenstergröße zwischen den Screenshots ändern).

Voraussetzung sollte sein, dass der Spider in einem Docker-Container läuft (#28) und nicht der PhantomJS-Treiber genutzt wird (deprecated), sondern Chrome oder Firefox.

Wenn die getestete Site mit einem Redirect antwortet, wird als Antwortzeit die für den ersten Request erfasst (der mit Redirect beantwortet wird) und nicht der letzte (der die Seite ausliefert). Damit kommt es in solchen zu Fällen in der Regel zur Angabe eines zu niedrigen Wertes.

Ich möchte gerne ein weiteres Prüfkriterium aufnehmen:

Werden beim Ausführen des Codes der Seite JavaScript-Fehler gemeldet?
nein=gut, ja=schlecht

Auch wenn JavaScriptFehler für Endnutzer*innen nicht unbedingt ein Problem darstellen, kann das Auftreten von Fehlern ein Hinweis darauf sein, dass mit der Site etwas nicht stimmt und sich jemand mit Sachverstand diese mal genauer ansehen sollte.

Zur Umsetzung:

Aktuell werden beim Erzeugen der Screenshots mit Selenium und Chromedriver bereits JavaScript-Fehler ausgegeben. Durch Aufruf der Seite mit Selenium ist es also möglich, die Fehler zu erfassen. Jedoch sollte das unbedingt unabhängig vom Erzeugen der Screenshots passieren.

In #30 ist der Wunsch beschrieben, eine Seite möglichst nur einmal aufzurufen. Ich habe außerdem einen PR in Arbeit, der den Spider insgesamt auf Selenium umstellt. Damit wäre das sicher gestellt. Dann sollte es relativ einfach sein, die Fehlerausgabe aufzufangen uns auszuwerten.

Es wäre schön, im Report ein Kriterium für die Nutzbarkeit mit mobilen Endgeräten zu haben.

Wir sollten Daten darüber sammeln, welche Cookies die Site setzt. Dazu gehören Details wie

• Lebensdauer (bzw. Session-only)
• Domain
• Größe in Bytes
• Sicher (HTTPS-only) oder nicht

Hier ist grundsätzlich zu unterscheiden:

• Cookies, die vom Server gesetzt werden, der die (Start-)Seite ausliefert
• Cookies, die von anderen Servern (Bilder, JavaScript, Tracking-Dienste, ...) bzw. anderen Domains gesetzt werden

Erstere können beispielsweise mit requests gesammelt werden. Um letztere zu bekommen, müssen wir die Seite mit einem tatsächlichen Browser laden.

Anwendungsmöglichkeiten:

• Aussagen über Datensparsamkeit bzw. Datenschutz und entsprechende Empfehlungen
• Aussagen über Performance bei Seiten mit vielen HTTP-Requests ("Serve static resources from a cookie-free domain")

Wir sollten Details zu HTTPS-Zertifikaten erfassen und Aussagen darüber treffen können,

• wann ein Zertifikat abläuft
• ob ein Zertifikat für den Hostnamen gültig ist
• ob ein Zertifikat von einer allgemein vertrauenswürdigen CA stammt
  • ob das Zertifikat von einer CA stammt, die von Chrome (demnächst) als nicht vertrauenswürdig erachtet wird (https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html)
• ob die CA chain komplett ist

Allgemeine Info:

• https://developer.mozilla.org/en-US/Apps/Progressive
• https://developers.google.com/web/progressive-web-apps/

Welche Vorteile wir genau erwarten, wäre noch genauer zu ermitteln. Der Offline-Speicher von Daten wäre ein erster Vorteil, der das Laden der Anwendung erheblich beschleunigen dürfte.

Kommunikation zum Thema Datenschutz ist nicht nur gesetzlich geregelt, es wird auch zunehmend als vertrauensbildend gesehen.

Ich möchte ungerne den Eindruck erwecken, dass GREEN SPIDER den Website-Betreibern irgend eine Sicherheit bieten kann, dass sie Anforderungen der DSGV mit ihrer Site erfüllen.

Wir können allerdings ein paar Anzeichen prüfen, dass das Thema Datenschutz behandelt wird und, falls diese Anzeichen fehlen, eine entsprechende Warnung aussprechen. Was wird evtl. prüfen können:

• Ist ein Link "Datenschutz" (oder evtl. ähnlich) vorhanden?
• Gibt es einen Opt-in bzw. Opt-out-Hinweis?

PhantomJS für selenium ist deprecated und vergleichsweise langsam. Wir sollten auf Chromedriver umstellen.

Beispielcode: http://chromedriver.chromium.org/getting-started

Bestimmte Angaben in einer robots.txt und Meta-Tags können dazu führen, dass Suchmaschinen die Site oder Teile davon nicht erfassen. Und eine URL, die nicht erfasst wird, kann auch nicht gefunden werden.

Der Check sollte im ersten Schritt prüfen, ob die Indexierung der Einstiegs-URL(s) durch die populärsten Suchmaschinen in irgend einer Form verhindert wird.

Wir wollen für alle angezeigten Empfehlungen Texte in der Anwendung haben, wie im Dummy in #76 zu sehen.

Es sollte dargestellt werden, wie die Gesamtpunktzahl für eine Site zustande kommt.

Z. B. könnte bei mouse-over oder Klick auf die Punktzahl ein Overlay erscheinen.

Beispiel "Harsefeld":

Die ursprüngliche und angezeigte URL ist http://www.gruene-harsefeld.de/home/. Diese führt tatsächlich auf eine 404 Fehlerseite.

Der Spider ermittelt tatsächlich die richtige kanonische URL https://gruene-harsefeld.de/

Wir sollten dafür sorgen, dass die kanonische URL angezeigt wird, und nicht die ursprünglich eingegebene. Oder idealerweise beides.

Ich markiere das mal als Bug, weil es gegen jede Intuition ist.

Für den dauerhaften Betrieb und Ausbau möchte ich gerne die folgenden Ziele verfolgen:

• Häufiges, paralleles Crawlen: Spider sollen häufig (mind. täglich) laufen können und Ergebnisdaten schnell und automatisch zur Verfügung stellen.

  • Hintergrund: Wir wollen ermöglichen, dass Verbesserungen sowie neue Probleme (Site nicht erreichbar?) zeitnah festgestellt werden. Im Fall eines Problems ist eine Benachrichtigung der Besitzer*innen denkbar.

• Immer aktuelle Daten in Webapp: Die Webapp (Reporting) sollte je Site immer die aktuellsten Daten nutzen und anzeigen.

• Tiefer crawlen: Spider sollen einzelne Sites tiefer crawlen können als bisher und mehr Kriterien auswerten. In jedem Fall sollen mehr Ressourcen je Site herunter geladen werden, um Empfehlungen zu geben (z. B. Bilder, Feeds). Denkbar ist, dass wir ganze Sites crawlen.

• Historische Daten sollen gespeichert werden, so dass Verbesserungen/Veränderungen an Sites sichtbar werden können.

• Modularisierung: Komponenten sollten möglichst unabhängig von einander gepflegt und deployt werden können.

Aktuell warnt der Browser wegen mixed content, weil die Seite selbst über HTTPS geladen wird. Wir sollten die Icons herunter laden und selbst über HTTPS hosten.

Ladezeiten haben negativen Einfluss auf die User Experience und das Ranking in Suchmaschinen.

Wir sollten grundlegende Daten dazu sammeln, wie schnell eine Seite lädt. Dies kann Anlass dazu geben, den Aufbau einer Site zu prüfen und ggf. Optimierungen vorzunehmen.

Beispiel: URL ist http://www.gruenestelle.de/#Startseite

Antwort ist ein Redirect

HTTP/1.1 301 Moved Permanently
Date: Mon, 09 Apr 2018 21:38:23 GMT
Server: Apache
X-Powered-By: PHP/5.3.2-1ubuntu4.28
Location: https://sedo.com/search/details.php4?language=d&domain=gruenestelle.de&partnerid=50162
...

sedo.com ist eine Domainbörse. Die Site sollte daher als defekt gekennzeichnet werden.

Die Daten für diese URL sehen so aus:

  {
    "canonical_urls": [
      "https://sedo.com/search/details/?language=d&domain=gruenestelle.de&partnerid=50162&origin=partner"
    ],
    "hostnames": [
      {
        "aliases": [],
        "input_hostname": "gruenestelle.de",
        "ip_addresses": [
          "95.130.17.36"
        ],
        "resolvable": true,
        "resolved_hostname": "gruenestelle.de"
      },
      {
        "aliases": [],
        "input_hostname": "www.gruenestelle.de",
        "ip_addresses": [
          "95.130.17.36"
        ],
        "resolvable": true,
        "resolved_hostname": "www.gruenestelle.de"
      }
    ],
    "input_url": "http://www.gruenestelle.de/#Startseite",
    "resolvable_urls": [
      {
        "error": null,
        "redirects_to": "https://sedo.com/search/details/?language=d&domain=gruenestelle.de&partnerid=50162&origin=partner",
        "url": "http://gruenestelle.de/"
      },
      {
        "error": null,
        "redirects_to": "https://sedo.com/search/details/?language=d&domain=gruenestelle.de&partnerid=50162&origin=partner",
        "url": "http://www.gruenestelle.de/"
      },
      {
        "error": {
          "message": "HTTPSConnectionPool(host='gruenestelle.de', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x110fd1630>: Failed to establish a new connection: [Errno 61] Connection refused',))",
          "type": "<class 'requests.exceptions.ConnectionError'>"
        },
        "redirects_to": null,
        "url": "https://gruenestelle.de/"
      },
      {
        "error": {
          "message": "HTTPSConnectionPool(host='www.gruenestelle.de', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x110fb8f28>: Failed to establish a new connection: [Errno 61] Connection refused',))",
          "type": "<class 'requests.exceptions.ConnectionError'>"
        },
        "redirects_to": null,
        "url": "https://www.gruenestelle.de/"
      }
    ],
    "urlchecks": [
      {
        "content": {
          "canonical_link": null,
          "encoding": "utf-8",
          "feeds": [],
          "generator": "TYPO3 CMS",
          "icon": null,
          "opengraph": null,
          "title": "gruenestelle.de steht zum Verkauf - Sedo GmbH"
        },
        "duration": 831,
        "error": null,
        "status_code": 200,
        "url": "https://sedo.com/search/details/?language=d&domain=gruenestelle.de&partnerid=50162&origin=partner"
      }
    ]
  }

Auffällige und verallgemeinerbare Kriterien hier sind:

• Domain der kanonischen URL stimmt nicht mit der bekannten Domain überein
• In der Domain kommt nicht gruen (oder verwandte Schreibweise) vor

Wir sollten versuchen, den Grund für das Fehlen von Screenshots transparent zu machen.

Dafür müsste die Logik von screenshotter geändert werden. Es sollte nicht nur im Erfolgsfall ein Datensatz geschrieben werden, sondern auch im Fall eines Fehlers. Darin sollte entweder für Endnutzer verständlich, oder maschinell lesbar, der Grund für das Fehlen des Screenshots enthalten sein.

in
rating/contact_link.py

if link['text'].lower() == 'kontakt':
  urls_with_contact_link += 1

besser wäre

if link['text'].lower() == 'kontakt':
  urls_with_contact_link += 1
  break

Wir sollten eine Continuous Integration pipeline aufbauen, um Pull Requests automatisiert zu testen. Anbieter wie TravisCI sind kostenlos für Open Source Projekte.

Siehe #31 für erste Unittests.

Sollte zu einer URL keine IP-Adresse ermittelbar sein, ist das eine deutliche Warnung wert.

Beispiel: http://www.gruene-rheiderland.de/

Das entsprechende Feld sollte rot und mit ❌ gekennzeichnet werden.

Die Site http://www.gruene-dannstadt-schauernheim.de/ antwortet aktuell mit einem 403 Fehler. Trotzdem wird sie in den Ergebnissen als erreichbar gewertet.

Bei 4** Fehlern sollte die Site als nicht erreichbar gelten.

An dieser Site ist einiges nicht in Ordnung. Ich frage mich, wie man das sinnvoll in objektive Kriterien übersetzen kann.

• Die Site enthält praktisch keine Inhalte. Der einzige Inhalt der Seite ist ein Bild. Darüber hinaus führen Links auf eine andere Domain. Siehe dazu auch #50.

• Frames: Die Site nutzt die frameset und frame Tags. Das ist sowohl für Menschen mit Beeinträchtigungen als auch für Nutzer*innen mobiler Endgeräte ein erhebliches Hindernis. Auch für Suchmaschinen ist das nicht optimal.

Obwohl https://www.xn--grne-teltow-uhb.de/ und https://xn--grne-milk-r9a.de/ gültige Zertifikate haben, werden die Hostnamen nicht als passend erkannt. Bei Spidern erscheinen diese Fehler:

WARNING:root:Error when getting certificate for https://www.xn--grne-teltow-uhb.de/: CertificateError("hostname 'www.grüne-teltow.de' doesn't match either of 'www.xn--grne-teltow-uhb.de', 'xn--grne-teltow-uhb.de'",)

WARNING:root:Error when getting certificate for https://xn--grne-milk-r9a.de/: CertificateError("hostname 'grüne-milk.de' doesn't match either of 'www.xn--grne-milk-r9a.de', 'xn--grne-milk-r9a.de'",)

WARNING:root:Error when getting certificate for https://www.xn--grne-mnster-uhbe.de/: CertificateError("hostname 'www.grüne-münster.de' doesn't match either of 'www.xn--grne-mnster-uhbe.de', 'xn--grne-mnster-uhbe.de'",)

WARNING:root:Error when getting certificate for https://www.xn--grne-teltow-uhb.de/: CertificateError("hostname 'www.grüne-teltow.de' doesn't match either of 'www.xn--grne-teltow-uhb.de', 'xn--grne-teltow-uhb.de'",)

WARNING:root:Error when getting certificate for https://xn--grne-milk-r9a.de/: CertificateError("hostname 'grüne-milk.de' doesn't match either of 'www.xn--grne-milk-r9a.de', 'xn--grne-milk-r9a.de'",)

Im Report sollte jeder Eintrag (= Site) eine Punktzahl bekommen, nach der die Einträge sortiert werden können. So ergibt sich ein Ranking, in dem jeder Eintrag eingeordnet werden kann.

Die Punktzahl sollte sich aus den Qualitätskriterien, die wir überprüfen, ergeben. Die höchste Punktzahl sollte die Site bekommen, welche die Qualitätskriterien am besten erfüllt.

Verschiedene Kriterien können unterschiedlich gewichtet werden. Einige Kriterien werden binär funktionieren (Ja/Nein), andere werden eher als Skalenwert funktionieren (z. B. Ladezeit X Sekunden).

Die Logik für die Ermittlung der Punktzahl sollte soweit wie möglich außerhalb der Webapp liegen.

In der Auswertung lässt sich dieser Wert dann nutzen, um beispielsweise Aussagen zu treffen wie:

• Die Site schneidet besser ab als 70% aller Grünen-Websites
• Die Site schneidet besser ab als 80% aller KV-Websites
• Unter den besten 10% aller Sites erfüllen X,X % das Kriterium Y

Ziele

Die Webapp soll deutlich benutzer*innenfreundlicher werden! Einige Dinge, die ich gerne erreichen möchte:

• Die Anwendung soll sich schnell laden.
• Jeder soll seine Site schnell und einfach finden und wiederfinden können.
• Die Anwendung soll auch auf dem Smartphone bedienbar sein.
• Prüfkriterien und Empfehlungen für Verbesserungen sollen verständlich und nachvollziehbar sein.

Entwurf

Hier gibt es einen Prototypen:

https://xd.adobe.com/view/a929adc4-e8b2-4c29-54f0-479fd9cf699b-df18/

Und hier noch mal zur Ansicht:

TODO

Die Umsetzung soll in überschaubaren Schritten erfolgen. Hier eine mögliche Reihenfolge:

• Umsetzung einer Navigationsstruktur von Liste (etwa wie 2 Suchergebnis, noch ohne Suche) zur Detailseite (3 Website Detailseite) - Siehe netzbegruenung/green-spider-webapp#11
• Suchfunktion und Startseiten-Inhalte - Siehe netzbegruenung/green-spider-webapp#13
• Umbau des Datenexports:
  • Export einer JSON-Datei für die Liste (Startseite) bzw. Suche.
  • Export einer JSON-Datei für jede Site mit allen Details.
• Favoriten-Funktion mit Auflistung von Favoriten auf der Startseite
• Erstellung der Textinhalte zu den Kriterien (siehe 4 Empfehlung Detailseite) - siehe #86
• Verlinkung von 3 Website Detailseite zu 4 Empfehlung Detailseite

In der Production Webapp führt der Klick auf eine Screenshot-URL dazu, dass nicht der Screenshot geladen wird, sondern die Webapp ohne Seiteninhalt.

Beispiel: https://green-spider.netzbegruenung.de/screenshots/360x640/a7ca7d2dc22768ecfc5086121a2632fc.png

Deaktiviert man den Service Worker über die Chrome developer tools, tritt das Problem nicht auf.

Mit https://github.com/netzbegruenung/green-directory/issues/108 wird das Daten-Schema auf Gliederungen von Jugenorganisationen (Grüne Jugend) erweitert. Das sollte sich auch im Interface darstellen lassen.

Die Spalte "Typ" sollte dazu umbenannt werden in "Ebene". Eine weitere Spalte müsste hinzu kommen, die dann den Typ oder die Kategorie angibt, beispielsweise sowas Partei-Gliederung oder Jugend-Gliederung.

Vorschläge zur Benamung sind willkommen!

Der Spider sollte in einem Docker-Container laufen, um Probleme mit verschiedenen Dependency-Versionen und Plattformen gar nicht erst aufkommen zu lassen.

Das wird besonders dann notwendig, wenn mit Selenium und einem headless Browser (z. B. Chrome, Firefox) getestet wird. Oder falls wir lighthouse (siehe #11) ausführen wollen.

Für Websites gilt in Deutschland ganz grundsätzlich in aller Regel eine Pflicht der Anbieterkennzeichnung. Dabei hat sich die Konvention heraus gebildet, einen Link mit der Bezeichnung "Impressum" auf allen Seiten anzubieten, der zu der entsprechenden Information führt.

Wir sollten prüfen, ob ein entsprechender Link auf der Site vorgefunden wird.

Von Sites mit Umlaut-Domains fehlen die Screenshots grundsätzlich.

Beispiele:

https://green-spider.netzbegruenung.de/sites/https%3A%2F%2Fxn--grne-porta-westfalica-9hc.de%2F

https://green-spider.netzbegruenung.de/sites/https%3A%2F%2Fwww.xn--grne-teltow-uhb.de%2F

Die folgenden URLs werden in der webapp nicht decodiert:

• http://xn--grne-milk-r9a.de/ - sollte als http://grüne-milk.de/ angezeigt werden
• http://xn--grne-much-r9a.de/ - sollte als http://grüne-much.de/ angezeigt werden