Unterschied CMS

Wer bisher ein CMS verwendet hat, soll wissen, dass es Unterschiede zwischen den CMS und zum Werkzeug ZIM gibt.

Ich muss das so konkret auf ZIM münzen, denn wer einen Statik Website Generator wie z.B. Hugo einsetzt, dort heben sich die Unterschiede im Ergebnis teilweise auf.
Theoretisch hätte man als Autor dann eine Software für seine Notizen und den Generator, in dem man in Markdown schreibt.

Hier hat man sein Notizbuch, in dem man ganz normal schreibt und das sich seinen Server (als Generator) gleich mit bringt.

In meinem Sandkasten hier habe ich ZIM auf Herz und Nieren prüfen können, ehe ich meine Projekte umsetze. Und ich werde sie damit umsetzen, da ich nichts gefunden habe, das mir abgeht. Daher bin ich sozusagen voreingenommen.

Aber ich möchte wenigstens versuchen, die Dinge anzusprechen, die sich zum CMS unterscheiden.

Thumbnail und Anrisstext

Hauptpunkt ist sicher, dass es in ZIM keine separaten Felder für Thumbnail und Anrisstext gibt.
Damit lassen sich also nicht die Übersichtsseiten automatisch generieren, wie man sie vom CMS kennt nach Aktualität oder Keyword.
Es gibt Statik Website Generatoren, die unterschiedliche Seiten generieren. Eine für Artikel, eine für Übersichtsseiten.

Lösung in ZIM

Man kann sich Übersichtseiten selbst manuell erstellen. Dahinter steht ein anderer Ansatz des Schreibens.

Die Hauptseite beispielsweise zum Hobby "Hörspiele und Lesungen sammeln" ist nichts anderes als das, was wir heute unter einer Übersichtsseite verstehen: Eine Einführung ins Thema mit der Möglichkeit, zur Vertiefung.
Natürlich kann man das Ganze noch mit mehr Bildern aufpeppen, wenn man drauf steht.

Bei den zusätzlichen Übersichtsseiten zu Keywords (Hashtags) steckt dahinter, dass man dem User anbieten möchte, zu einem Keyword Inhalte zu finden.
In Zim führt man einfach seine Stichwortliste.
Nicht abgelenkt von Bildern und möglicherweise reißerischen Aufmachern, ist ein User dank der Liste nicht lange am Suchen, sondern schnell am Finden.

Meta-Angaben

Wenn man Anrisstext und Thumbnail nicht "greifen" kann, so ohne Extrafelder, kann Zim natürlich auch keine Meta-Angaben in die zu exportierende Datei zaubern.
Wann braucht man diese wirklich? Suchmaschinen bedienen sich doch längst aus dem, was nach dem Element <body> kommt.

Share-Postings

Man braucht diese Meta-Angaben, um den neuen Artikel in den SN augenfällig zu teilen?

Auf Diaspora*, Hubzilla, usw. gibt es die Möglichkeit, Bilder hoch zu laden.
- entweder ein vorhandenes Thumbnail aus dem Artikel
- oder einen Screenshot seiner fertigen Artikel-Seite (siehe Anleitungsvideo Bildschirmfoto zuschneiden).

Damit sieht das Posting nicht aus, wie von der Kleiderstange und erweckt mehr Aufmerksamkeit.

Kein Feed

Irgendjemand hat mal geschrieben, dass er viele Artikel im FeedReader liest, weil sie dort lesbarer seien.
Hier ist keine Werbung eingebunden und wer lieber einspaltig liest, kann sich ja den Browser zusammen schieben.

Warum nutze ich einen FeedReader? Weil ich nicht in kommerziellen Sozialen Netzwerken bin und folglich nicht mitbekomme, wo und welche neuen Artikel erschienen sind.

Selbst poste ich auf Diaspora* und Hubzilla.
Anstatt die Adresse in seinen FeedReader einzutragen, kann man sich dort z.B. per Abo auf dem Laufenden halten.


Keine Kommentarfunktion

Das stimmt.
Man kann natürlich im Theme auch den Code einfügen, um beispielsweise Disqus zu integrieren. So was wäre also ruckzuck erledigt. Disqus ist wegen Hackerangriffen in die Schlagzeilen geraten.
Auf Disqus haben Kommentatoren ihre zentrale Plattform zum Managen der eigenen Kommentare, die sie auf verschiedenen Webseiten abgegeben haben. Kommentare sind nicht unsichtbar, wenn Moderator sie nicht für veröffentlichungswürdig hält.
Der Ansatz ist sicher gut und ich finde ihn demokratischer. Selbst würde ich das nicht einbauen, wenn der Anbieter kommerziell ist und wenn er nicht in der EU sitzt.
Dazu interessant vielleicht noch der Text von Sven.

Oder man entscheidet sich z.B. für isso als Alternative, falls der eigene Webserver Python kann.
Da ich den Anspruch habe, ohne Scripte etc. Webseiten zu betreiben, kommt das allerdings nicht in Betracht.

Bei meinem einen Projekt posteten User, wenn sie meine Hilfe wollten. Nervt, weil alle Info säuberlich bereit liegt.
Das andere Projekt - ja, da posteten nette Kollegen. Da bedaure ich es fast ein wenig.
Aber es gibt wegen der Kommentarmöglichkeit zu viel Spamfilterei auf beide Projekten zu organisieren.

Der Schockwellenreiter lässt sich Kommentare als Mail zuschicken und pflegt sie händisch ein.

Selbst habe ich für Kritik, Anregungen und Diskussionen rund um diesen Webauftritt einen Kanal bei Hubzilla eingerichtet.
Es kann also immer mal sein, dass ich ein Thema von dort hier für einen Artikel aufgreife und - nach Rücksprache - auch zum betreffenden Kollegen verlinke, der das Thema angeschnitten oder ein Problem gelöst hat.
Ähnlich zufrieden - so ohne Kommentarfunktion - äußert sich Thomas Leister, nach den ersten drei Monaten im Nachtrag, der seine statischen Webseiten mit Hugo erstellt.

Ist schon eine erstaunliche Entwicklung

  • Erst gab es statische Webseiten,
  • Dann musste alles dynamisch sein.
  • Dann kamen die Sozialen Netzwerke.
  • Und nun bauen manche ihre Präsenzen wieder zurück auf Anfang.

Testweise Maillink für Kommentar

Ich würde sie dann als Anhang einpflegen.
Einerseits möchte ich nicht den Eindruck erwecken, als sei ich nicht an Kommentaren interessiert.
Andererseits möchte ich auch nicht dazu drängen.
Testweise gibt es aktuell also einen eMail-Link zum Senden für Kommentare.

Keine Sitemap.xml

Stimm auch.

Wer in seine Statistik schaut, wird zugeben, dass sich die vielen Spider aus ganz wunderbar zurecht finden und keine gesonderte maschinenlesbare Datei brauchen.

Wir haben ein Inhaltsverzeichnis und damit ist dem Menschen gedient.

Auch laut Selfhtml (letzter Satz) ist eine Sitemap allenfalls bei sehr großen Projekten sinnvoll.



Möglicherweise kommen noch Aspekte hinzu. Aber im Moment wüsste ich keine.

Umgewöhnen ist allerdings kein echter Aspekt.
Auch an eine neue Version eines CMS muss man sich gewöhnen.
Erst recht, ist der Aufwand fürs Umgewöhnen deutlich, beim Umstieg auf ein anderes CMS.

Manche Abläufe werden anfangs länger dauern, aber sehr schnell entwickelt sich Routine.
Hinzu kommt die Freude über die Einfachheit.

Die Seiten sind für User schnell geladen.

Man hat sein Backup bereits, da das in HTML exportierte Notizbuch die Grundlage ist, was per FTP hochgeladen wird.

Die Seite ist weniger Angriffen ausgesetzt ohne Datenbank.

Man muss sich nicht mit Arbeiten befassen, die mit dem CMS zu tun haben (Module finden, updaten etc.)

Es ist eher ein Umdenken - ein Infrage stellen, wovon man jahrelang in überzeugt war.

Für manchen mag direkter Umgang mit Code und Skripten ungewohnt ist.
Solche Anforderungen (z.B. Bilder) sind eher unter Sonderfälle zu verbuchen und sie wurden beim netzrose-theme mit Mustern und Anleitung erleichtert.

Für mich ist es eher ein Zurückgewinnen meiner Gestaltungsfreiheit.
Ein CMS "aufzubohren", ist riskanter.
Bei ZIM hat man nachvollziehbare Gelegenheit, auch mal den vorbereiteten Rahmen zu verlassen und kann beispielsweise mittels Anhang weiteren Code in eine Seite integrieren oder man könnte zentral sein Theme entsprechend umbauen, falls er auf allen Seiten erfolgen soll.


Interaktion
Kanal für Diskussionen auf Hubzilla.
Oder: Kommentar per Mail senden. -> Datenschutz.

Hier her intern verlinkt von:

| A Home | Stichworte | Management:Erfolg Geld | Publizieren:Generator ZIM:netzrose-theme | Hardware:Monitor:netzrose-theme |