Kalender und calendar.waste

[Cannon]

Das Feature mit dem klickbaren Info-Feld ist jetzt im Develop. Ich habe dazu eine Option angelegt, die man auf 'active' setzen kann, um dies zu nutzen. Default ist das bisherige Verhalten (Option weglassen oder '').

Habe ich mal probiert. Ist doch schon mal echt toll. Anmerkungen dazu:

- das Widget ist breiter geworden (irgendwas stimmt mit Margin oder Padding nicht)
- vielleicht sollte da nicht "Info" stehen, sondenr man nimmt ein Symbol evtl. das + Symbol, was man ja bei den Containern schon hat
- die Info evtl. nur dann sichbar, wenn nicht genug Platz ist

[Cannon]

Cannon, konntest Du den iCal Service schon testen? Wenn Du in der Konfiguration bei den Kalendernamen die Leerzeichen hinter dem Komma weglassen musst, damit es funktioniert, dann sollte es reichen, im Regex Zeile 29 das '+' durch ein '*' zu ersetzen.

Ich habs getestet. Das Austauschen des DIenstes hatte dazu geführt, dass der gar keinen Kalender lädt. Es gab keinen Fehler und es nicht nachvollziehbar warum nicht, denn deine geänderte Zeile 29 funktionierte, wenn ich das bei mir änderte, obwohl beim Vergleich sonst kein anderer Unterschied feststellbar war. Es wurde aber mehr als nur das + und * getauscht:

alt: '/[\s,]+/m'
neu: '/,\s*/m'

Ich habe aber nicht verstanden, wie das genau geht, diese RegEx-Sachen sind echt schwer verständlich ...

Aber um es noch mal zu sagen die Änderung auf "neu" macht auch Kalendernamen mit Leerzeichen möglich.

[wvhn]

Das Feature mit dem klickbaren Info-Feld ist jetzt im Develop. Ich habe dazu eine Option angelegt, die man auf 'active' setzen kann, um dies zu nutzen. Default ist das bisherige Verhalten (Option weglassen oder '').

Cannon, konntest Du den iCal Service schon testen? Wenn Du in der Konfiguration bei den Kalendernamen die Leerzeichen hinter dem Komma weglassen musst, damit es funktioniert, dann sollte es reichen, im Regex Zeile 29 das '+' durch ein '*' zu ersetzen.

$config_calendar_names = preg_split('/,\s*/m', strtolower(config_calendar_name));

Gruß
Wolfram

[Cannon]

Was meinst Du mit „Seiten im Netz?“ Meinst Du URLs, die im Kalendereintrag stehen und dann nicht vollständig angezeigt werden? Das könnte eher ein Escaping-Problem sein. Hast Du ein Beispiel?

Nein, dass hat hiermit nichts zu tun. Das hatte ich bei einen Dienstplaner, wo immer die Namen abgeschnitten wurden, obwohl da noch genug Platz war. Das wurde dann aber mit einem Updaete behoben ....

[wvhn]

Fraglich allerdings ob 15 Zeichen richtig wären. Das Problem bei einigen Seiten im Netz ist, dass da Sachen abgeschnitten werden, obwohl da noch genug Platz ist.

Was meinst Du mit „Seiten im Netz?“ Meinst Du URLs, die im Kalendereintrag stehen und dann nicht vollständig angezeigt werden? Das könnte eher ein Escaping-Problem sein. Hast Du ein Beispiel?

[Tom Bombadil]

Find ich zu kompliziert, dann wird's unübersichtlich - wie oben gezeigt reicht doch.

Simplicity is the key - meistens kennt man doch die Termine sowieso, und braucht die 'Headline' nur als Erinnerung. Für den kleinen Rest - Info aufklappen ...

/tom

[Cannon]

Ich könnte beim Kalender auch die Länge des "where"- Eintrags abfragen und ihn bis ca. 15 Zeichen direkt auf dem Event anzeigen (wie bisher) und nur bei Überschreiten dieser Länge in einem dynamischen Zusatzfeld. Das finde ich noch übersichtlicher.

Was hältst du von dem Ansatz, ab einer bestimmten Länge, dass dann so anzuzeigen: "Stadthalle Gerlingen ...". Das man drauf klicken kann wird der User dann wissen, dann braucht man das "info" nicht mehr. So kann man jedes Kalenderelement aufklappen lassen und von da dann möglicherweise sogar noch eine Verlinkung auf Google Maps initiieren oder so, sprich neben der Adresse noch ein Icon von Google Maps daneben machen.

Fraglich allerdings ob 15 Zeichen richtig wären. Das Problem bei einigen Seiten im Netz ist, dass da Sachen abgeschnitten werden, obwohl da noch genug Platz ist. Kann man das irgendwie an Hand der Schriftbreite ermitteln? Ich kenne mich da leider nicht so aus. :-(

[Cannon]

Falls Zusatzinfos vorhanden sind, wird das platzsparende "Info"-Feld eingeblendet und der Eintrag wird clickbar.

Die Idee ist sehr gut. Ich würde das dann aber eher "Details" nennen. Villeicht kann man auch noch oben in der Titelzeile rechts einen Button machen, um den Kalender zu erweitern, damit weitere Einträge angezeigt werden.

++1 (period) für Kalender, -1 für 'Missed calls' - bei letzterem will man möglichst ohne Zusatzklick sehen, wann ...

Sehe ich genau so.

Wenn Du die ./lib/calendar/service/iCal_(e.g.:Google).php durch die Datei im Anhang ersetzt, sollten Kalender mit Leerzeichen im Namen verarbeitbar sein.

Teste ich. :-)

[wvhn]

Bei der Phonelist würde ich eh nichts machen. Das passt eigentlich immer und Überschneidungen lassen sich vermeiden, indem man nicht die Vornamen der gesamten Großfamilie zu einer Nummer in die Fritzbox hämmert.

Ich könnte beim Kalender auch die Länge des "where"- Eintrags abfragen und ihn bis ca. 15 Zeichen direkt auf dem Event anzeigen (wie bisher) und nur bei Überschreiten dieser Länge in einem dynamischen Zusatzfeld. Das finde ich noch übersichtlicher.

Gruß
Wolfram

calendar_spoiler2.gif

[Tom Bombadil]

Was haltet Ihr davon, die Zusatzinfos in einem separaten Content-Feld anzuzeigen, das man aufklappt?

++1 (period) für Kalender, -1 für 'Missed calls' - bei letzterem will man möglichst ohne Zusatzklick sehen, wann ...
/tom

[wvhn]

Was haltet Ihr davon, die Zusatzinfos in einem separaten Content-Feld anzuzeigen, das man aufklappt?
Falls Zusatzinfos vorhanden sind, wird das platzsparende "Info"-Feld eingeblendet und der Eintrag wird clickbar.

calendar_spoiler.gif

Auf längere Sicht könnte man das Notizfeld des Termins integrieren und Scroll-Balken für längere Texte einbauen.

Gruß
Wolfram

[Tom Bombadil]

Ich würde es unter Design vermuten, finde aber das passende Objekt nicht.

Offensichtlich wird dem Datumsfeld keine eigene Klasse zugewiesen, die man steuern könnte. Oder ich bin zu doof, die zu finden. Aus der Konsole:

<span class="ui-li-count ui-body-inherit">tt.mm.yy hh:mm</span>

Vielleicht kann Wolfram dem Ding einfach in zukünftigen Versionen eine eigene Klasse mit auf die Reise geben, dann ist die css-Adressierung ein Klacks ...

/tom

Edit: War zu flüchtig - es gibt noch eine zweite Appearance hier.

[wvhn]

Cannon Das Problem der Kalendernamen mit Leerzeichen kann ich für den Google-Kalender nicht selbst testen. Wenn Du die ./lib/calendar/service/iCal_(e.g.:Google).php durch die Datei im Anhang ersetzt, sollten Kalender mit Leerzeichen im Namen verarbeitbar sein.

Gruß
Wolfram

[Cannon]

Ein kleiner 'fix' für Cannon wegen Datum/Zeit über Text ist auch mit drin (Text = linksbündig).

Danke, aber der Text ist bei mir sowieso linksbündig. Ich habe gestern schon gesucht aber nicht genau gefunden, wo man das Overlay-Datum konfigurieren kann. Ich würde es unter Design vermuten, finde aber das passende Objekt nicht. Kannst du mir sagen an welcher Stelle? Dann probiere ich damit mal rum.

[Tom Bombadil]

So, ich hab's jetzt doch schnell über .css angepasst:

Vorher:
cal1.png

Nachher:
cal2.png

Falls noch jemand mehrspaltiges Layout für die Widgets verwenden will - hier der Abschnitt aus meiner visu.css:

.calendarlist {
    column-count: 2;
}

.phonelist {
    column-count: 2
}

.calendarlist > ul > li > a
{
    display: inline-block !important;
    width: 75% !important;
    text-align: left !important;
}

.phonelist > ul > li > a
{
    display: inline-block !important;
    width: 75% !important;
    text-align: left !important;
}

Ein kleiner 'fix' für Cannon wegen Datum/Zeit über Text ist auch mit drin (Text = linksbündig).

/tom


Edit:
Ich sehe gerade, dass die Adressierung ggf. Auswirkungen auf den Müllkalender hat. Also lieber entsprechend das Element 'calendarlist' über die ID statt über die Klasse adressieren, also statt '.calendarlist' hier bei mir '#index-clist' (resultierend aus dem Aufruf auf der Seite index.php: {{ calendar.list('clist', '', '6', 'yellow', '', 'K1') }}).