Cutlist.at 2.0 und CuLiX - Brainstormingthread
Ideen können hier geposted werden. Das Konzept wird anhand der Ideen nach und nach verfeinert und anschließend hier veröffentlicht:
http://cutlist.at/2.0/
Eine derzeit noch sehr unvollständige und teils sogar noch veraltete Version des Konzeptes sowie ein Zeitplan sind bereits online.
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Das Problem bei den Bewertungen ist mir sehr wohl bewusst, daher ja mein Ansatz für das neue Bewertungssystem:
Der Autor gibt beim Upload folgende Informationen an:
Ausgangsmaterial: audiofehler | bildfehler | anfang fehlt | ende fehlt | asynchron (bild und ton sind versetzt)
Doppelte Szenen: unbekannt | keine | entfernt | noch vorhanden
Schnittgenauigkeit: perfekt | akzeptabel (1 frame, knacken) | grob
Der Benutzer gibt bei der Bewertung folgendes an:
Schnittgenauigkeit: perfekt | akzeptabel | fehlerhaft
Doppelte Szenen: keine (mehr) | noch vorhanden
Abwärtskompatibilität:
5 = perfekt + keine doppelten szenen
4 = perfekt|akzeptabel + doppelte szenen
3 = fehlerhafter schnitt
---
Dass RSS vielen Benutzern wichtig ist, ist mir bereits des öfteren aufgefallen, darauf werde ich in Zukunft mehr Wert legen.
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Danke für die Antwort!
Wie ich schon in dem verlinkten Thread aufgeführt habe, würde ich die alten Schnittstellen einfach so lassen und neue Api-Request fürs Runterladen per JSON anbieten: Ein Request – alle Informationen, inkl. Schnittmarken. Ich sehe auch wenig Nutzen darin, an der Cutlist-Datei als solcher zu bleiben. Die Datei muss heruntergeladen, ausgelesen, am Ende gelöscht werden (wenn es per Client geschieht).
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Hmm, langsam bin ich überzeugt... Also eine neue API die nur noch mit JSON arbeitet und in einem Request die Suchergebnisse inklusive aller Schnittinformationen beinhaltet - und weiterhin Ausgaben in den bisherigen Formaten als XML und ini.
Irgendjemand Argumente dagegen XML nicht vollwärtig zu unterstützen bzw. Argumente gegen JSON?
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Zitat:
Zitat von
anatol.at
(Die gewünschten Typen casten muss man ja trotzdem noch wenn man es nicht nur anzeigen möchte... -_-)
Ich bin mir nicht sicher, ob dich richtig verstehe, aber: Wenn man den JSON-Parser von PHP oder Python nimmt, wird gleich automatisch gecastet. Wenn man stattdessen die Strings noch casten müsste, wäre ein großer Vorteil von JSON verloren gegangen.
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Klar, in Java ist es aber tatsächlich so, dass wenn du ein Objekt oder Array parst alles Strings sind! Nicht nur Zahlen sondern auch verschachtelte Objekte, die müssen dann Ebene für Ebene neu geparst werden. Und einfach mit Strings rechnen ist auch nicht möglich. (Daher sind mir dynamisch typisierte Scriptsprachen grundsätzlich viel lieber...)
PS: falls ich hier was falsches behaupte lasse ich mich gerne eines Besseren belehren. ;)
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Back to topic:
Mist! Ich wusste doch dass wir irgendetwas nicht bedacht haben: die Bewertung auf der Seite basiert darauf, welche Cutlist der Benutzer heruntergeladen hat. Diese Funktion will ich auf alle Fälle beibehalten!
Man könnte natürlich einen zusätzlichen Request senden welche Liste verwendet wurde, aber darauf ist nur bedingt Verlass... (Und es sind erst wieder 2 Requests...)
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Zitat:
Zitat von
anatol.at
Klar, in Java ist es aber tatsächlich so, dass wenn du ein Objekt oder Array parst alles Strings sind! Nicht nur Zahlen sondern auch verschachtelte Objekte, die müssen dann Ebene für Ebene neu geparst werden. Und einfach mit Strings rechnen ist auch nicht möglich.
Da gibt es bestimmt auch alternative JSON-Parser, aber ich lehne mich mal nicht zu weit aus dem Fenster.
Zitat:
Zitat von
anatol.at
Mist! Ich wusste doch dass wir irgendetwas nicht bedacht haben: die Bewertung auf der Seite basiert darauf, welche Cutlist der Benutzer heruntergeladen hat. Diese Funktion will ich auf alle Fälle beibehalten!
Man könnte natürlich einen zusätzlichen Request senden welche Liste verwendet wurde, aber darauf ist nur bedingt Verlass... (Und es sind erst wieder 2 Requests...)
Das ist natürlich ein Problem.
Vielleicht könnte man es ja wirklich so machen, dass die Clients immer nach dem Schneiden eine Rückmeldung an cutlist.at geben, egal ob bewertet wurde oder nicht.
Beispiel:
Code:
/api/rate/id=9012345/cut=1/ds=0 # Nutzer bewertet eine Cutlist
/api/rate/id=9012345 # Nutzer hat Cutlist nicht bewertet, der Client schickt aber trotzdem diesen Request
Das hätte sogar noch einen Vorteil: In der Liste bei cutlist.at würden dann nur die Cutlists zum Bewerten auftauchen, die auch wirklich benutzt wurden, nicht auch eventuelle Test-Dateien, fehlgeschlagene Versuche etc.
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
vielleicht wäre es auch interessant bei den suchergebnissen zusätzlich zu der durchschnittsbewertung der cutlist die einzelbewertungen zu liefern, so könnte man einfacher möglicherweise falsche bewertungen erkennen: (3*5+1*0)/4 = 3,75 = (3*4+1*3)/4.
auch wäre bei der bewertung schön, wenn nutzer kurze kommentare zu den schnittlisten oder gar einzelnen schnitten abgeben könnten(auflistung in den suchergebnissen optional?)!
AW: Cutlist.at 2.0 und CuLiX - Brainstormingthread
Zitat:
Zitat von
anatol.at
hatte ich gelesen, aber als mapping der neuen werte auf das alte format verstanden(also in db weiterhin 1-5).
hab gerade noch mal genauer gelesen und hätte ich dein beispiel angeschaut wäre der teil meines posts vollkommen überflüssig gewesen! sehr schön eindeutig umgesetzt!
Code:
userrating : {
ratingcount : '6',
cuts : { perfect : '5', suitable : '1', unexact : '0' }
duplicatescenes : { removed : '6', stillexisting : '0' }
},
nur ist da ratingcount überhaupt sinnvoll oder nicht eher eine überflüssige fehlerquelle?
von meinem ersten post bleibt nur noch ggf. die idee der benutzerkommentare übrig.