freifunkfranken / landingpage-freifunkfranken Goto Github PK

Das Impressum sollte nicht auf eine Privatperson verweisen. Evtl. ist es möglich den "Freie Netze e.V." hier einzutragen?

Ich bin kein Experte in Typografie, finde nur die Mischung aus Schrift mit und ohne Serifen unschön.
Die Hauptüberschrift ist mit, die untergeordneten Headlines ohne. Der Text wieder mit - außer im aside, wo wieder alles ohne Serifen ist.

Als Hauptschriftart wird font-family: "ff-tisa-web-pro-1","ff-tisa-web-pro-2", georgia, serif; angegeben. Ich nehme aber an, dass FF Tisa bei den wenigsten Nutzern installiert sein dürfte. Ebenso wie proxima nova als serifen lose Schrift.

Webfonts irgendwoher einbinden sollten wir meiner Ansicht nach sein lassen, da die Seite einen möglichst schlanken Footprint haben sollte.

Vorschlag: Analog zu den Freifunk-Seiten nur Serifenlos.
Fallbacks weg. einfach nur font-family: sans-serif; denn: http://css-tricks.com/sans-serif/

nft

https://help.github.com/categories/20/articles

Es gibt auf mobilen Geräten einige Apps die Ihre Daten über HTTP senden/empfangen. Falls dies unverschlüsselt auf Port 80 geschieht kommen die Daten nicht durch, bis der Benutzer den Browser geöffnet hat und den Access-Button betätigt hat.
Die Landingpage-Sperre sollte nur bei Browser-Anfragen kommen.

Ich finde es ist unklar was nach dem klicken des Bestätigungsbuttons passiert.

Vllt sollte man da nicht nur schreiben "Sei einfach frei...."

Sondern auch explizit: Du kannst jetzt los surfen.

Der Benutzer wird durch die Landingpage beim Surfen unterbrochen. Wenn der Benutzer auf "Weitersurfen" klickt soll er automatisch zu der vorher gewünschten Seite weitergeleitet werden.

Eigentlich sollte das bereits funktionieren (siehe #24) aber es gibt im Realbetrieb noch Probleme.

Support for Smartphones and Tablets

Mir ist nicht ganz klar wofür die 2. Seite gedacht ist.
Hier wird ja aktuell der Nutzer "im Internet begrüßt" (überspitzt)

Die landingpage erfüllt ja den Zweck, den Nutzer zu informieren, dass er sich im Freifunk-Netz befindet. Die sollte Infos anbieten was das bedeutet, Links zu detaillierten Texten.
Der Link "Weitersurfen" sollte den Nutzer eher auf die von ihm aufgerufene Seite weiter leiten.
Da noch was nachzulagern und mitzuteilen: Jetzt darfst du los legen - finde ich unnötig.

Vielmehr sollten wir planen

1. was unbedingt auf die Startseite soll
2. Welche Informationen direkt erreichbar sein sollten, also hier verlinkt werden müssen/sollten.

Den Image-Film auf Seite 2 sollten wir IMHO verlinken. Der bringt einem regelmäßigen Nutzer keinen Mehrwert.

zu 1. :

• was ist FF?
• Sicherheitshinweis

zu 2. :

• Link zu FreifunkFranken - Startseite
• ggf Link zu Rechtlichen Hinweisen
• Link zu Detaillierten Sicherheitshinweisen (TOR, https, sicherer mailversand, Homebanking via FF? ....

All diese Zusatzinfos sollten meiner Ansicht nach auf die FreifunkFranken Seite, da sie auch für alle Nutzer dort relevant sind.

Es soll die (GPS) Position des Benutzers ermittelt werden. Entprechend der Position sollen dann zuätzliche Informationen über offizielle benachbarte Knoten und ggf. deren Sponsoren angezeigt werden.

Es wäre evtl. ganz nett die Seite durch eine Mesh-Animation aufzupeppen.

Ich finde es unschön und unseriös wenn in der URL mojoaxel usw angezeigt wird.

Können wir das unter der Domain Freifunk-Franken hosten? Evtl n Job einrichten der immer den aktuellen Source aus dem Git holt?

Grüße
Johannes

Der Benutzer (nennen wir ihn einfachkeitshalber "Tim") möchte gerne ein Häckchen setzen können "Nie wieder anzeigen" durch das das Einblenden der Landingpage für diesen Client deaktiviert wird. Wie könnten wir das realisieren?

Das Logo könnte als SVG-Grafik zusammen mit einem PNG-Fallback eingebunden werden.

Als Vorschlag um möglichst viel https Traffic zu erreichen.

" Dies erreichst Du unter anderem indem Du https verwendest! Als einfache Hilfe kannst du Dir dieses [Link/Plugin] installieren um möglichst oft verschlüsselt zu surfen."

It's just enough to see this page once.

Wäre toll, wenn wir User-Daten z.B. Piwik hätten. Frage ist nur ob wir das aus Datenschutzgründen wirklich alles sammeln wollen?

in der script.js wird ein Fehler geworfen, "Uncaught TypeError: Cannot call method 'split' of undefined "

Auslöser ist das verarbeiten eines nicht vorhandenen hash aus der URL.
Ich kann das beheben, weiß aber nicht genau was das Ziel da ist.

Wo sollen die Parameter Access und req her kommen?

Ich vermute, dass da irgendwie die ursprüngliche URL durchgereicht werden soll. ist das korrekt?

Der Code in createAccessButton enthält ein log und kann auch noch optimiert werden. - würde ich auch übernehmen.

In jedem Fall verhindert der JS Fehler auch die Ausführung der restlichen Scripte.

Servus,

nur mal als abstrakte Idee: Vielleicht sollte man die Landingpage dreigeteilt machen. Sprich zum einen einen Platz für den Knotenbetreiber, zum anderen Platz für Freifunk, und zum dritten Platz für den der den Gateway bezahlt/betreibt.

Ist aber nur eine Idee, de facto könnte man ja für jeden Gateway die Seite entsprechend modifizieren.

Die Seite sollte mehrsprachig werde. Je nach dem wie der Browser des Benutzers eingestellt ist soll die entsprechende Sprache angezeigt werden.

The Page should be completly http transparent if the request doesn't come from a normal user.

Es wurde kritisiert, dass die Seite zu viel Text enhällt, den sowiso keiner liest.
Die einzelnen Textblöcke sollten beim Laden "eingeklappt" sein und erst auf Wunsch des Benutzers "herausfahren".

Feedly bekommt die Landingpage verabreicht und präsentiert dann einen Fehler

Ich würde vorschlagen, wir legen eine WikiSeite an, auf der wir solche Fehlerfälle sammeln.
App, System, User-Agent etc