Die Zukunft von Serendipity

[yellowled]

Die Darstellung ist anders.

Markup: Mobile Output (serendipity_event_mobile_output)

This plugin handles mobile devices and outputs optimized XHTML MP markup if it detects a mobile browser and a specially optimized site for iPhone and iPod Touch. It also scales images to fit the display size. For more information see http://c.seo-mobile.de/.

Liegt auf Spartacus. Ein anderer Ansatz wäre es, das über das Template bzw. dessen CSS zu regeln, etwa so, wie ich es aucf http://netzgestaltung.net umgesetzt habe.

Das Problem damit ist: Der Smartphone-Markt ist riesig, d.h. es gibt etliche verschiedene (und sehr kleine) Display-Auflösungen, etliche Mobil-Browser (z.T. auch unterschiedliche auf demselben Smartphone-OS) und vor allem: unterschiedliche Standards. Zudem lese ich z.B. von iPhone-Nutzern, dass sie diese "optimierten" Seiten gar nicht mögen.

So gesehen ist der Weg über ein an bestimmte Auflösungen angepasstes CSS (über sogenannte media queries, die die tatsächliche Displayauflösung abfragen) derzeit der einzig sinnvolle. Der Haken dabei ist aber, dass das nicht "global" umsetzbar ist -- es muss individuell für jedes Template angepasst werden. Eine eierlegende Wollmilchsau in Form eines Plugins sehe ich da im Moment nicht.

YL

[refilix]

Die Darstellung ist anders.

Markup: Mobile Output (serendipity_event_mobile_output)

This plugin handles mobile devices and outputs optimized XHTML MP markup if it detects a mobile browser and a specially optimized site for iPhone and iPod Touch. It also scales images to fit the display size. For more information see http://c.seo-mobile.de/.

Liegt auf Spartacus. Ein anderer Ansatz wäre es, das über das Template bzw. dessen CSS zu regeln, etwa so, wie ich es aucf http://netzgestaltung.net umgesetzt habe.

Das Problem damit ist: Der Smartphone-Markt ist riesig, d.h. es gibt etliche verschiedene (und sehr kleine) Display-Auflösungen, etliche Mobil-Browser (z.T. auch unterschiedliche auf demselben Smartphone-OS) und vor allem: unterschiedliche Standards. Zudem lese ich z.B. von iPhone-Nutzern, dass sie diese "optimierten" Seiten gar nicht mögen.

So gesehen ist der Weg über ein an bestimmte Auflösungen angepasstes CSS (über sogenannte media queries, die die tatsächliche Displayauflösung abfragen) derzeit der einzig sinnvolle. Der Haken dabei ist aber, dass das nicht "global" umsetzbar ist -- es muss individuell für jedes Template angepasst werden. Eine eierlegende Wollmilchsau in Form eines Plugins sehe ich da im Moment nicht.

YL

Hi,

danke für die Info mit dem Plugin. Genau das meinte ich.

Sicherlich ist es sehr schwierig für alle Displayauflösung sowas zu machen. Ich versuche zurzeit das xhtml_mp Template an die gängigen Smartphones anzupassen. Also das serendipity_event_mobile_output plugin hat ja bereits eine angepasstes Template für das iPhone. Neben dem iPhone gibt es überwiegend nur noch die Android Handys. Da man wie du schon sagtes nicht alle Auflösungen hinbekommen kann, werd ichs einfach auf das Populärste Android Smartphone anpassen. Also den Desire. Samsung Wave hat das gleiche Display. Problem Blackberry,Palm, und die anderen Android Handys sind außen vor. Tja...trotzdem bin ich froh das es das Plugin gibt.

mfg refi

[refilix]

Mein Gott da schaut man ein paar Wochen nicht ins Forum und schon passiert hier was.^^

Lass dir das man dscha nich zu Kopfe steigen....!

Andererseits könnte es mal ruig einige Verbesserungen geben. Da fallen mir spontan die Templates ein und das Download Plugin. Was ich für stark Verbesserungswürdig halte. Ich hatte das Download Plugin schonmal angesprochen. Garvin hatte damals auch reagiert.

Der Downloadmanager ist in Arbeit (siehe 0.23.1).
Die "90000".0.24 ist fast fertig!
Ich mache mal einen neuen Thread auf, der Verbesserungsvorschläge und code contributions beeinhalten könnte.

Aber alles ohne Gewähr (Ich habe mich nur gezwungenermaßen drangesetzt)!

Ian

Cool.^^ Darauf warte ich schon lange

[yellowled]

Neben dem iPhone gibt es überwiegend nur noch die Android Handys. Da man wie du schon sagtes nicht alle Auflösungen hinbekommen kann, werd ichs einfach auf das Populärste Android Smartphone anpassen.

Ist in meinen Augen sinnfrei. Der (derzeit) einzig sinnvolle Weg ist es, über media queries im CSS die tatsächliche Displayauflösung abzufragen und für diese individuelles CSS auszuliefern. Das funktioniert dann als angenehme „Nebenwirkung“ z.B. auch für kleine Bildschirmauflösungen auf dem Desktop, etwa 800x600 oder so.

Nehmen wir mal an, Du hast ein typisches Layout, in dem ein links gefloateter Inhaltsbereich von 640 Pixeln Breite und eine rechts gefloatete Sidebar von 320 Pixeln Breite in einem 960 Pixel breitem Container liegen.

Code: Select all

<div id="container">
    <div id="main">
    [...]
    </div>
    <div id="sidebar">
    [...]
    </div>
</div>

und im CSS:

Code: Select all

#container {
    margin: 0 auto;
    width: 960px;
}
#main {
    display: inline;
    float: left;
    width: 640px;
}
#sidebar {
    display: inline;
    float: right;
    width: 320px;
}

Dann kann man annehmen, dass zumindest alles, was eine Auflösung zwischen 640 und 960 Pixeln hat, noch das Wesentliche (den Inhalt) lesen kann, ohne horizontal scrollen zu müssen. Für alle anderen sollte man etwas unternehmen, z.B. sowas hier:

Code: Select all

@media handheld and (max-device-width: 640px),
screen and (max-device-width: 640px),
screen and (max-width: 640px) {
    #container,
    #main,
    #sidebar {
        display: block;
        float: none;
        width: 100%;
    }
}

(Das ist natürlich sehr rudimentär.)

Und schon werden bei Auflösungen < 640 Pixel (und zwar in allen Browsern != IE, der @media noch nicht kann , aber auf allen Endgeräten, ob Smartphone, PC oder Netbook) Inhalt und Seitenleiste in voller Bilschirmbreite untereinander dargestellt.

YL

[refilix]

Ich weis das mein Lösungsansatz nicht das Gelbe vom Ei ist.

Aber ich bin ein Noob und kann nur das machen wozu mein Wissen reicht.

Hab das xhtml_mp Template Angepasst an die Auflösung eines Desire via CSS. Das Orginal Template hat genau das Problem was du beschrieben hast. Es ist alles unlesbar klein. Nur wenn man den Smartphone Quer hält kann man was Lesen. Wenn ich könnte würde ich es besser Anpassen, aber ich kann nicht.

Aber du vieleicht?

mfg refi

[yellowled]

Aber du vieleicht?

Nö. Von Plugins lasse ich die Finger, dafür ist mein PHP zu schlecht. Es ist durchaus denkbar, dass es demnächst ein freies Template gibt, das media queries verwendet, aber dazu muss ich a) die Zeit finden, es umzusetzen, b) noch viel vorbereiten und c) endlich mal das Javascript verstehen, was den Kram auch dem IE beibringt.

YL

[hagenroewer]

Moin,

Ja aber diese Unterschiede entstehen doch nicht durch die Systeme selbst! Das einzige was Wordpress wirklich von sich aus mehr kann ist die Verwaltung von mehreren Blogs gleichzeitig. Ansonsten ist die Grundfunktionalität ziemlich genau die gleiche.

Schon liest man hier nicht länger mit, dann entstehen hier wieder interessante Diskussionen.

Die Funktionalität, die du weiter oben ansprichts, gibt es auch länger in S9Y, bekannt als Shared installation unter http://www.s9y.org/41.html. Auch hat Fadoe dazu mal eine interessante Anleitung geschrieben.

In meiner Grundinstallation installiere ich mittlerweile S9Y fast nur noch so, damit falls die Anforderung, ich schnell noch ein Blog dazu packen kann.

Oder geht es dir um Automatismus?
Den habe ich bei WP nie so gefunden, vielleicht in der Erstinstallation, aber danach das ständige Rumschrauben mit Plugins und Templates - nee - da finde ich S9Y einfacher.
Und auch wenn YL es gerne nicht lesen mag, ich nutze es gerne als kombinierte BlogCMS-Engine (weiß YL aber auch)

Tschüß ...

[Timbalu]

Hi Garvin

Gibt es eigentlich Überlegungen - aus Performancegründen - die S9y v.1.6 möglicherweise mit Smarty 3.x oder Dwoo herauszugeben?
Man könnte ja für PHP4 Nutzer einen fallback auf Smarty 2.x einführen...

Ian

PS:
Immer wieder fallen mir auch so Sachen ein wie:

• Universelle und sichere Funktionalität des Upgrades von Plugin mit Datenbanktabellen, damit man beim Plugin Schreiben auf eine sichere Methode zurückgreifen kann.

• Test Verfahren bzw Dokumentationen, ob Plugin in der richtigen Reihenfolge installiert sind... bzw Prüfung auf Pluginabhängigkeiten...

Allerdings sind das nur so Dinge die mir irgendwann mal so zwischendurch als irgendwie verbesserungswürdig auffielen, nichts wirklich durchdachtes bis jetzt... [unvollständig].

[garvinhicking]

Hi!

Ich wäre dem gegnüber grundsätzlich offen. Ich hatte aber noch keine Mögichkeit Smarty 3.x/Dwoo mal anzusehen. Wenn da jemand interesse hätte herum zu arbeiten, dann sehr gerne. Wir haben derzeit eh den experimentellen SVN "2.0" branch wo man mit so etwas herumspielen könnte. Oder auch als git-fork, oder wie immer.

Ein PHP4 fallback sehe ich nicht mehr unbedingt für notwendig an, den sprung zu PHP5-required können wir schon mit der 2.0er locker gehen.

Grüße,
Garvin

[onli]

Wunsch: Tabbed Optionen durch Übergabe verschachtelter Arrays oder so, also ohne jeglichen Kontrollcode seitens des Plugins.

Ein Datenbankupgradefunktion für Plugins wäre für mich sehr hilfreich, wenn man sich dadurch die Prüfungen sparen kann. Kann mir aber noch nicht vorstellen, wie das aussehen sollte.

[yellowled]

Darf ich auch noch ein paar Feature-Wünsche raushauen? Ist ja bald dieses komische Fest.

* tabbed theme options; bei so Geschichten wie BP eigentlich unverzichtbar
* Möglichkeit, die maximale Kapazität einer Seitenleiste vorzugeben (sehr hilfreich für die Formatierung von Seitenleisten, die horizontal verlaufen oder als Tabs ausgegeben werden); bisschen wie Widget-Areas bei Drupal oder WP
* so eine if-else-Abfrage für serendipity_showPlugin wäre super; "gib das Plugin hier aus, falls es installiert ist, ansonsten gib den folgenden Hinweis aus"

EDIT: Bisschen aus der „YL träumt rum“-Ecke

Ich würde mir wünschen, dass wir in absehbarer Zeit:

1. eine JS-Library, vorzugsweise jQuery, mit S9y bundlen und in Backend und Frontend nutzen
2. das Backend modernisieren, auf dass es benutzbarer und vor allem schmerzfreier zu gestalten werde (Ja, das bedeutet weg mit Frames, Tabellen und dem ganzen anderen Rotz.)
3. im Zuge dessen auch endlich mal ein neues, zeitgemäßes Standard-Template ausliefern

(Uh. Ich habe gerade scheißviel Arbeit vorgeschlagen, hm? Naja. Wir haben ja sonst nix zu tun.)

YL

[kleinerChemiker]

bei der gelegenheit könnte man gleich s9y 2.0 mit php5 neu schreiben

[Lux]

Ein PHP4 fallback sehe ich nicht mehr unbedingt für notwendig an, den sprung zu PHP5-required können wir schon mit der 2.0er locker gehen.

Hurra!

Woher kommt der Sinneswandel?

Gruss

Dirk

[garvinhicking]

Hi!

Woher kommt der Sinneswandel?

Alles eine Frage der Zeit. PHP5 dürfte inzwischen ja überall verfügbar sein. Und mit s9y < 2.0 steht ja dann noch eine PHP4 Alternative im Raum.

Onli, Yellowled: Sehr gute Wünsche, tabbing und so ist auch sicherlich gut umsetzbar. Daran arbeite ich die nächsten Wochen/Monaten sicher mal gerne. Muss mir noch überlegen, ob man das nicht auch schon für 1.6 mit einbaut, bevor man das 2.0er Fass aufmacht und das Release dort evtl noch länger läuft. Ich würde jquery als Defaultbibliothek nutzen wollen. Man müsste mal überlegen wie man dann mit Plugins vorgeht, die jquery ja bereits bundleln, ob mehrere referenzierte jquery versionen dann große probleme machen. Im Plugin selbst kann man sonst sicher die s9y version überprüfen und dann jquery unterbinden.

Das mit der "Widget area" ist mir noch nicht so klar, seitenleistenplugins sind ja nie wirkich fix in ihren ausmaßen?!

Für die konkreteren Diskussionen zu den Einzelwünschen wäre ein neuer Thread ganz praktisch...

Grüße,
Garvin

[Lux]

Alles eine Frage der Zeit. PHP5 dürfte inzwischen ja überall verfügbar sein. Und mit s9y < 2.0 steht ja dann noch eine PHP4 Alternative im Raum.

Ich freue mich sehr über Deine Entscheidung.

Für die konkreteren Diskussionen zu den Einzelwünschen wäre ein neuer Thread ganz praktisch...

Geht es nur um Kern-Features oder auch um Plugins?

Bei den Kern-Features hätte ich gerne eines, dass das Aufräumen der Datenbank nach bestimmten Kriterien aus der Adminoberfläche heraus möglich macht.

Und ein weiteres, dass die Mediendatenbank nach nicht benutzten Medien durchsucht.

Aufräumen ist vielleicht ein weiterer zentraler Punkt. Löschen aller Plugins und Templates, die über Spartacus gekommen sind, aber nicht benutzt werden.

Gruss

Dirk