Datumsfeld, Kalender, Bedienfreundlichkeit

Orion7

Orion7

Aktives Mitglied
Thread Starter
Dabei seit
26.01.2004
Beiträge
112
Reaktionspunkte
8
Hallo liebe Leute,

habe neulich einen Rappel bekommen, da mich die im Netz vorkommenden Datumsfelder nerven. Mit Javascript habe ich was gebaut, womit ich selber zufrieden wäre dies auf Seiten anzutreffen, die Datumsangaben in Formularen erfordern. Also z.B. Reisebüro, wo erforderlich ist Beginn und Ende einer Reise anzugeben.
Mein Beispielformular hat zwei dieser Datumsfelder und zwei weiter sonstige Textfelder.
Schmankerl bei meinem Kalender ist, dass auch Feiertage angezeigt werden, was ich bisher noch bei keinem Kalender gesehen habe. Die beweglichen von Ostern abhängigen Feiertage sind nämlich nicht so einfach zu programmieren.

Über das Design kann man sicher streiten, ist aber für einen Webdesigner über CSS und andere Icons ja an die Bedürfnisse der konkreten Seite anpassbar. Primär geht es mir hier um die Bedienbarkeit.

Wie immer macht der IE es anders als gedacht. Gerade dazu hätte ich gerne Meinungen gehört.
 
Finde ich nicht so gut. Ich würde mich von der Bedienung da mehr an dem jQuery-Datumfeld orientieren(oder es sogar übernehmen).

Negativ:
  • Man muss erst auf ein Icon klicken, das ist nicht sehr intuitiv
  • Das Datumfeld wird bei onblur nicht verborgen

Ich denke mal die Feiertage in jQuery reinzuprogrammieren ist vermutlich weniger stressig, als nicht noch mit irgendwelchen IE Anpassungen rumzuschlagen.
 
Darii schrieb:
  • Man muss erst auf ein Icon klicken, das ist nicht sehr intuitiv
  • Das Datumfeld wird bei onblur nicht verborgen
Zum Vergrößern anklicken....
Danke für die Hinweise. Das finde ich beim jQuery Datepicker auch besser. jQuery kannte ich bisher nicht. Muss man sich ja auch erst mal reinfinden. Habe ich mir aber jetzt vorgenommen.
 
Orion7: Immerhin ist Dein Beispielformular in Nullkommanix geladen, während die jQuery-Seite ca. 10sec rumrödelt, bevor ich überhaupt etwas zu sehen bekomme – und das liegt sicher nicht an meiner Leitung (schon eher an meinem mittlerweile etwas betagtem Mac mini G4 1.5 Ghz).
Und etwas zu sehen bekomme ich dann auch im Firefox; mein Safari 2 (unter MacOS X 10.4.10) stürzt auf der jQuery-Seite sang- und klanglos ab…
 
Nachdem ich den Cache vom Firefox geleert habe, hatte ich auch Ladezeiten von ca. 10 Sekunden. Mit MBP 2,4 GHz. Das sind wohl die Nachteile bei so einem Framework, was auf der anderen Seite aber beeindruckende Funktionen bietet.
 
Das liegt nicht an jQuery, dass das so lahm ist, das liegt an der jQuery-Seite, die einfach nur lahm.
 
Na ja, es liegt schon auch daran, was mit jQuery der Browser alles verarbeiten muss. Habe mal eine datepicker Version zum ausprobieren auf meinen Webspace geladen. Im Safari kann man sich unter Develop->Netzwerk-Timeline einblenden lassen. (Mit TinkerTool das Menü "Develop" freischalten.) Bei mir brauchte der jQuery datepicker etwa doppelt so lange wie meine Entwicklung. Knapp unter einer Sekunde.

Bin mir noch unschlüssig, wo ich weiter entwickle.
 
Also ich persönlich würde immer externe Bibliotheken verwenden. Nicht weil die unbedingt schneller und besser sind, sondern weil man sich dabei relativ sicher sein kann, dass sie auch bei den meisten Browsern funktionieren. Von allem was direkt auf das DOM zugreift, lasse ich konsequent die Finger.

also z.B.:
Code: 
$("#foo").css("display", "none");
// statt
document.getElementById("foo").style.display = "none";
Ist mir egal was schneller ist, hauptsache es funktioniert. Und bei solchen einmaligen Sachen ist die Geschwindigkeit auch eher unwichtig. Zudem ist jQuery wesentlich bequemer als sich durch das umständliche DOM-Interface zu hangeln.
 
Ich kann deine Vorgehensweise gut verstehen. Ich stehe halt noch vor der Hürde mich erst mal in jQuery einzuarbeiten. das muss man ja auch erst mal verinnerlicht haben, wie das tickt. Mit dem DOM komme ich inzwischen relativ gut klar.
Habe mich jetzt entschieden erst mal auf meinem Weg weiter zu gehen. Wobei ich für die Zukunft jQuery auf jeden Fall im Auge behalten werde. Danke Darii für den Hinweis darauf, auf jeden Fall aber auch auf die Bedienfreundlichkeit weiter oben. Die Icons braucht man nämlich tatsächlich nicht.
Wenn ich einen vorzeigbaren Schritt weiter bin, werde ich hier wieder posten. Kann aber durchaus eine Weile dauern.
 
Ich kann deine Vorgehensweise gut verstehen. Ich stehe halt noch vor der Hürde mich erst mal in jQuery einzuarbeiten. Das muss man ja auch erst mal verinnerlicht haben, wie das tickt. Mit dem DOM komme ich inzwischen relativ gut klar.
Habe mich jetzt entschieden erst mal auf meinem Weg weiter zu gehen. Wobei ich für die Zukunft jQuery auf jeden Fall im Auge behalten werde. Danke Darii für den Hinweis darauf, auf jeden Fall aber auch auf die Bedienfreundlichkeit weiter oben. Die Icons braucht man nämlich tatsächlich nicht.
Wenn ich einen vorzeigbaren Schritt weiter bin, werde ich hier wieder posten. Kann aber durchaus eine Weile dauern.
 
So, ich denke nun kann ich das Ergebnis wieder zur Diskussion stellen. Auch im IE 6 und 7 sieht es nun praktisch gleich aus wie in Firefox und Safari. Die Reaktion ist ebenfalls fast identisch.
 
Finde ich gut. Wenn man ein Datum angeklickt hat und sich dann doch umentscheidet, muss man erst ein blur des Formularfelds machen und wieder aktivieren, damit das Datum erscheint. Da würde ich noch ein click event dran binden.

Die Framework-Diskussion ist für mich hinfällig. Die meisten Anwendungen können ohne Framework nur sehr schwer geschrieben werden. Ein wenig Code-Overhead (im Fall von jQuery 15-50kb) und dafür 30% weniger vorm Computer hocken + die Sicherheit, dass der Code wirklich funktioniert, und wenn das nicht, von der Community ständig verbessert wird? Da brauche ich nicht überlegen.
 
Okay, habe ich eingebaut. Um den Kalender wieder anzuzeigen muss man bei FF und Safari zweimal in das Feld klicken bei IE einmal. Das sind halt so kleine Unterschiede.
Dies ist eine Funktion, die es z.B. beim Datepicker mit jQuery nicht gibt. Wenn ich die dort einbauen wollte, hmm, weiß nicht wie lange ich da vor der Kiste hocken würde. Wahrscheinlich würde ich diese Kleinigkeit dann einfach sein lassen. In diesem speziellen Fall, wo ich schon relativ weit war in der Entwicklung, glaube ich lag ich richtig, nicht kurz vor dem Ziel umzuschwenken.

Aber klar, wenn ich mal wieder eine spezielle Funktion realisieren wollte, werde ich bestimmt erst mal bei jQuery schauen.
 
Ein Vorteil der Frameworks ist eben auch die gute Caching-Eigenschaft. Wenn zwei Seiten die selbe jQuery-, Prototype- oder Scripaculous-Version nutzen, wird eigentlich nichts neu geladen, sondern es kommt alles aus dem Cache. Somit sind die 10s Ladezeit eher akademischer Natur, weil eben nach einer Cacheleerung. Dafür laden eben auch andere Seiten schneller, wohingegen Eigenprogrammierungen immer komplett geladen werden müssen (außer natürlich man besucht eine Seite zweimal).
 
master_p schrieb:
Ein Vorteil der Frameworks ist eben auch die gute Caching-Eigenschaft. Wenn zwei Seiten die selbe jQuery-, Prototype- oder Scripaculous-Version nutzen, wird eigentlich nichts neu geladen, sondern es kommt alles aus dem Cache. Somit sind die 10s Ladezeit eher akademischer Natur, weil eben nach einer Cacheleerung. Dafür laden eben auch andere Seiten schneller, wohingegen Eigenprogrammierungen immer komplett geladen werden müssen (außer natürlich man besucht eine Seite zweimal).
Zum Vergrößern anklicken....

Hmmm?
Wie soll denn das funktionieren?
Woher soll der Browser wissen, dass meine Site z.B. die gleiche jQuery-Version nutzt wie irgendeine andere Site, bevor er sie geladen hat? Das ginge höchstens, wenn alle Leute die jquery.js vom gleichen Server laden würden (etwa dem der Anbieter); allerdings würde m.E. kein ernsthafter Entwickler Scriptdateien von einem externen Server nutzen.
Zudem dürfte, wie Jakob schon gesagt hat, die reine Dateigröße solcher Lösungen und deren Ladezeit wohl eh kein bedeutsames Problem sein...
 
@Atarimaster bzgl. Hosting von Skripts: Doch, das gibt es schon und wird auch genutzt. Bspw. das Hosting von Google für ein paar der bekanntesten Frameworks (http://code.google.com/apis/ajaxlibs/) oder von Yahoos YUI (http://developer.yahoo.com/yui/articles/hosting/).

Da ein Browser von einem Server nur begrenzt viele Dateien gleichzeitig lädt (ich meine derzeit sind es 4 Dateien beim IE), macht es schon Sinn, Dateien auf anderen Servern zu platzieren. Die meisten großen machen das für Bilder auch noch aus anderen Gründen, daher z.B. images.amazon.com.

Zusätzlich ist immer die neueste Framework-Version installiert. Aber es erhöht auch die Abhängigkeit, da hast Du Recht.
 
Jakob schrieb:
@Atarimaster bzgl. Hosting von Skripts: Doch, das gibt es schon und wird auch genutzt. Bspw. das Hosting von Google für ein paar der bekanntesten Frameworks (http://code.google.com/apis/ajaxlibs/) oder von Yahoos YUI (http://developer.yahoo.com/yui/articles/hosting/).
Zum Vergrößern anklicken....

Mit dem »ernsthaften« Entwickler meinte ich auch einen »professionellen« – und das wiederum meine ich (zumindest hier) im Sinne von jemandem, der dafür bezahlt wird, nicht in Hinsicht auf seine Fachkenntnis.
Derartige Frameworks werden ja typischerweise installiert, weil man auch intensiv damit arbeiten (d.h. sie benutzen) möchte; und ich, steinigt mich, finde es eben nicht professionell, sich in die Abhängigkeit eines anderen Server zu begeben. Der »andere« muss ja nicht mal komplett offline sein, es ist ja schon schlimm genug, wenn er gerade lahmt.
Sicher, auch »mein« Server (also der, auf dem die fragliche Site gehostet ist) kann down sein, dagegen ist nunmal kein Kraut gewachsen. Da ist es für den Besucher aber schnell ersichtlich, dass im Moment nichts zu erreichen ist – er wird es i.d.R. später noch einmal versuchen. Wenn sich aber Teile der Website unerwartet oder gar falsch verhalten, ist das für für den Besucher möglicherweise nicht direkt ersichtlich; und schon gar nicht erklärlich.

Außerdem gibt es (okay, wohl nicht sehr verbreitet) Blocker, die sämtliche Inhalte von externen Server draußen halten...


Jakob schrieb:
Da ein Browser von einem Server nur begrenzt viele Dateien gleichzeitig lädt (ich meine derzeit sind es 4 Dateien beim IE)
Zum Vergrößern anklicken....

Bitte? Wo hast Du denn die Info her?
Ich erwarte ja wirklich nicht viel vom IE, aber sooo schlecht kann selbst der eigentlich nicht sein (kann ich gerade nicht testen: hab hier keinen Windows-PC).


Jakob schrieb:
Zusätzlich ist immer die neueste Framework-Version installiert.
Zum Vergrößern anklicken....

Wie gesagt: In einem privaten oder unbezahlten Umfeld mag das sinnvoll sein.
Aber ein Webmaster/eine Agentur, der/die die Frameworks nicht auf einem aktuellen Stand hält (sofern sinnvoll, also bei Bugfixes oder sicherheitsrelavanten Updates; bei neuen Funktion ergibt das ja nur Sinn, wenn man sie auch nutzt), ist sein Geld nicht wert.


dms schrieb:
Wer dabei Bedenken hat, darf mit der gleichen Argumentation auch kein GoogleMaps und Google Analytics nutzen.
Zum Vergrößern anklicken....

Das ist aber etwas anderes: Bei GoogleMaps bindest Du eine komplette, in sich geschlossene Applikation ein. Das heißt: Wenn die gerade weg ist, kannst Du vielleicht nicht den Anfahrtsweg zu Deinem Geschäft zeigen... aber der Rest der Site funktioniert noch. Das nicht verfügbare JS-Framework kann Dir hingegen auf der gesamten Site arge Probleme machen.
Und Analytics, naja... wenn da mal ein paar Statistiken fehlen sollten, ist das wohl auch kein Beinbruch.
 
Atarimaster schrieb:
Bitte? Wo hast Du denn die Info her?
Ich erwarte ja wirklich nicht viel vom IE, aber sooo schlecht kann selbst der eigentlich nicht sein (kann ich gerade nicht testen: hab hier keinen Windows-PC).
Zum Vergrößern anklicken....
Doch, das ist in der Tat so. Kann man natürlich ändern. M.E. ist das allerdings kein "Feature" des IE, sondern von Windows.

Atarimaster schrieb:
Das ist aber etwas anderes: Bei GoogleMaps bindest Du eine komplette, in sich geschlossene Applikation ein. Das heißt: Wenn die gerade weg ist, kannst Du vielleicht nicht den Anfahrtsweg zu Deinem Geschäft zeigen... aber der Rest der Site funktioniert noch. Das nicht verfügbare JS-Framework kann Dir hingegen auf der gesamten Site arge Probleme machen.
Zum Vergrößern anklicken....

Na, wir verwenden Doch JS-Spielereien nicht als Voraussetzungen und bieten für alles einen Fallback an, oder? ;) Wird das Framework nicht geladen sieht die Seite so aus als ob der Nutzer JS deaktiviert hat. Die (meine) Seiten sind aber dennoch zu 100% benutzbar.
 
Atarimaster schrieb:
Bitte? Wo hast Du denn die Info her?
Ich erwarte ja wirklich nicht viel vom IE, aber sooo schlecht kann selbst der eigentlich nicht sein (kann ich gerade nicht testen: hab hier keinen Windows-PC).
Zum Vergrößern anklicken....

Das hat weder etwas mit Windows noch mit dem IE zu tun. Auch der Firefox macht per Standard höchstens 8 http Verbindungen pro Server, 24 höchstens zu mehreren Servern. d.h. rein unter diesem Gesichtspunkt ist eine Aufteilung der Seiteninhalte auf drei Server ideal für eine Website.

Bei normalen Seiten mit ein paar hundert Besuchern pro Tag und nicht viel Traffic macht es wahrscheinlich keinen wirklichen Unterschied, aber wir reden hier ja über die Sinnhaftigkeit von JS-Frameworks, speziell jQuery.

Meiner Meinung nach sollte man sich beim Entwickeln auf seinen USP spezialisieren und alle Standard-Dinge, die das Geschäft an sich nicht weiterbringen von Standard-Dingen erledigen lassen und nicht neu erfinden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten