Challenge to rebuild site in CMSimple_XH

[svasti]

Just for fun....

Hi webdesigners,

A friend of mine wants what she calls a very simple website. It should look like this one: http://www.wendybaudin.com/
and have the same functionality, as she want to offer the same service.

Do you think one can do it? How would you do it?


Hallo Leute,
eine Freundin möchte ein "einfache" Website so wie diese weil sie mit denselben Diensten Geld verdienen will . Wie würdet ihr so eine Seite bauen, welche Plugins?

svasti

[cmb]

Hi svasti,

I guess you're referring to the fact, that the site doesn't seem to reload on navigation. That is explained in the source code:

<!--
IMPORTANT! LOOKING FOR THIS SITE’S SEO CONTENT?

This site's SEO content, such as meta tags and headers, is not here.
This is because search engines, like Google, actually crawl the site's homepage via http://www.wendybaudin.com/?_escaped_fragment_=.

Internal pages, like “Media”, also have their own special search engine versions, for example: http://www.wendybaudin.com/?_escaped_fr ... ia%2Fc1hm9
If you’re looking for this site’s SEO content, that’s where you can view it.

Want more information about Ajax page crawling? Read Google's explanation here: http://bit.ly/ajaxcrawling
-->

So one can access a single page with http://www.wendybaudin.com/?_escaped_fr ... ndy%2Fcjsa for instance.

To do this with CMSimple seems possible, but may require modifications to the core. I'm not sure, if it's possible as purely plugin based solution. However, there is no plugin (yet) to help with it.

Basically I have some doubts regarding this technique, as one cannot access the site at all, if JavaScript is disabled. This may exclude visually impaired, and bots which are not aware of Google's ajax-crawling (seems quite proprietary).

Anyway, it seems to me that it is not necessary to implement Google's ajax-crawling technique in the first place to have a similar result, as CMSimple is no AJAX application. The idea:

• The site is set up as usual with CMSimple
• The template contains a SCRIPT, that rewrites the URLs in the menu (and submenu) moving the name of the page from the query part to the fragment part (?Welcome becomes #Welcome) and adds an onclick listener.
  • If JS is disabled nothing happens, and clicking a menu item reloads the desired page as usual.
  • If JS is enabled, clicking a menu item triggers the onclick handler, which makes an AJAX request which gets the content() and replaces the exisiting content. Furthermore it has to modify the menu (simple for a single level menu; only .sdoc and .doc would have been to changed). The onclick handler returns true, so the new fragment will show up in the address line (to be able to get a deep link).
• To be able to handle deep links, another SCRIPT in the templates checks for a fragment part of the URL. If that's found the content area, is reloaded via AJAX.

I'm quite sure that I have overlook some details, but basically that might work, and would not be too hard to implement. sitemap, mailform, and print view will not work this way without further modifications, but they may not be necessary at all. And of course plugins creating some kind of internal navigation (such as Forum_XH, Galleries and RealBlog) will not work without further modifications.

Christoph

[svasti]

Wow, that's tricky.
I used to think that everything could be done with CMSImple_XH, but this would be quite challenging.

So I think I'll rather go for standard simple CMSimple_XH technique + Teaser_XH + Coco_XH + Wellrad + RealBlog_XH + Socialshareprivacy_XH + Memberpages_XH + 2 special fonts (hm easiest seems to be linking to Google-Fonts) + a plugin to collect e-mail adresses.

Now, which plugin could be used to collect e-mail adresses? (People who register would get the benefit of getting access to a page with special wisdom ) May be better to use Register_XH instead of Memberpages?

Wellrad has Paypal integrated as far as I know, credit card handling seems to be a little more complicated.
This was something similar to that site seem to be managable.

svasti

[Torsten.Behrens]

Jetzt mal ganz praktisch: Die angeführte Beispielseite lädt unendlich lange und ist bei mir im Browser (OS X - Safari 5.1.9) überhaupt nicht zu scrollen.
Ein fast abgeschnittenes Wassertropfen Logo, welches nicht mal freigestellt wurde. Dann noch Großbuchstaben in Schreibschrift.
Und eine Verlinkung im Footer auf wix.com - auch wenn das Design von http://www.momentum33.com/ kommen soll. Die sind aber auch programmtechnisch ( http://momentum33.com/Life_Coach.html - mit alten Terminen! ) mit der Beispielseite verknüpft.
Zusätzlich die 'Brüche' durch die Auslagerung von Inhalten auf externe Seiten: Eine solche Beispielseite sollte man sich -meiner Meinung nach- nicht als Beispiel nehmen.
Die Seite für die Freundin muss also «BESSER» als die Beispielseite sein - lieber weniger Technik und dafür mehr zusammenpassende und designtechnisch aufeinander abgestimmte Inhalte. Erst ein Konzept erarbeiten und dann an die technische Umsetzung gehen.

Torsten

[cmb]

I used to think that everything could be done with CMSImple_XH

IMO a lot can be done with CMSimple_XH, but of course there are restrictions; for instance flying to the moon with it might not be possible.

So I think I'll rather go for standard simple CMSimple_XH technique + Teaser_XH + Coco_XH + Wellrad + RealBlog_XH + Socialshareprivacy_XH + Memberpages_XH + 2 special fonts (hm easiest seems to be linking to Google-Fonts) + a plugin to collect e-mail adresses.

That seems to be a reasonable approach.

Now, which plugin could be used to collect e-mail adresses? (People who register would get the benefit of getting access to a page with special wisdom ) May be better to use Register_XH instead of Memberpages?

If the regristration should be automated, using Register_XH is the simplest solution (after all that was the reason it was made; originally it was just an AddOn for Memberpages). As an alternative you may consider to allow for a manual registration process (the user has to ask for member access via email first).

Die Seite für die Freundin muss also «BESSER» als die Beispielseite sein - lieber weniger Technik und dafür mehr zusammenpassende und designtechnisch aufeinander abgestimmte Inhalte. Erst ein Konzept erarbeiten und dann an die technische Umsetzung gehen.

Da hast Du, finde ich, nicht unrecht. Das wichtigste bei einer Website sind die Inhalte und deren Darstellung. Wie das ganze technisch umgesetzt ist, interessiert den Besucher i.d.R. nicht.

Jetzt mal ganz praktisch: Die angeführte Beispielseite lädt unendlich lange und ist bei mir im Browser (OS X - Safari 5.1.9) überhaupt nicht zu scrollen.

"Unendlich lange" finde ich etwas unpräzise. Bir mir dauert es etwa 10 Sekunden bis ich die erste visuelle Reaktion im Browserfenster sehe, dann 2-3 Sekunden bis das Menü erscheint und etwa noch mal so lange bis der Content da ist. Im Hintergrund wird dann für nahezu weitere 3 Minuten weiter geladen. Insgesamt werden 152 Request gesendet.

Eine solche Beispielseite sollte man sich -meiner Meinung nach- nicht als Beispiel nehmen.

Ich würde sagen: jein. Das "ewige" Warten auf die Website ist sicher nicht schön; die Navigation ohne Page Reload hat aber schon was, finde ich. Ich habe daher mal ein bisschen experimentiert, und das Laden des Content einer CMSimple Site per AJAX realisiert -- in meiner lokalen Testinstallation läuft das erstaunlich flott und rund. Ich werde wohl "morgen" mal eine Demo bereit stellen. Für Bastler, die eine solche Technik nutzen wollen, und mit den Einschränkungen (bin noch nicht sicher, welche das letztlich sind) leben können, dann vielleicht eine Interessante Variante.

[snafu]

Die Seite für die Freundin muss also «BESSER» als die Beispielseite sein - lieber weniger Technik und dafür mehr zusammenpassende und designtechnisch aufeinander abgestimmte Inhalte. Erst ein Konzept erarbeiten und dann an die technische Umsetzung gehen.

Da hast Du, finde ich, nicht unrecht. Das wichtigste bei einer Website sind die Inhalte und deren Darstellung. Wie das ganze technisch umgesetzt ist, interessiert den Besucher i.d.R. nicht.

wie wahr, wie wahr ;-}

"Unendlich lange" finde ich etwas unpräzise. Bir mir dauert es etwa 10 Sekunden bis ich die erste visuelle Reaktion im Browserfenster sehe, dann 2-3 Sekunden bis das Menü erscheint und etwa noch mal so lange bis der Content da ist. Im Hintergrund wird dann für nahezu weitere 3 Minuten weiter geladen. Insgesamt werden 152 Request gesendet.

sorry, es gab und gibt genug "usability" Unteersuchungen im Web, wie lange die Masse der Besucher bereit ist auf eine Seite zu warten. Alles über 10 Sekunden wird da als INDISKUTABEL bezeichnet, wobei da von Seiten ausgegangen wird, wo man trotzdem nach 1-2 Sekunden sieht, das was passiert. 10 Sekunden whitescreen incl. blockierendem Browser geht gar nicht. Die Masse der Besucher schliesst ein "leeres Browserfenster nach wenigen Sekunden (ne Sanduhr wäre das mindeste). Deine technische Begeisterung über die Seite, nachdem alles geladen ist, wird ein Besucher kaum teilen ... soweit kommt er gar nicht.
Mal abgesehen davon, daß ein halbwegs sicherheitsbewusster Surfer (noscript) sowieso nichts sieht ... und noscript benutzt man ja nicht deswegen um es bei jeder fremden Seite gleich wieder auszuschalten um eventuell den Inhalt sehen zu können ... und sich irgendeine Trojanerseuche zu holen ;-}
Wobei, selbst bei deaktiviertem noscript ich die Seite in meinem Firefox nicht sehen kann, scheiter dann wohl an einem der anderen Blocker bei mir, kein gutes Zeichen

Ich würde sagen: jein. Das "ewige" Warten auf die Website ist sicher nicht schön;

sorry, man WARTET heutzutage nicht mehr lange. Da wo es um die Vermittlung von Inhalten geht (blogosphäre ;-}) schaut man sehr genau drauf und eine Wartezeit von 5 Sekunden wird da schon als "gefährlich" langsam angesehen .. und da sieht man immerhin schon ab der ersten Sekunde (auch mit aktivem noscript), dass sich was tut.

Auf Design, BG Bild, Farben geh ich bei einer Seite mit derartigen Einschränkungen gar nicht erst ein ... bei den teuren Produkten hätten sie sich halt auch einen entsprechenden Designer leisten sollen.

[cmb]

sorry, es gab und gibt genug "usability" Unteersuchungen im Web, wie lange die Masse der Besucher bereit ist auf eine Seite zu warten. Alles über 10 Sekunden wird da als INDISKUTABEL bezeichnet, wobei da von Seiten ausgegangen wird, wo man trotzdem nach 1-2 Sekunden sieht, das was passiert. 10 Sekunden whitescreen incl. blockierendem Browser geht gar nicht. Die Masse der Besucher schliesst ein "leeres Browserfenster nach wenigen Sekunden (ne Sanduhr wäre das mindeste). Deine technische Begeisterung über die Seite, nachdem alles geladen ist, wird ein Besucher kaum teilen ... soweit kommt er gar nicht.

Ich gebe Dir natürlich recht, dass lange Wartezeiten (besonders ohne schnelle erste Rückmeldung) nicht förderlich für die Besucherzahlen einer Site sind. Bei der grundlegenden Technik (nämlich nur den Content per AJAX zu laden) geht es aber eigentlich genau darum, die Seiten schneller darzustellen. Die Idee ist, dass bei dieser Technik nur 1 einziger Request an Server gemacht wird (plus ggf. weitere für Bilder, Scripte usw. im Content); beim "normalen" Page-Reload werden allerdings auch das/die Stylesheets, allgemeine Scripte, Headerbilder usw. erneut requested (auch wenn diese im Browser-Cache sind, muss nachgefragt werden, ob sie noch aktuell sind).

Ich bin übrigens auf einen interessanten Artikel zu diesem Thema gestoßen: http://blog.benward.me/post/3231388630. Dieser hat mich nachdenklich gestimmt. Auch wenn ich eine etwas andere Implemetierung im Sinn hatte als die HashBang-Variante, damit die Site auch ohne JavaScript genutzt werden kann (nicht nur von entsprechenden Suchmaschinen), gibt es zumindest Probleme bzgl. Deep-Links: werden diese in der Hash-Version verlinkt, dann landet ein Besucher ohne JS immer auf der Startseite; ein Besucher mit JS müsste aber durch den Browser erst relokiert werden, was den Performance-Vorteil umkehrt. Werden sie in der "klassischen" Form verlinkt, dann wird auch bei aktivem JS bei der ersten Navigation ein Reload nötig. Und spätestens wenn dann noch weiche Überblendungen des Content gewünscht sind, dann ist das Browsing-Erlebnis nicht so schön.

Ich finde die grundsätzliche Technik nach wie vor interessant, aber in Anbetracht der genannten (und vermutlich weiterer) Probleme, und weil ich finde, dass es dringlicheres gibt, werde ich mich erst mal nicht weiter mit diesem Thema befassen. Meinen Entwurf habe ich mal als Demo zur Verfügung gestellt[1]. Im Zweifel einfach mit und ohne JS vergleichen.

Christoph

PS: [1] Die Demo ist nicht mehr verfügbar.