Static content in your Rails application
Our heros over at thoughtbot.com blogged about static pages and their newly released Rails engine high_voltage. High Voltage helps you dealing with simple, stupid static content pages that nobody wants but everyone needs. ;) (With static pages I’m thinking of imprint, about us, etc.)
In our projects we had a similar solution but to edit the pages more easily and without the need to deploy the whole application we’re saving the content in the database.
Because the database part was missing in high_voltage but I’ve really liked the idea to extract that feature into a rails engine I’ve created a fork last night.
My fork checks if there is a valid template file in views/pages/ - if not it checks the Database and renders the views/pages/show template.
How to use it?
Installation
script/plugin install git://github.com/bumi/high_voltage.git
Create pages
this is up to you. ;)
You can add static files to your app/views/pages/ directory or create a database entry:
HighVoltage::Page.create(:title => "Hello world", :body => "High Voltage! High Voltage!")
That’s it!
For more information check the original thoughtbot post” - You should follow their blog anyway! - And have a look at the readme.
Hope you like my addons.
What are your solutions for static pages?
Stift, Zettel und “Tego”
Gestern und heute war ich damit beschäftigt für unsere aktuelle #yai7d “Tego” Interface-Skizzen anzufertigen - natürlich, so wie wir es oft machen, mit Bleistift und einem Stapel DIN A3-Blättern: Paper-based Prototypen sind schnell angefertigt, man kann sie wunderbar in die Hand nehmen und rumreichen, mit Schere und etwas Geschick sogar animieren und sie dann stakeholdern vorlegen, um jene bei der Interaktion zu beobachten; denn durch ihre grafische Abstraktion legen sie den Fokus in dieser frühen Phase der Entwicklung einzig auf die Interaktion. Naja, und schließlich kann man sie (wichtig!) einfach wegwerfen. Ich mag paper-based Prototypen.
Doch gestern und heute war ich mit den Zeichnungen nicht so zufrieden. Unsere neue Anwendung wird sehr textlastig, Text ist überhaupt der einzige UGC und daher gilt es Texte unterschiedlicher Länge in benutzbarer Form darzubieten und erstellen zu lassen. Natürlich hatte ich wenig Lust ein Blatt Papier mit Blindtext vollzuschreiben und selbst, wenn ich es getan hätte, wäre das Ergebnis natürlich nicht mit dem tatsächlichen Textsatz des Browsers vergleichbar gewesen. Wenn nun jedoch die Anwendung zu großen Teilen aus kurzen und längeren Texten besteht, hat die konkrete Darstellung jener sicherlich auch einen Einfluss auf die Interaktion - und an dem Punkt stockte mein Bleistift- und Zettel-Ansatz.
Ich hätte es wie Shawn Medero machen können, der gedruckte Textblöcke mit seinen Interface-Skizzen kombiniert und somit die Flexibilität des Papiers mit aussagekräftigeren Darstellungen aus dem Drucker, bin dann aber schließlich doch komplett zu OmniGraffle gewechselt. Die hiermit erzeugten Prototypen würde ich als “almost paper-based”¹ bezeichnen, sie sind ähnlich schnell zusammengeklickt wie gezeichnet und gegenüber der Papierversion haben sie den sehr praktischen Vorteil, dass man sie zur Validierung einfach per E-Mail verschicken kann ;-) … doch eines darf man danach auch hier nicht vergessen: ⌘ + ⌫
¹ Man kann sie allerdings nicht mehr so gut in Usability Tests einsetzen und muss sich bewusst bremsen nicht zu viele grafische Details mit einfließen zu lassen.
#yai7d geht in die zweite Runde: “Tego”
Letzten Mittwoch haben wir das Poken/GoogleMaps-Mashup Pokenvision präsentiert, an dem wir für die missionpoken.de-Crew sieben agile Tage lang gearbeitet haben. Das positive Twitter-Echo darauf hat uns sehr gefreut und wir werden die Entwicklung der App sicherlich auch zukünftig unterstützen.
Doch unsere neue Woche soll tatsächlich schon wieder mit einem frischen Projekt beginnen: “Tego” - richtig, um euch ein bisschen rätseln zu lassen, haben wir erneut zu einem Codenamen gegriffen.. ;-) Auch Details gibt’s erstmal keine. Nur soviel: Die Zusammenarbeit wird diesmal ein bisschen internationaler…
Also, seid gespannt auf unsere Berichte: Morgen geht es los - wir bekommen Besuch!
Projekt “Boswell” ist online: Pokenvision - a visual poken map by missionpoken.de & Railslove
Unser erstes #yai7d-Projekt, das wir in der letzten Woche unter dem Codenamen “Boswell” entwickelt haben, ist heute um 13:42 nun offiziell gestartet und damit enthüllt: Pokenvision, ein Google Maps-Mashup für Poken-Fans, wurde im Auftrag und in Zusammenarbeit mit der missionpoken.de-Crew realisiert.
Bei Pokenvision handelt es sich um eine kleine Rails-App, bei der sich Poken-Besitzer samt ihrer Pokens auf einer Weltkarte platzieren können. Die angegebenen Ortsnamen und Postleitzahlen werden dabei geokodiert und schließlich als einzelne Marker abgespeichert; und damit die Browser auch mit der gesamten Poken-Crowd klar kommen, werden mehrere Marker pro Region in höheren Zoom-Stufen on-demand zu einem Cluster zusammengefasst. Feine Sache!
Was bleibt uns also noch zu sagen, als: Happy poking, everyone!
Marker-Cluster für die Google Map
Jeder der schon mal versucht hat viele Marker auf einer Google map anzuzeigen wird schnell ferststellen, dass das kein Spass macht. Zum einen sieht die Karte dann bei einem niedrigen Zoomlevel sehr unübersichtlich aus - man sieht eigentlich die Karte vor Marker nicht mehr- und zum anderen sinkt die Performance des Browsers bei vielen Markern starkt.
Jeder Marker besteht aus vielen einzelnen DOM-Elementen. Und bei mehreren Tausend Marken macht das Verarbeiten und Anzeigen dieser Vielzahl an DOM-Elementen dem Browser schwer zu schaffen.
Um dieses Problem zu lösen gibt es die Möglichkeit die Marker zu einzelnen Clustern zusammenzufügen. Ein guter Einstieg in dieses Thema ist der Blogpost von Gabriel Svennerberg zum Thema Handling Large Amounts of Markers in Google Maps. Hier werden verschiedene Methoden zum Clustern von Markern und vor allem ein Benchmark zur Ladezeit vorgestellt.
In den Kommentaren stösst man aber auf eine Lösung von Xiaoxi Wu im Google Geo Developers Blog. Hier werden die einzelnen DOM-Elemente in einen Cluster zusammengefasst, wenn er in einem vorgegebenem Range liegt. In einem Demo kann man entsprechende Speed-Tests mit diesem Verfahren ausprobieren. Das Laden von ca. 500 Markern dauert ca. 331 ms. was gegenüber dem Benchmark von Gabriel Svennerberg eine akzeptable Ladezeit ist.
Für unser #yai7d-Projekt “Boswell” mussten wir zusätzliche Modifikationen in das Skript einbauen um die einzelnen geclusterten Objekte auszulesen.
Der Post kommt mit einer kleinen Verzögerung durch die entstandenen Feiertage. Unser erstes #yai7d-Projekt ist aber abgeschlossen. Wir werden sehr bald dadrüber Bloggen!
Viel Spass beim Clustering!



