Ich löse die Frage mal aus dem anderen Thread, der graphischen Neugestaltung heraus, weil ich sie durchaus interessant finde.
[quote="Saxe-DD-WXD"]
Mal eine Frage dazu.
Betrifft die Neugestaltung "nur" die Grafik, oder auch eine Überarbeitung der Cachearten?[/quote]
Was stellst Du Dir bei der Überarbeitung der Cachearten vor?
Einstampfen überholterCachearten, bzw. Zusammenlegen von Cachearten?
Und: hast Du Ideen für neue Cachearten?
Überarbeitung der Cachearten
-
Saxe-DD-WXD
Wenn ich schon direkt gefragt werde, werde ich auch antworten. Auch wenn es keinen Sinn hat.
Die Frage nach den Cacharten ist in einem anderen Thread schon einmal Diskutiert worden. Da aber niemand zur Umsetzung da war, ist es untergegangen und nicht bis zu Enden aus diskutiert worden. Der Entwickler soll selbst entscheiden was wie umgebaut werden soll.
Daher hier nur meine persönliche Meinung.
Die Cacharten liessen sich auf 2 reduzieren. Tradi und Multi, also Caches mit einer, und Caches mit mehreren Stationen. Alles weitere kann dann über Attribute eingestellt werden. Als Erstes, ob eine Dose findbar ist oder nicht. Tradi mit Webcam-Attribut ist dann ein Webcam-Cache. Ein Multi mit Mysterie-Attribut ist dann ein Multi mit Einstiegsrätsel. Oder ein Virtual mit mehreren Stationen.
Genau genommen kann man auch über Attribute einstellen ob eine oder mehrere Stationen zum Cache führen. Somit erstellt man einfach einen Cache, und alles weitere stellt man über die Attribute ein. Danach richtet sich dann die Anzeige auf der Karte. Z.B ein Tradisymbol mit Fragezeichen ist ein Mysterie, Multisymbol mit Fragezeichen ist dann ein Multi mit Einstiegsrätsel. Wählt man Cache ohne Dose mit mehreren Stationen und Einstiegsrätsel hat man einen Virtuellen Multi-Mysterie gebastelt. Ebenso kann man die Stationen bei Multis mit Attributen versehen, damit jeder sehen kann was einen vor Ort erwartet. Z.B. Stationen an denen eine Aufgabe erfüllt werden muss als virtuelle Station, eine Station wo man eine Dose suche muss, oder eine Station mit einem QR-Code.
Die Bedienung würde sich dann zwar von anderen Plattformen unterscheiden, ich fände es aber intuitiver, und nach einer kurzen Eingewöhnung dürfte es keine Probleme darstellen. Da hier bei OC nicht so ein strenges Regelwerk besteht, muss man ja die Caches auch nicht so streng Kategoriesieren.
Ich hoffe, ich habe es halbwegs verständlich rüber gebracht.
Die Frage nach den Cacharten ist in einem anderen Thread schon einmal Diskutiert worden. Da aber niemand zur Umsetzung da war, ist es untergegangen und nicht bis zu Enden aus diskutiert worden. Der Entwickler soll selbst entscheiden was wie umgebaut werden soll.
Daher hier nur meine persönliche Meinung.
Die Cacharten liessen sich auf 2 reduzieren. Tradi und Multi, also Caches mit einer, und Caches mit mehreren Stationen. Alles weitere kann dann über Attribute eingestellt werden. Als Erstes, ob eine Dose findbar ist oder nicht. Tradi mit Webcam-Attribut ist dann ein Webcam-Cache. Ein Multi mit Mysterie-Attribut ist dann ein Multi mit Einstiegsrätsel. Oder ein Virtual mit mehreren Stationen.
Genau genommen kann man auch über Attribute einstellen ob eine oder mehrere Stationen zum Cache führen. Somit erstellt man einfach einen Cache, und alles weitere stellt man über die Attribute ein. Danach richtet sich dann die Anzeige auf der Karte. Z.B ein Tradisymbol mit Fragezeichen ist ein Mysterie, Multisymbol mit Fragezeichen ist dann ein Multi mit Einstiegsrätsel. Wählt man Cache ohne Dose mit mehreren Stationen und Einstiegsrätsel hat man einen Virtuellen Multi-Mysterie gebastelt. Ebenso kann man die Stationen bei Multis mit Attributen versehen, damit jeder sehen kann was einen vor Ort erwartet. Z.B. Stationen an denen eine Aufgabe erfüllt werden muss als virtuelle Station, eine Station wo man eine Dose suche muss, oder eine Station mit einem QR-Code.
Die Bedienung würde sich dann zwar von anderen Plattformen unterscheiden, ich fände es aber intuitiver, und nach einer kurzen Eingewöhnung dürfte es keine Probleme darstellen. Da hier bei OC nicht so ein strenges Regelwerk besteht, muss man ja die Caches auch nicht so streng Kategoriesieren.
Ich hoffe, ich habe es halbwegs verständlich rüber gebracht.
Ziemlich genau das glaube ich hatten wir Teamintern schon mal so festgehalten.
Ich als Entwicklungsfremder hab da keine Ahnung, aber das macht wohl wahnsinnig viel Arbeit und ist eine größere Geschichte, Darum steht das - wie vieles andere - eben auf der Warteliste.
Das Problem ist dabei nicht nur das neu zu entwickeln, sondern ggf, auch den Bestand anzupassen.
Wie auch immer, spannendes Projekt das vielleicht mal umgesetzt wird. Kommt eben auf die Entwickler an, aber es wäre schon schön sich da deutlich abzuheben
Ich als Entwicklungsfremder hab da keine Ahnung, aber das macht wohl wahnsinnig viel Arbeit und ist eine größere Geschichte, Darum steht das - wie vieles andere - eben auf der Warteliste.
Das Problem ist dabei nicht nur das neu zu entwickeln, sondern ggf, auch den Bestand anzupassen.
Wie auch immer, spannendes Projekt das vielleicht mal umgesetzt wird. Kommt eben auf die Entwickler an, aber es wäre schon schön sich da deutlich abzuheben
[url=http://www.opencaching.de/viewprofile.php?userid=152708][img]http://www.opencaching.de/statpics/DE/152708.jpg[/img][/url]
-
Bananeweizen
- Nano
- Beiträge: 97
- Registriert: 18.02.2013, 13:18
Danach würde kein GPS-Gerät mehr funktionieren, weil die nun mal alle darauf ausgelegt sind, Caches anhand des Typs zu unterscheiden (und der steht in der GPX-Datei nun mal woanders als die Attribute). Und OC hat auch nicht die Marktmacht, das zu ändern.
@Marschkompasszahl: Deine Frage ist viel zu offen gestellt, sowas solltest du vermeiden, da das immer zu "Wünsch dir was" interpretiert wird. Ist zumindest meine Erfahrung aus c:geo.
@Saxe-DD-WXD: Wenn das jetzt ein Feature-Request bei einem meiner Projekte wäre, würde ich darauf antworten, dass bitte _das Problem_ beschrieben werden soll, und nicht _die vorgestellte Lösung_. Denn Anwender kommen sehr häufig auf spezialisierte "Lösungen", die sehr viel Aufwand bedeuten, ein ähnliches Problem nicht lösen und für viele andere Anwender nicht verwendbar sind. Also daher nochmal die Frage: Was ist für dich _das Problem_ mit den vielen Cachetypen? Ist dir das Erstellen eines Listings zu kompliziert?
@Marschkompasszahl: Deine Frage ist viel zu offen gestellt, sowas solltest du vermeiden, da das immer zu "Wünsch dir was" interpretiert wird. Ist zumindest meine Erfahrung aus c:geo.
@Saxe-DD-WXD: Wenn das jetzt ein Feature-Request bei einem meiner Projekte wäre, würde ich darauf antworten, dass bitte _das Problem_ beschrieben werden soll, und nicht _die vorgestellte Lösung_. Denn Anwender kommen sehr häufig auf spezialisierte "Lösungen", die sehr viel Aufwand bedeuten, ein ähnliches Problem nicht lösen und für viele andere Anwender nicht verwendbar sind. Also daher nochmal die Frage: Was ist für dich _das Problem_ mit den vielen Cachetypen? Ist dir das Erstellen eines Listings zu kompliziert?
-
Schrottie
Wir hatten das schon öfter im Gespräch, wobei wir neben Tradi und Multi auch das Event im Auge hatten. Ich persönlich finde das sehr charmant, den tatsächlich ist eine Kombination aus sinnvoll gesetzten Attributen, korrekten Werten für Schwierigkeit und Gelände sowie der Größenangabe vollkommen ausreichend.
Allerdings muss ich auch Bananeweizen recht geben, denn der Kompatibilitätseinwand ist nicht von der Hand zu weisen. Den Benutzern das Eindamfen der Cachetypen zu "verkaufen" ist das eine und wird nicht überall auf Gegenliebe stoßen, aber wenn das GPS nicht mehr wie gewohnt verwendet werden kann, dann rennen die Benutzer in Scharen weg. Zumndest die, die bisher primär GC benutzen. Reinen OC-Nutzern wird das nichts ausmachen, die nehmen in aller Regel ohnehin eine Vorsortierung über die Suche vor und laden Caches nur gezielt auf das GPS. Aber eben den anderen. Und die Typenbestimmung über Attribute im GPX auszugeben, so dass es zu keinen Irritationen bei GPS-Geräten kommt, ist nur in sehr engen Grenzen machbar. Und im nächsten Schritt muss Software wie GSAK bedacht werden. Allein jetzt müssen schon die IDs der Attribute die auch bei GC.com existieren auf eben deren IDs umgesetzt werden, was dann für alle anderen ebenfalls bedeutet, das sie im GPX eine andere ID erhalten müssen um Überschneidungen zu vermeiden. Eine komplette Typendarstellung über Attribute würde dann zusätzliche Probleme allein in diesem Bereich bringen.
Kritisch wäre das auch für all diejenigen, die doppelt listen. Man darf bnicht vergessen, die Doppellistings machen einen nicht unerheblichen Anteil der Caches auf OC aus und hier durch ein eigenes Typsystem Hürden einzubauen wäre eher kontraproduktiv. (Dieser Einwand wird natürlich hinfällig, sobald die Anzahl der OConly die der Doppellistings übersteigt, aber ich denke mal wir sind uns alle einig, das dies nur mittel- bis langfristig geschehen kann und nicht von jetzt auf gleich. Immerhin müssen da noch viele Werbetrommeln gerührt werden.)
Aber bei allen Problemen die so etwas bringt, bei mir rennt man mit einer solchen Vereinfachung trotzdem offene Türen ein. Allerdings nicht, weil ich im bisherigen System ein Problem sehe, sondern weil "einfach einfach einfach ist". Und weil ein eigenes System der Cachetypisierung auch ein Alleinstellungsmerkmal für die Plattform sein kann.
Allerdings muss ich auch Bananeweizen recht geben, denn der Kompatibilitätseinwand ist nicht von der Hand zu weisen. Den Benutzern das Eindamfen der Cachetypen zu "verkaufen" ist das eine und wird nicht überall auf Gegenliebe stoßen, aber wenn das GPS nicht mehr wie gewohnt verwendet werden kann, dann rennen die Benutzer in Scharen weg. Zumndest die, die bisher primär GC benutzen. Reinen OC-Nutzern wird das nichts ausmachen, die nehmen in aller Regel ohnehin eine Vorsortierung über die Suche vor und laden Caches nur gezielt auf das GPS. Aber eben den anderen. Und die Typenbestimmung über Attribute im GPX auszugeben, so dass es zu keinen Irritationen bei GPS-Geräten kommt, ist nur in sehr engen Grenzen machbar. Und im nächsten Schritt muss Software wie GSAK bedacht werden. Allein jetzt müssen schon die IDs der Attribute die auch bei GC.com existieren auf eben deren IDs umgesetzt werden, was dann für alle anderen ebenfalls bedeutet, das sie im GPX eine andere ID erhalten müssen um Überschneidungen zu vermeiden. Eine komplette Typendarstellung über Attribute würde dann zusätzliche Probleme allein in diesem Bereich bringen.
Kritisch wäre das auch für all diejenigen, die doppelt listen. Man darf bnicht vergessen, die Doppellistings machen einen nicht unerheblichen Anteil der Caches auf OC aus und hier durch ein eigenes Typsystem Hürden einzubauen wäre eher kontraproduktiv. (Dieser Einwand wird natürlich hinfällig, sobald die Anzahl der OConly die der Doppellistings übersteigt, aber ich denke mal wir sind uns alle einig, das dies nur mittel- bis langfristig geschehen kann und nicht von jetzt auf gleich. Immerhin müssen da noch viele Werbetrommeln gerührt werden.)
Aber bei allen Problemen die so etwas bringt, bei mir rennt man mit einer solchen Vereinfachung trotzdem offene Türen ein. Allerdings nicht, weil ich im bisherigen System ein Problem sehe, sondern weil "einfach einfach einfach ist".
Und weil ein eigenes System der Cachetypisierung auch ein Alleinstellungsmerkmal für die Plattform sein kann.-
Schrottie
Ach, ich vergaß noch eines: Eines der möglichen Hauptprobleme können auch die Owner werden. Viele haben schon heute Stress damit, den korrekten Typ und ein paar Attribute zu setzen. Wenn aber von deren Korrektheit deutlich mehr abhängt als heute, dann ist das schnell ein ganz ernsthaftes Problem.
-
Steingesicht
Ich muss da Bananenweizen recht geben. Wenn wir die Typen und Attribute überarbeiten wollen (und auch ich sehe da Bedarf) sollte zuerst das Problem beschrieben werden, bevor es an die Lösung geht - also zuerst die Frage, _dann_ die Antwort. Vielleicht gibt das dann auch einen ganz anderen Blick auf die Probleme und wir erkennen ob wir nicht u.U. aneinandervorbeischwätzen.
Ich mach mal den Anfang:
Für mich stellt sich das Problem, dass es Caches gibt, die nicht eindeutig einem Typ zuzuordnen sind, sondern Elemente aus verschiedenen Typen enthalten. Um mal ein klassisches Beispiel zu nennen: Ein Cache mit mehreren Sationen bei denen vor Ort gerätselt werden muss. Prinzipiell könnte man sagen, dass der Ersteller entscheiden muss, was der führende Cachetyp sein soll: Rätsel oder Multi - aber trotzdem wäre es gut, wenn beide Typen dem Listing als Eigenschaft zuweisen könnte.
Ich habe da auch eine Idee, wie man das auch mit dem bestehenden System der Typen machen könnte - aber ich versuche mich da erstmal zurückzuhalten, bis wir das Problem zusammen beschrieben haben.
Ich mach mal den Anfang:
Für mich stellt sich das Problem, dass es Caches gibt, die nicht eindeutig einem Typ zuzuordnen sind, sondern Elemente aus verschiedenen Typen enthalten. Um mal ein klassisches Beispiel zu nennen: Ein Cache mit mehreren Sationen bei denen vor Ort gerätselt werden muss. Prinzipiell könnte man sagen, dass der Ersteller entscheiden muss, was der führende Cachetyp sein soll: Rätsel oder Multi - aber trotzdem wäre es gut, wenn beide Typen dem Listing als Eigenschaft zuweisen könnte.
Ich habe da auch eine Idee, wie man das auch mit dem bestehenden System der Typen machen könnte - aber ich versuche mich da erstmal zurückzuhalten, bis wir das Problem zusammen beschrieben haben.
-
Marschkompasszahl
[quote="Bananeweizen"]@Marschkompasszahl: Deine Frage ist viel zu offen gestellt, sowas solltest du vermeiden, da das immer zu "Wünsch dir was" interpretiert wird. Ist zumindest meine Erfahrung aus c:geo.[/quote]
Schon klar. Aber ich habe ja auch nur den Teil von Saxe-DD-WXD aufgegriffen, der bisher auch nicht näher formuliert war.
Grundstäzlich denke ich auch, dass 3 Grundtypen reichen würden:
+ Tradi (1 Station)
+ Multi (mehrere Stationen)
+ Event
und alles andere (Drive-In, Mystery, usw.) durch Attribute gesetzt werden könnte.
Allerdings sehe ich dort vornehmlich das Problem der Schnittstellen (ob GPSr oder App).
Darum würde ich die bisherigen Cachegrundarten dann doch eher an den Marktführer angleichen:
+Tradi
+ Multi
+ Event
+ Mystery
+ Letterbox Hybrid
+ CITO
+ EarthCache
+ Wherigo
+ Virtual
+Webcam
Die reinen G$-Typen CITO und EC dürften wohl zu vernachlässigen sein; die ehemaligen und nicht mehr verwendeten Typen Virtual und Webcam sollten natürlich weiter verwendet werden, wobei man die Webcam noch als Virtual mit Attribut einstufen könnte. Letterbox und Wherigo sind vornehmlich Multis und könnten über ein Attribut abgegrenzt werden.
Verzichten würde ich auf die OC-Typen:
- Drive-In-Cache => zum Tradi mit Attribut machen
- Mathe/Physik-Cache => zum Mystery (ggf. mit Attribut) machen
- Unknown (ist der relevant? )
Schon klar. Aber ich habe ja auch nur den Teil von Saxe-DD-WXD aufgegriffen, der bisher auch nicht näher formuliert war.
Grundstäzlich denke ich auch, dass 3 Grundtypen reichen würden:
+ Tradi (1 Station)
+ Multi (mehrere Stationen)
+ Event
und alles andere (Drive-In, Mystery, usw.) durch Attribute gesetzt werden könnte.
Allerdings sehe ich dort vornehmlich das Problem der Schnittstellen (ob GPSr oder App).
Darum würde ich die bisherigen Cachegrundarten dann doch eher an den Marktführer angleichen:
+Tradi
+ Multi
+ Event
+ Mystery
+ Letterbox Hybrid
+ CITO
+ EarthCache
+ Wherigo
+ Virtual
+Webcam
Die reinen G$-Typen CITO und EC dürften wohl zu vernachlässigen sein; die ehemaligen und nicht mehr verwendeten Typen Virtual und Webcam sollten natürlich weiter verwendet werden, wobei man die Webcam noch als Virtual mit Attribut einstufen könnte. Letterbox und Wherigo sind vornehmlich Multis und könnten über ein Attribut abgegrenzt werden.
Verzichten würde ich auf die OC-Typen:
- Drive-In-Cache => zum Tradi mit Attribut machen
- Mathe/Physik-Cache => zum Mystery (ggf. mit Attribut) machen
- Unknown (ist der relevant? )
-
Saxe-DD-WXD
Dann beschreibe ich mal das Problem aus meiner Sicht.
Das bestehende System finde ich für veraltet. Immer überlegt man neue Cacharten einzuführen, siehe die Safari-Caches. Die gibt es auch nur auf OC. Eigentlich sind sie aber eine Art Virtual. Dann versucht man ein paar Richtlinien für die neue Cacheart zusammen zu stellen. Immer mehr Cachearten, immer unübersichtlicher wird das Erstellen. Was will ich für einen Cache machen? In welche Art passt er am Besten? Das sind Sachen die ich mit Attributen umgehen kann. Eben, wie Schrottie sagt, einfach einfach.
Cache erstellen -> eine oder mehrere Stationen? -> Dose ja/nein usw. Alles schön nacheinander. Zum Schluss kommt vielleicht ein Cache raus, der mit den jetzigen Arten nicht möglich wäre.
Zu den GPX. Die Cachearten kann man intern vergeben. Attribut Cache mit einer Station und Dose wird zum Tradi, Attribut Cache mit mehreren Stationen und Dose wird zum Multi. Dann noch die ohne Dose zu Virtuals und die mit Rätsel zu Mysterie machen und dann passt das. Für die GPSr reicht das.
Die Events würde ich in einer extra Kategorie lassen, da sie immer nur an einem bestimmten Termin stattfinden. Nach dem Termin können diese automatisch archiviert werden.
Ich habe nie behaubtet, das es eine kleine Baustelle ist. Doch, so wie ich es verstanden habe, soll doch die Bedienbarkeit der Seite verbessert werden,. Was durchaus ja ein langfristiger Plan ist.
Doppellistings gehen dann erst einmal nicht mehr so einfach per C&P. Meine Meinung dahingehend ist aber, mit der Einfachheit der Cacherstellung auf OC die OConlys zu fördern. Bis die entsprechenden Macros angepasst sind.
Und zum Markt verändern. Welche Funktionen sind vom Großen Onkel denn von OC schon übernommen worden, die bei OC zuerst da waren?
Es muss nicht immer ein Problem vorhanden sein, um Innovationen einzuführen.
Das bestehende System finde ich für veraltet. Immer überlegt man neue Cacharten einzuführen, siehe die Safari-Caches. Die gibt es auch nur auf OC. Eigentlich sind sie aber eine Art Virtual. Dann versucht man ein paar Richtlinien für die neue Cacheart zusammen zu stellen. Immer mehr Cachearten, immer unübersichtlicher wird das Erstellen. Was will ich für einen Cache machen? In welche Art passt er am Besten? Das sind Sachen die ich mit Attributen umgehen kann. Eben, wie Schrottie sagt, einfach einfach.
Cache erstellen -> eine oder mehrere Stationen? -> Dose ja/nein usw. Alles schön nacheinander. Zum Schluss kommt vielleicht ein Cache raus, der mit den jetzigen Arten nicht möglich wäre.
Zu den GPX. Die Cachearten kann man intern vergeben. Attribut Cache mit einer Station und Dose wird zum Tradi, Attribut Cache mit mehreren Stationen und Dose wird zum Multi. Dann noch die ohne Dose zu Virtuals und die mit Rätsel zu Mysterie machen und dann passt das. Für die GPSr reicht das.
Die Events würde ich in einer extra Kategorie lassen, da sie immer nur an einem bestimmten Termin stattfinden. Nach dem Termin können diese automatisch archiviert werden.
Ich habe nie behaubtet, das es eine kleine Baustelle ist. Doch, so wie ich es verstanden habe, soll doch die Bedienbarkeit der Seite verbessert werden,. Was durchaus ja ein langfristiger Plan ist.
Doppellistings gehen dann erst einmal nicht mehr so einfach per C&P. Meine Meinung dahingehend ist aber, mit der Einfachheit der Cacherstellung auf OC die OConlys zu fördern. Bis die entsprechenden Macros angepasst sind.
Und zum Markt verändern. Welche Funktionen sind vom Großen Onkel denn von OC schon übernommen worden, die bei OC zuerst da waren?
Es muss nicht immer ein Problem vorhanden sein, um Innovationen einzuführen.
-
Schrottie
[quote="Saxe-DD-WXD"]
Das bestehende System finde ich für veraltet. Immer überlegt man neue Cacharten einzuführen, siehe die Safari-Caches. Die gibt es auch nur auf OC. Eigentlich sind sie aber eine Art Virtual.
[/quote]
Sie sind nicht nur "eigentlich eine Art Virtual", es sind lupenreine Virtuals. Nur haben sie ein eigenes Attribut. Somit ist hier im Grunde der Ansatz, den Cachetyp über Attribute zu definieren, bereits umgesetzt.
[quote="Saxe-DD-WXD"]
Und zum Markt verändern. Welche Funktionen sind vom Großen Onkel denn von OC schon übernommen worden, die bei OC zuerst da waren?
[/quote]
Die blauen Schleifchen. Die hat GC.com direkt von uns kopiert, inkl. der Begrenzung auf 1 Empfehlung pro 10 Logs. Nur das anstelle des Sternchens eben die Schleife genommen und das alles als Premiumfunktion umgesetzt wurde.
Das bestehende System finde ich für veraltet. Immer überlegt man neue Cacharten einzuführen, siehe die Safari-Caches. Die gibt es auch nur auf OC. Eigentlich sind sie aber eine Art Virtual.
[/quote]
Sie sind nicht nur "eigentlich eine Art Virtual", es sind lupenreine Virtuals. Nur haben sie ein eigenes Attribut. Somit ist hier im Grunde der Ansatz, den Cachetyp über Attribute zu definieren, bereits umgesetzt.
[quote="Saxe-DD-WXD"]
Und zum Markt verändern. Welche Funktionen sind vom Großen Onkel denn von OC schon übernommen worden, die bei OC zuerst da waren?
[/quote]
Die blauen Schleifchen. Die hat GC.com direkt von uns kopiert, inkl. der Begrenzung auf 1 Empfehlung pro 10 Logs. Nur das anstelle des Sternchens eben die Schleife genommen und das alles als Premiumfunktion umgesetzt wurde.
Zuletzt geändert von Schrottie am 28.01.2014, 12:22, insgesamt 1-mal geändert.
-
Marschkompasszahl
[quote="Saxe-DD-WXD"]Immer mehr Cachearten, immer unübersichtlicher wird das Erstellen. Was will ich für einen Cache machen? In welche Art passt er am Besten? Das sind Sachen die ich mit Attributen umgehen kann. [/quote]
Eben. Nehmen wir mal als mögliches Novum die [url=http://deaddrops.com/de/]Dead Drops[/url]. Kann man als Tradi oder Mystery einsetzen.
Widerspricht den Guidelines bei GC.com, nicht aber den Regeln bei OC.
Schickes Icon mit USB-Stick und schon gibt es die Cache-Variante per Datenaustausch zu loggen - ohne physisches Logbuch.
Und wenn es in zehn Jahren keine USB-Sticks mehr gibt und an jeder Straßenecke auf Clouds und Netzwerke zugegriffen werden kann, dann eben ein neues Icon für die neue Logmöglichkeit. Oder aber man wählt gleich "Speichermedium" (z.B. Diskette) als Symbol für speicherbare Logs im Felde.
Und selbst "CITOs" könnte man als Event mit Attribut umsetzen. Oder einen Wherigo (warum nicht die bayerische Version "Wo-i-geh"?) ähnlich.
Oder warum nicht "EarthCaches" als "Naturdenkmal" bezeichnen?
Ich finde, da sind wir ziemlich flexibel.
Eben. Nehmen wir mal als mögliches Novum die [url=http://deaddrops.com/de/]Dead Drops[/url]. Kann man als Tradi oder Mystery einsetzen.
Widerspricht den Guidelines bei GC.com, nicht aber den Regeln bei OC.
Schickes Icon mit USB-Stick und schon gibt es die Cache-Variante per Datenaustausch zu loggen - ohne physisches Logbuch.
Und wenn es in zehn Jahren keine USB-Sticks mehr gibt und an jeder Straßenecke auf Clouds und Netzwerke zugegriffen werden kann, dann eben ein neues Icon für die neue Logmöglichkeit. Oder aber man wählt gleich "Speichermedium" (z.B. Diskette) als Symbol für speicherbare Logs im Felde.
Und selbst "CITOs" könnte man als Event mit Attribut umsetzen. Oder einen Wherigo (warum nicht die bayerische Version "Wo-i-geh"?) ähnlich.
Oder warum nicht "EarthCaches" als "Naturdenkmal" bezeichnen?
Ich finde, da sind wir ziemlich flexibel.
-
Steingesicht
[quote="Schrottie"]Die blauen Schleifchen. Die hat GC.com direkt von uns kopiert, inkl. der Begrenzung auf 1 Empfehlung pro 10 Logs. Nur das anstelle des Sternchens eben die Schleife genommen und das alles als Premiumfunktion umgesetzt wurde.[/quote]
Das ist bei OC.de doch auch eine Premium-Funktion
Das ist bei OC.de doch auch eine Premium-Funktion