Hi an alle,

 

Dank der freundlichen Erlaubnis von Pascal und dem Team darf ich euch - wenn auch sehr verspätet - das Projekt "Coaster Platform" einmal vorstellen. Bei diesem Projekt handelt es sich um eine Freizeitpark Datenbank - OK, zugegeben: Nicht wirklich was neues. Davon gibt es bereits einige mit großen Datenbestand. Weshalb komme ich dann auf die Idee noch eine auf die Welt loszulassen?  Weil ich mich vor Jahren mal geärgert habe. Ich wollte gerne eine App Entwickeln und musste dann feststellen: Daten zu bekommen ist nicht so einfach. Und selbst wenn man einen Partner mit Daten gefunden hat, kann man mit den Daten kaum was anfangen, weil diese nicht optimal weiter verarbeitet werden konnten. Viele, viele Blogs und Seiten haben interessante Daten - aber außer Copy & Paste kann man damit nichts anfangen. Mein App Projekt musste ich beenden. Immer wieder stelle ich fest, dass ich damit nicht alleine bin. Viele Webbetreiber wollen Freizeitparkdaten in deren Seite einbinden - und machen dann mühseliges Copy & Paste von anderen Quellen. Mal davon abgesehen, dass dabei sogar große Betreiber verbieten jegliche Daten zu kopieren.

 

Soviel zur Geschichte - genau hier setzt nun Coaster Platform ein. Coaster Platform soll eine "Open API" für Freizeitparkdaten sein. Zu den anderen Datenbank unterscheiden wir uns daher wie folgt:

- Wir erlauben ausdrücklich, dass alle Textdaten von unserer Datenbank kopiert werden dürfen (Creative Commons Lizenz)

- Wir stellen kostenlos eine API zur Verfügung, um Daten abzufragen und direkt in deren Projekt (Webseite, App) einzubinden

- Jeder darf nach einer Anmeldung Daten bearbeiten oder neue hinzufügen (Community stellt Content)

- Alle Werte werden atomar gepflegt

 

Wir stellen also eine Plattform und Schnittstelle, um Freizeitparkdaten für eigene Webseitenbetreiber und Apps bereitzustellen. Wenn einer also gerade Lust hat eine App zu bauen oder ein neuen Blog, kann dieser einfach über die API Daten abfragen und nutzen und muss nicht sich diese Daten mühselig aneignen. Durch die atomare Pflege eignen sich die Daten auch ideal für die Weiterverarbeitung, zb. um nach bestimmten Hersteller zu filtern. Plugins zum Beispiel für Wordpress um Daten aus der API auch für nicht technische Leute zu erhalten sind in Planung - dauern aber vermutlich noch ein paar Wochen.

 

Wieso erzähle ich euch das jetzt alles?

Die Seite ist gerade einmal 24 Stunden online - quasi ein Soft Opening, da ich noch keine Werbung machen. Die Phantafriends Community ist exklusiv als Tester eingeladen diese neue Plattform zu testen. Entweder als einfacher Gast zum schauen, oder man meldet sich an und Pflegt ein paar Daten oder man spielt mit der API rum. Das kann jeder für sich selbst entscheiden. Ich freue mich über jedes Feedback wodurch ich dieses Projekt verbessern kann. Feedback könnt ihr einfach in diesem Thread schreiben - auch Fragen oder generell Anmerkungen. Bedenkt dabei bitte, dass bisher nur Entwickler auf der Seite waren. Es kann daher und wird durchaus vorkommen, dass noch Fehler vorhanden sind oder manche Punkte völlig unklar erscheinen. Zumal das Projekt komplett Eigenbau ist und auf kein CMS System beruht. Außerdem arbeite ich meist täglich an der Seite, weshalb sich die Seite immer wieder mal ändern kann.

 

Das Projekt findet ihr unter folgenden Adresse: https://coaster-platform.org

 

Vielen Dank vorab für jedes Feedback!

Am 14.2.2019 um 08:48 schrieb flofen:

Hab mir das jetzt endlich mal eingerichtet. Und klappt sogar alles wie es soll

Danke sehr. 

 

Ahh, das ist selbstverständlich. Ich versuche ja was faires für alle rauszuholen. Soeben ging die Mail für die neuen Nutzungsbedingungen raus. Ab den 1. März ist diese dann "gültig".

Solltet euch da noch was auffalen gebt ruhig bescheid.

 

Ansonsten gebt es kaum berichtbares. Paar technische Themen wie eine Sitemap sind raus. In den nächsten Tagen werde ich wohl wieder mehr Richtung Bearbeitung und Anzeige von Parks / Attraktionen ein paar Optimierungen raushauen.

 

Als richtiger "Go Live" Termin peile ich den 18. März an.

Eine Sache ist mir bei meiner App-Programmierung aufgefallen. Die kannst Du auch gut nachstellen. Wenn ich bei "Parks" auf beide Kategorien filtere, wird immer nur die letzte berücksichtigt, die mitgegeben wird. Wenn man beide Kategorien als Filter auswählt, sollten aber alle Ergebnisse logischerweise enthalten sein. Sonst sieht alles soweit gut aus. Und die API ist (bisher) auch wirklich sehr performant.

 

Was noch schöne wäre: bei den Parks ein Integer-Feld mitgeben, dass die Anzahl der dem Park zugeordneten Attraktionen zurück gibt.

vor 55 Minuten schrieb Tommy:

Wenn ich bei "Parks" auf beide Kategorien filtere, wird immer nur die letzte berücksichtigt, die mitgegeben wird. Wenn man beide Kategorien als Filter auswählt, sollten aber alle Ergebnisse logischerweise enthalten sein.

Ah guter Punkt. Ich vermute mal, du machst es so: ?filter=types.name:"themepark"&filter=types.name:"waterpark" oder ?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark"

Dann ersetzt das letzte das vorherige. Ist ein Bug. Das passe ich an.

 

Folgende Syntax funktioniert schon out of the box: ?filter=types.name:"themepark" OR types.name:"waterpark" bzw. ?filter[]=types.name:"themepark" OR types.name:"waterpark"

 

vor einer Stunde schrieb Tommy:

Was noch schöne wäre: bei den Parks ein Integer-Feld mitgeben, dass die Anzahl der dem Park zugeordneten Attraktionen zurück gibt.

 Wird asap kommen. Gute Idee.

 

 

vor einer Stunde schrieb Tommy:

Und die API ist (bisher) auch wirklich sehr performant.

Noch ist ja kein Traffic drauf. Das Projekt ist ja quasi nur hier veröffentlicht. Aber ich versuche tatsächlich auch die API so performant wie möglich zu halten. Wird sich dann Zeigen je mehr Daten und Traffic reinkommen, wie sich das entwickelt. Die Filterung läuft extra über eine Search Engine anstatt über die Datenbank. Und durch Hosting bei heroku.com kann sehr schnell skaliert werden, wenn plötzlich mal die Performance einbricht.

 

Danke fürs Feedback!

Die API wurde soeben aktualisiert.

 

Beim Punkt mit den Filtern muss ich ein wenig zurück rudern. Nachfolgend einmal nochmal die Möglichkeiten:

 

1. doppelt "filter="

/api/parks?filter=types.name:"themepark"&filter=types.name:"waterpark" 

Hier wird "filter" ersetzt, bevor ich überhaupt dran komme. Daher hat sich hier nichts geändert.

 

2. doppelt "filter[]="

/api/parks?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark"

Das verarbeitet die API prinzipiell richtig. Nur wird dann eine "UND" Verknüpfung gemacht. Also werden nur Parks gefunden, die sowohl als Themepark und Waterpark gekennzeichnet sind. Ob man nun eine UND oder eine ODER Verknüpfung erwartet ist dann wohl Geschmackssache.

 

3. Search query

/api/parks?filter=types.name:"themepark" OR types.name:"waterpark"
/api/parks?filter[]=types.name:"themepark" OR types.name:"waterpark"

Beides war schon vorher möglich. Hier wird eine Query gebaut die 1:1 an die Such Engine geht. Da kann man dann eben "OR" oder "AND" nutzen.

 

4. any / all Methode

/api/parks?filter=any(types.name,themepark,waterpark)
/api/parks?filter=all(types.name,themepark,waterpark)

Die habe ich soeben neu gebaut und soll eine vereinfachung aus den Punkt 3 sein. Bei "any" muss nur eines der Begriffe aus types.name zutreffen (also eine OR Verknüpfung). Bei "all" müssen alle vorhanden sein (AND Verknüpfung).

 

Du kannst dein Filter Problem also mit der Search Query (Punkt 3) oder mit der neuen "any" Methode lösen. Des Weiteren werden bei Parks unter "attractions" nun die Anzahl der Attraktionen mitgegeben.

 

Ich werde übers Wochende die API Dokumentation mal stark zu verbessern. Hilft dir das denn soweit weiter?

 

Heute mehrere kleinigkeiten zu vermelden:

 

- Die Felder "Themenbereich" und "Thema" waren bisher immer Textfelder. Ich hatte damals nicht dran gedacht, dass man mehrere Werte reinschreiben könnte. Diese Felder sind nun "Tags" Felder, wodurch die Werte getrennt gespeichert werden (siehe Bild section.png).

- Bei der Attraktionsliste innerhalb der Parks kann man nun nach dem Themenbereich filtern (siehe facet.png).

- Fehler im Javascript bei Park / Attraktionsbearbeitung behoben

- Die Coaster API erlaubt nun auch die Zugriff via Javascript von anderen Seiten

 

Sollten sich hier Javascript Entwickler befinden: Auf CodeSandbox habe ich ein jQuery Beispiel gebaut um Daten abzufragen. https://codesandbox.io/s/l91ypr26z

 

 

Über einen Monat habe ich mittlerweile nichts zum Projekt geschrieben - in den vergangenen 30 Tagen habe aber dennoch fleißig dran gearbeitet:

 

Auszug aus Github:

Zitat

Excluding merges, 1 author has pushed 49 commits to master and 49 commits to all branches. On master, 89 files have changed and there have been 3,133 additions and 2,565 deletions.

 

Also 89 Dateien bearbeitet und an ca. 5.000 Zeilen Code verändert. Und das Resultat ... seht ihr nicht. ?

 

Sogut wie alles was ich gemacht habe, war rein technischer Natur. Das einzige Änderungen, die vll auffalen:

- "Commits" habe ich in "Logs" umbenannt, da dies für Verwirrung in Gesprächen gesorgt hat

- Der Playground für die API wurde ausgelagert

- Über die API können nun auch die Logs abgefragt werden

 

Stück für Stück soll es in den nächsten Wochen zu diesem Ziel kommen:

- Parks / Attraktionen können auch über die API aktualisiert und angelegt werden ( @Tommy ich glaub das hattest du auch mal angefragt?)

- Benutzerhandling geht komplett über die API

- Das komplette Frontend ist eine reine Javascript Anwendung welches zu 100% auf die API zurückgreift.

 

Ansonsten bin ich weiterhin für weitere Ideen / Vorschläge zum Projekt offen ?

Heute gibt dann doch mal mehr neues "zum zeigen":

- Ein Fehler bei der Ausgabe von "Ja / Nein" Feldern wurde behoben (es wurde immer nur das grünr Häkchen angezeigt)

- Folgende Elemente sind hinzugekommen: In-Line Twist, Sidewinder, Batwing, Cobra Roll, Double Down, Double Up, Non Inverting Loop, Wing Over Drop, Top Hat, Roll-Over, Pretzel Loop, Cable Lift

- Das Feld "Sitzart" heißt jetzt "Rückhaltesystem" und hat zwei weitere Auswählmöglichkeiten: "Westenbügel" und "keins"

- Bei Attraktionslisten kann man nun rechts nach dem Eröffnungsjahr filtern (wenn man zb. "2020" eingibt erscheint FLY, bei "2016" erscheint zb. Taron)

- Eine erste "Alpha"-Version einer Javascript Library zur Abfrage von Daten (für die Entwickler unter euch) liegt nun auf NPM: https://www.npmjs.com/package/coaster-platform.js

 

Vielen Dank nochmal an alle.

Bearbeitet 31. März 20196 Jr. von migo315 (Änderungen anzeigen)

In der Attraktionsliste (sowohl die allgemeine als auch bei Parks) kann man nun den List Typen wählen. Dafür gibt es zwei Icons, die wahlweise das bisherige "Bilder-Grid" Anzeigen oder eine Liste ohne Bilder aber mit mehr Informationen.

 

Die neue Liste sieht noch nicht so fit aus - da werde ich noch was ändern und vermutlich auch noch mehr Informationen anzeigen. Aber die Grundidee, das man zwischen Listentypen wählen kann, wollte ich trotzdem schonmal veröffentlichen ?

 

Hier, falls man nicht sofort erkennt was ich meine:

 

Hier mal ein paar News.

 

- Die "Detaillisten" für Attraktionen und Parks sehen mittlerweile recht gut (siehe Anhang). Man kann beliebig zwischen den Listentypen wechseln.

- "Spielplatz (innen)" und "Spielplatz (außen)" sind zusammengefügt worden (zu "Spielplatz"). Ob es Indoor / Outdoor ist kann man ja mittlerweile in den technischen Daten vermerken (das gabs zu Anfang noch nicht).

 

Und was größeres:

Bei Datumsangaben sind nun auch Formate ohne Tag und ohne Monat möglich. Also bei "Eröffnung" kann nun auch einfach ein Jahr oder ein Jahr und Monat angegeben werden. Es komplettes Datum ist nicht mehr notwendig. Allerdings ist das eine "massive" Änderung. Bei der Eingabe des Datums muss nun ein Format beachtet werden. Folgende Daten sind nun erlaubt "1989", "1989-05" oder "1989-05-31". Sowas wie "31.5.1989" geht zum Beispiel nicht. Auch Browser Hilfen zur Datumnsauswahl sind nicht deswegen nicht mehr vorhanden (die beruhen eben darauf, dass man ein komplettes Datum auswählt). Ich werde aber zeitnah Hilfen bereitstellen, damit dies einfacher ist. So sieht dies dann aus, wenn man nur ein Jahr angibt https://coaster-platform.org/parks/phantasialand/attractions/f-l-y  oder eben ein Jahr mit Monat https://coaster-platform.org/parks/movie-park-germany/attractions/bandit

 

Das hat leider auch ein Breaking Change in der API zur folge, weil die API immer ein kompletten Zeitstempel zurück gab. Aber da nun auch "unvollständige" Daten gepflegt werden können, kann kein Zeitstempel mehr zurück gegeben werden. Die Dokumenation zur API folgt noch im Lauf des Tages.

Wenn jemand spontan noch eine coole Idee hat um den Reiz etwas zu pflegen zu erhöhen - nur her damit ?

 

Die Tage möchte ich noch den Ersteller und letzten Bearbeiter prominent am Park / Attraktion anzeigen.

Ansonsten könnte ich mir vorstellen, dass Nutzer die Sachen pflegen, die Möglichkeit erhalten ihr eigenes Projekt (zb. seinen Blog) auf coaster-platform.org vorzustellen. Gibt es Blogger oder Leute mit eigenen Projekten hier? Und wenn ja, wäre das ein Anreiz für euch?

Hab jetzt länger keine Infos mehr rausgehauen, um hier nicht unnötig zu "spammen". Nachwievor arbeite ich ca. alle 2 Tage an dem Projekt - letzte Woche mal aufgrund einer Erkrankung ausgenommen. Hier die letzten Anpassungen:

 

- Die Hauptfarbe hat sich ein wenig geändert (dunkleres blau / neues Logo)

- Im Kopfbereich kann man nun nach Attraktionen / Parks suchen

- Der Ersteller einer Attraktion / Park wird nun auf der Park / Attraktionseite angezeigt

- Der letzte Bearbeiter einer Attraktion / Park wird nun auf der Park / Attraktionseite angezeigt

- Neuheiten können abgerufen werden (links in der Navigation gibt es ein neuen Punkt)

- Attribute (Technische Daten) und Elemente sind im Bearbeitungsmodus alphabetisch sortiert

- Es gibt zwei neue Attribute für XXL Sitze und Testsitze

- Alle Contributor (Bearbeiter) werden nun auf der Attraktion / Park Seite mit der Anzahl an Logs angezeigt

- Parks und Attraktionen werden versioniert gespeichert (so dass man theoretisch jederzeit auf eine Version davor zurück springen kann)

- Die API wurden zum Teil optimiert und unnötigen Inhalte (die nur für die Webseite da waren) entfernt

- Bilder werden nicht mehr bewertet - stattdessen wird die Reihenfolge der Bilder per Zufall entschieden

 

Das waren nur grob die "offensichtlichen" Punkte. Intern gab es auch einige Bugfixes, Updates einiger Abhänhigkeiten und Optimierung von Code.

 

Für Contributor hoffe sich sind nun mehr Anreize geschaffen etwas zu pflegen. Jeder einzelne wird auf der Detailseite nun erwähnt. Besonderer Ersteller neuer Attraktionen / Parks profitieren davon, dass diese ewig als "Ersteller" auch auf der Detailseite gekennzeichnet werden (übrigens auch Rückwirkend für alle, die bereits Sachen gepflegt habe). Die Reihenfolge der Bilder wird nun per Zufall entschieden - so dass jedes Bild mal vorne bzw. als Hauptbild steht. Btw: Der Bilderupload pro Park oder Attraktion ist auf 6 beschränkt. Wenn also 6 Bilder für Taron hochgeladen wurden, gibt es aktuell keine Möglichkeit weitere Bilder für Taron hochzuladen bis einer sein Bild wieder löschen sollte.

 

Tatsächlich fände ich weiterhin Gamification recht cool. Also so typische Badges für Erfolge wie "Erste Attraktion erstellt" oder "10 Bilder hochgeladen". Leider fehlen mir hier aber die Kreativität und Können um entsprechende Badges zu designen. Hab ich aber weiterhin im Hintetrkopf.

 

Für die nächsten Woche steht die Mehrsprachigkeit an. Neben deutsch soll auch englisch pflegbar sein, um die potenzielle Zielgruppe massive zu erhöhen.

Gerade mal wieder reingeschaut, sieht echt super aus! Designänderung hat was. Ebenfalls die Kopfzeile (mit dem fancy Logo ). Das zufällige Anzeigen von Bildern (auch in der Attraktions- und Parkliste) ist schön abwechslungsreich.

Hier stellt sich mir nur die Frage, ob es eine Grenze an hochgeladenen Bildern für jeweils eine Attraktion / Park gibt. Gegebenfalls könnte man das Bewertungssystem weiterhin verwenden um beispielsweise die Top 10 bewerteten Bilder zufällig (in der Park- und Attraktionsliste) darzustellen. Mein Gedanke hierbei war, dass so die Bilder bevorzugt ausgewählt werden, die viel Fläche/Kulisse vom Park zeigt (ist halt meist höher bewertet). Bilder wie von einzelnen Statuen, Attraktionsschildern, etc. können somit angeschaut werden, werden aber nicht als bildliches "Aushängeschild" in der Attrakton/Parkliste angezeigt.

Zu guter letzt: Der Neuigkeitentab ist natürlich auch super! Hier wäre es aber vielleicht angenehmer ein Dropdown Menü für das jeweilige Eröffnungsjahr zu benutzen. Wenn technisch machbar auch nur mit den Jahreszahlen, in welchen ein Datensatz zu einem Eröffnungsjahr vorliegt (Bsp. eine Attraktion mit einem Eröffnungsjahr aus 1910 wird wohl kaum existieren in den Datenbank, dieses Jahr muss also nicht angezeigt werden).

Bearbeitet 28. Mai 20196 Jr. von Kleator (Änderungen anzeigen)

Am 28.5.2019 um 08:34 schrieb Kleator:

Gerade mal wieder reingeschaut, sieht echt super aus! Designänderung hat was. Ebenfalls die Kopfzeile (mit dem fancy Logo ).

 

Das helle blau vorher ging ja gar nicht. Aber für Style Anpassungen brauche ich immer meine Zeit. Das Logo selber ist eher aus der Not enstanden. ?

 

Am 28.5.2019 um 08:34 schrieb Kleator:

Hier stellt sich mir nur die Frage, ob es eine Grenze an hochgeladenen Bildern für jeweils eine Attraktion / Park gibt.

Die Idee Bilder zu "kategorisieren" hatte ich auch schon. Also beispiel: "Bild zeigt großflächig Attraktion", "Deko Objekt", "Layout Bild", "Warteschlange" o.ä. Auch mit Datumsangabe, so dass man auch ältere Bilder hochladen kann und den Verlauf der Attraktion / Park schön sieht (Timeline?).

Fände ich mega geil. Das wird ggfs. auch mal kommen. Sehe ich aber jetzt in kürze leider noch nicht. Größtenteils aus politischen Gründen. Tatsächlich scheue ich mich davor, "unbegrenzt" Bilderupload zu ermöglichen, weil je mehr Bilder auf der Plattform sind desto höher das Risiko das ich damit Probleme bekomme. Artikel 13 / 17 haben dies quasi noch bestärkt. Daher ist der Upload pro Park / Attraktion auch auf 6 Bilder beschränkt. Technisch wäre mehr möglich und würde auch viel mehr aus der Gallerie rausholen - aber wenn dann irgendwann für eine Attraktion alleine 50 Bilder verlinkt sind ist die Gefahr für Abmahnung einfach aktuell zu groß für mich.

 

Siehe auch https://www.phantafriends.de/topic/3594-artikel-13-und-wie-es-das-forum-verändern-würde/.

 

Am 28.5.2019 um 08:34 schrieb Kleator:

Der Neuigkeitentab ist natürlich auch super! Hier wäre es aber vielleicht angenehmer ein Dropdown Menü für das jeweilige Eröffnungsjahr zu benutzen. Wenn technisch machbar auch nur mit den Jahreszahlen, in welchen ein Datensatz zu einem Eröffnungsjahr vorliegt (Bsp. eine Attraktion mit einem Eröffnungsjahr aus 1910 wird wohl kaum existieren in den Datenbank, dieses Jahr muss also nicht angezeigt werden).

Ich schau mal ob ich es kurzfristig reinbekomm.

 

 

Am 28.5.2019 um 08:34 schrieb Kleator:

Zu guter letzt: Der Neuigkeitentab ist natürlich auch super! Hier wäre es aber vielleicht angenehmer ein Dropdown Menü für das jeweilige Eröffnungsjahr zu benutzen. Wenn technisch machbar auch nur mit den Jahreszahlen, in welchen ein Datensatz zu einem Eröffnungsjahr vorliegt (Bsp. eine Attraktion mit einem Eröffnungsjahr aus 1910 wird wohl kaum existieren in den Datenbank, dieses Jahr muss also nicht angezeigt werden).

 

Statt dem Eingabefeld kann man das Jahr nun auswählen.

Es gab immer wieder mal den Wunsch nach Öffnungszeiten. Die Idee fand ich recht cool - Coaster Platform soll ja vor allem auch andere Betreiber von Blogs, App etc. entlasten mit solchen Informationen. Somit müsste dann die ganzen Blogs und Co nicht jedesmal selber die Öffnungszeiten einpflegen sondern können diese aus der Coaster API sofort laden. Fände ich mega.

 

Dafür müssten die Öffnungszeiten aber eben einmalig in Coaster Platform gepflegt werden. Das sollte am besten sowenig Arbeit wie möglich machen. Hier wäre mal eure Meinung hilfreich. Wie findet ihr folgenden Ansatz? Im ersten Datumsfeld gibt man ein Startdatum an, im zweiten ein Enddatum. Für diesen Datumszeitraum kann man dann eine Startuhrzeit und eine Enduhrzeit angeben. Lässt man das Enddatum weg, gilt dies nur für den Startdatum. Pflegt man ein Datum aber keine Uhrzeit, gilt der Tag als geschlossen. Tage die in keinen Datum existiert sind ebenfalls geschlossen. Man kann Datum und Datumszeiträume überrschreiben indem man diese erneut angibt. Hier mal der komplette Saisonplan von Phantasialand als Beispiel:

 

 

Als erstes habe ich die Frühlingssaison angegeben, dann die Sommersaison und anschließend die Herbstsaison und Wintersaison. Soweit so einfach. In der Wintersaison zu Silvester (31.12) ist aber bereits um 18 Uhr schluss. Der Tag ist ja bereits mit der Wintersaison abgedeckt (11-20 Uhr) - ich kann den aber nochmal reinschreiben mit geänderter Uhrzeit. Das "letzte" Datum überschreibt die vorherigen Angaben vom betroffenen Datum. Außerdem gibt es ein paar Tage wie der 24.12 und der 01.01 die geschlossen sind. Die Trage ich auch nochmal ein ohne Uhrzeit um dies als geschlossen zu überschreiben. Die letzten beide Datumszeiträume sind ebenfalls geschlossen.

Ich sage also zuerst "vom 22.11 bis zum 19.01" ist Wintersaison und kann anschließend einzelne Tage von der Wintersaison aber als geschlossen markieren.

 

Kämt ihr damit zurecht? Oder zu komplex? Mein Ziel ist es, mit sehr wenig Angaben so eine komplette Saison in 5 Minuten einpflegen zu können. Was meint ihr?

sieht gut aus finde ich

Ich hoffe dass ich bald auch nochmal was Zeit habe ein paar Daten einzufügen, bin momentan leider mit Studium und Hiwi Job recht ausgelastet

Hab jetzt nochmal rumgespielt. Ich denke solche "Modal Fenster" für die Bearbeitung ist am Sinnvollsten? Was meint ihr?

 

 

ich finde das sieht einfach und selbsterklärend aus

@migo315 Das zweite sieht schon sehr viel Übersichtlicher und umgänglicher aus. Vor allem auch (selbst) erklärend (mit der Möglichkeit, dies auch später in andere Sprachen zu übersetzen).

Bisher sind die Angaben ja nur Backgrounddaten, aber eventuell kann man ja grade die Hauptsaison in der Parkansicht auf Basis der Daten anzeigen lassen (also Monat bis Monat, bzw. angefangene Monate mit eingerechnet).

@jen_f13 @Kleator Danke euch beiden.

 

Habe heute noch mit einem Kollegen drüber gesprochen und dabei wurde noch ein Punkt genannt. Es gibt Parks, die für Mo-Fr andere Zeiten haben als Sa + So. Und das über mehrere Wochen. Das muss ich dann auch irgendwie einbauen. Ich versuch es so einfach wie möglich zu machen aber ein wenig kompliziert wird es dann wohl doch um sich "Schreibkram" zu ersparen. Alternativ könnte man auch einfach jeden Tag einzeln speichern aber vermutlich hat keiner Lust jeden Tag einer Saison einzeln hinzuzufügen. ?

 

Vermutlich wird es wohl daher auch 1-2 Wochen dauern bis man Saisondaten speichern kann. Die Screens oben sind auch nur Entwürfe die noch nicht funktionieren.

 

vor 13 Stunden schrieb Kleator:

Bisher sind die Angaben ja nur Backgrounddaten, aber eventuell kann man ja grade die Hauptsaison in der Parkansicht auf Basis der Daten anzeigen lassen (also Monat bis Monat, bzw. angefangene Monate mit eingerechnet).

Kannst du das näher erklären? Hab das nicht verstanden.

 

Btw, hab ich vorhin gesehen das du ganz viele Historie Sachen gepflegt hast ( https://coaster-platform.org/parks/phantasialand ). Sehr cool! ?

Die Historie werde ich wohl auch die Tage dann nochmal umstylen, damit es besser aussieht. Denke da so in Richtung einer Timeline ( https://www.w3schools.com/howto/howto_css_timeline.asp )

 

Die doppelt Pflege für die Attraktion Eröffnung (einmal bei der Attraktion und einmal bei der Park Historie) ist ein wenig unpraktisch. Wir sollten schauen, dass wir Daten nur einmal pflegen. Sobald ihr das irgendwo nochmal pflegen müsst, dann muss ich die Platform anpassen damit es nicht notwendig ist. An diesem Beispiel: Was haltet ihr davon, wenn alle Attraktioneröffnungen und Schließungen automatisch in der Parkhistorie mit Datum stehen? Also, dass man diese nicht nochmal pflegen muss sondern automatisch dort aufgelistet werden? Fände es cool. Alte Attraktionen, die nicht mehr existieren, dürfen übrigens auch erstellt werden. Coaster Platform ist schließlich eine Datenbank für alle Daten - auch alte.