[Search Map] More display options for search results#2855
Conversation
|
Zwei kleine Korrekturen:
|
2Abendsegler
left a comment
There was a problem hiding this comment.
Hm ... ich habe hier leider ein paar Bedenken, das so umzusetzen.
Dieser neue Button auf der Karte soll zusätzliche Features beinhalten, die auf der Webseite nicht vorhanden sind. Die Features gefundene oder eigene Caches oder Caches nach Cache Typen zu filtern gibt es aber bereits im Filter der Webseite. Und ich sehe beim GClh Filter auch nur einen winzigen Vorteil gegenüber dem Filter der Webseite. Wir sind damit etwas schneller, weil die anzuzeigenden Caches nicht neu geladen werden müssen. Dafür ist das aber sicherlich für viele Benutzer ziemlich verwirrend. Ich war auch zuerst mal verwirrt, weil einige GClh Filter nicht funktioniert haben.
Es funktioniert nicht durchgängig, weil man nun an zwei Stellen die gleichen Filter setzen kann, ohne dass eine gemachte Einstellung an der anderen Stelle auch geändert wird. Beispielsweise werden die gefundenen Caches über den GClh Filter nur dann tatsächlich aktiviert, wenn sie im Filter der Webseite zuvor auch aktiviert waren. Und wenn ich in den Filter der Webseite hineingehe, können dort ganz andere Filtereinstellungen stehen als im GClh Filter. Beispielsweise könnte ich den Filter der Webseite aufrufen, um die Anzeige der gefundenen Caches zu aktivieren, weil sie im Moment auf der Karte nicht angezeigt werden. Im Filter der Webseite stelle ich dann aber fest, dass sie dort doch schon aktiviert sind.
Ich glaube du hast auch einige Programmstellen geändert, die wir nicht mehr einfach so ändern wollen. Beispielsweise sollten die Namen von Parametern und auch deren Bezeichnung nicht mehr geändert werden, nur weil man mittlerweile eine andere Schreibweise besser findet. Ansonsten gehen Einstellungen zu den Parametern verloren und im Changelog findet man nicht genau das, was man auf dem eigenen Bildschirm sieht.
Das Ausblenden der Past Events scheint zu funktionieren, habe ich aber nur kurz angetestet.
Prinzipiell sehe ich das schon als neues Feature. In der Search Map findet ebenfalls eine Suchabfrage am Server statt. Im Unterschied zur Browse Map kann die Suchabfrage in der Search Map aber bereits gefiltert sein.
Da hast du Recht. Das war letztendlich auch der Grund für den Tooltip-Button im Dialog, der genau dieses Thema versucht zu erläutern. Meine subjektive Erfahrung aus den Tests: Hat man erst einmal den Unterschied zwischen Such- und Anzeigefiltern verinnerlicht, dann verzichtet man auf die Suchfilter und verwendet fast ausschließlich die neuen Anzeigefilter - spart Klicks und aktualisiert bedeutend schneller.
Auch das ist ein valider Punkt.
Da stimme ich prinzipiell zu. Für jede der neuen Optionen müssen gewisse Teile des Codes dupliziert und nur geringfügig angepasst werden. Viel besser ist es, diese Codeteile in einer Schleife mit Variablenersetzungen zu verarbeiten. Da bei der Erstellung dieses PR die neue Version mit den letzten Änderungen noch nicht veröffentlicht war, schien diese Anpassung akzeptabel zu sein.
Sehr gut. Auch wenn mir die neuen Optionen gut gefallen würden, kann ich deine Bedenken nachvollziehen. Die Past Events könnten wir auf jeden Fall als dritte Option in den Anzeigeoptionen der aktuellen Release aufnehmen, das sind nur wenige Zeilen Code. Jetzt habe ich wieder ziemlich viel geschrieben, aber kürzer ging es irgendwie nicht ... |
|
Danke für deine ausführliche Antwort, das ist schon ok, dann kann man sich häufig ein besseres Bild machen.
Nein, das Fass wollen wir nicht aufmachen. So war das auch nicht gemeint von mir. Ich wollte nur beispielhaft schildern wie es jemandem ergehen kann.
Ja, da hast du schon recht.
Ich bezweifle tatsächlich, dass nahezu die gesamte Kundschaft diese Abgrenzung versteht. Und nichts ist blöder, wenn es dann per stille Post heißt "da funktioniert ja gar nichts".
Du hast ja recht. Ich hatte die Screenshots fürs Changelog schon gemacht, aber die hätte ich auch nochmal machen können, musste ich letztlich sowieso. Ich versuche halt meinen Aufwand und meinen Testaufwand möglichst gering zu halten. Sobald an bestehendem Code wieder Änderungen vorgenommen werden, muss ich das wieder testen, so meine Regel. Und die Umgebung in der Search Map ist eben auch furchtbar anfällig, wie wir mittlerweile ja wissen. Da kann ich das mit dem Testen nicht einfach etwas lockerer sehen.
Es ist unschön, dass du schon so viel Arbeit reingesteckt hast und wir es womöglich nicht einbauen können. Vielleicht sollte man in Zukunft zumindest bei größeren Arbeiten das Thema zuerst mal zur Diskussion stellen, eben als Feature Request. Die Past Events werden wir auf jeden Fall einbauen. Weiter weiß ich gerade nicht so recht was wir machen sollen. Ich werde mir das noch etwas durch den Kopf gehen lassen. Was mir spontan schon mal eingefallen/aufgefallen ist. Ich schreibe die Punkte einfach mal runter. Noch nicht umsetzen, ich will nur dass sie irgendwo stehen. Das sollten alles machbare Dinge sein.
|
Zwei weitere Punkte, die es vielleicht etwas klarer machen könnten: |
|
Um deine Überlegungen abzukürzen: mir ist (leider) eben ein KO-Kriterium begegnet: Angenommen, Mysteries sind über die Anzeigeoptionen ausgeblendet. Dafür sehe ich keine Lösung und ein solches Szenario ist für die Anwender nicht auflösbar. |
|
Das ist sehr schade, ich fände die Funktion echt klasse. Eine Überlegung von mir war, ob man die Filter nicht einfach aus den Filtern von GS entfernen könnte, dann gäbe es keine doppelten mehr. Aber leider werden gefunden Cache ja standardmäßig nicht geladen, und so würde der Filter keine Wirkung haben :/ Evtl. finden wir ja irgendwann später eine sinnvolle Lösung. |
|
Ich hatte mich auch bereits damit angefreundet. Ich habe zwei Punkte:
Das ist bei mir nicht so. Der Button wird deaktiviert. Die Anzeigefilterung bleibt aber bestehen. Im beschriebenen Fall würden also keine Caches der BML angezeigt.
Ich würde spontan sagen, dass wir beim Betätigen des Search Buttons eine neue Suche durchführen könnten. Eigentlich ist es doch sowieso nicht richtig, dass beim Wechsel von BML zum Search Button die Caches aus der BML weiter angezeigt werden. Also zumindest wenn wir eine automatische Suche eingestellt haben. Wir könnten das aber auch grundsätzlich so machen. |
Hm, so sollte das nicht funktionieren. Die eigentliche Filterung der Anzeige findet in
Leider würde das nicht in jedem Fall helfen. Was vielleicht funktionieren könnte: kommt man von der Anzeige einer BML zurück in den Suchbereich, dann werden alle noch gesetzten Anzeigefilter zurückgesetzt. Alternativ könnte man auch darüber nachdenken:
Nachteile:
Jetzt, beim aufschreiben, erscheint mir das fast die beste Lösung zu sein ... |
Ich habe die Mystery Caches ausgeblendet. Wenn ich den Link anwähle, dann werden keine Caches angezeigt und der Button ist auch nicht deaktiviert. |
|
Hoppla, da war noch ein Commit, den ich übersehen und noch nicht hochgeladen hatte - Sorry für die Verwirrung. Jetzt sollte es aber klappen. |
|
Ja, die Caches werden jetzt bei den BML angezeigt, egal wie die Anzeigeoptionen gerade stehen, super. Also wieder zurück zum eigentlichen Problem. |
Dubios, du hast aber gesehen, dass es bei mir durchaus funktioniert, siehe hier? |
|
Bei dir läuft das etwas anders ab. Wenn du auf "My Lists" klickst, dann wird bei dir scheinbar sofort eine bestimmte BML angezeigt. Das verstehe ich nicht. Wenn ich das mache, komme ich immer zuerst in die Liste der BML und muss dort erst eine BML auswählen. Genau das könnte den Unterschied machen, warum es bei mir funktioniert und bei dir nicht. |
Ja, das funktioniert bei dir deshalb, weil in dem Kartenausschnitt, den die BML vorgibt, für die Suche noch andere Caches vorhanden sind. Die werden dann, wenn nicht gefiltert angezeigt. Bei der von mir verlinkten BML ist das nicht so, von daher keine sichtbaren Treffer. Das zeigt eben, dass es nicht in allen Fällen funktionieren wird. |
Ich mache das doch genauso. In dem GIF ist der Teil der Auswahl der BML lediglich rausgeschnitten (die BML sind nicht öffentlich), das ist alles. |
|
Verstehe nun beide Sachverhalte, danke. (Ich mach nur weiter Brainstorming.) |
Leider auch nicht, da der Zoom-Parameter bei der Suche nicht berücksichtigt wird. Mit den letzten Ideen denke ich aber, eine besseres Konzept für die neuen Anzeigeoptionen gefunden zu haben:
Vorteile:
Nachteile:
Die Umsetzung dieser Punkte würde tatsächlich nur wenige Änderungen im Code bedeuten. :) Wäre das eine akzeptable Lösung? |
|
Ja, ich glaube das ist eine gute Lösung. Prima. Ich würde "Show finds at corrected coordinates" wegen der Einheitlichkeit ebenfalls nicht sessionübergreifend machen. Ich bin aber auch anderenfalls damit einverstanden. |
|
Sehr gut! Dann werde ich den Code entsprechend ändern und den MR aktualisieren. |
|
Sieht cool aus und hört sich gut an. Habe nur eine Kleinigkeit im Moment. |
Den Gedanken hatte ich zunächst auch, das funktioniert leider bei den beiden Optionen nicht. Für die oberen Optionen korrespondiert die Opacity der Icons wunderbar damit, ob Caches ein- oder ausgeblendet sind. Für die beiden unteren Optionen hätte die Opacity der Icons hingegen eine andere Bedeutung: Option aktiviert oder deaktiviert, das könnte verwirren. Dafür ist die Checkbox besser geeignet und zusammen mit dem Icon, wie ich finde, gut verständlich. |
Ja, das stimmt. Die Kombination von Icon, Checkbox und Bezeichnung ist aus meiner Sicht ziemlich gewöhnungsbedürftig. Ich kenne das in dieser Form nicht für einen Parameter, das ist mir also so noch nie bewusst begegnet. Und das Icon erscheint auch nicht notwendig. Ich komme nochmal darauf zurück, dass wir uns das Leben auch schwer machen mit den Icons. Oben im Bereich von Show/Hide macht das alles Sinn, weil dort ausschließlich die Icons verwendet werden können und weil wir das auch sowieso ziemlich ähnlich aus der Browse Map kennen. Bei eigenen Parametern ist die Wahl eines geeigneten Icons hingegen schwierig und birgt sogar die Gefahr, dass man sich für das falsche Icon entscheidet, weil man zukünftige Anforderungen noch gar nicht kennt. Ich war bisher der Meinung, dass das derzeitig verwendete Icon für "Show finds at corrected coordinates" schon ok wäre. Genau genommen besagt das Icon aber gar nicht worum es geht. Aber wir haben auch gar kein Icon bei dem die Bedeutung die ist, das wir gefundene Caches, und auch nur genau die, an die korrigierten Koordinaten verschieben. Vor einiger Zeit hatte ich mir noch eine weitere Anforderung notiert. Dabei wird beklagt, dass der Cache Typ nicht mehr sichtbar ist, sobald man die Koordinaten geändert hat. Als Farbe wird in solchen Fällen wohl die Farbe des Cache Typs Mystery verwendet. Damit liegt man ja auch häufig richtig. Allerdings werden ja auch bei Multis, Letterboxen und anderen Caches Typen die Koordinaten geändert. Laut Anforderung möchte man die Farbe des jeweiligen Cache Typs sehen. Vermutlich wäre das bei unserem Parameter verwendete Icon hier dann auch besser aufgehoben. Eigentlich ist es aber so, dass ich mir darum gar keine Gedanken machen möchte, wenn wir ein neues Feature implementieren wollen. Bei dieser weiteren Anforderung und auch bei den beiden Parametern habe ich mir bereits viel zu viele Gedanken gemacht, um ein passendes Icon für die Features zu finden bzw. zu beurteilen, ob ein ausgewähltes Icon passend ist oder nicht. Ich möchte die Icons an dieser Stelle lieber weglassen. |
|
Mein Herz hängt nicht an den Icons, also weg damit. Die Grundidee war hier einfach, durch die Icons optisch schnell erfassen zu können, was die Option beeinflusst. Die kurzen Texte leisten das ja ebenfalls. |
|
Das Feature ist jetzt eine runde Sache und läuft problemlos. Eine Verbesserung habe ich noch eingebaut: Optionen, die von den Suchfiltern bereits ausgeschlossen sind, werden nun ausgeblendet (da sie wirkungslos wären und für Verwirrung sorgen könnten). Der Tooltip-Text ist auch noch etwas ausführlicher und sollte das Feature verständlich beschreiben. Der Code für den Aufbau des Dialogs war zwar sehr kompakt geschrieben, dadurch aber recht schwer verständlich. Kurzum: der Code ist fertig zum Testen! |
|
Zu 5. und 6. Wir müssen nicht alle Ideen realisieren, nur weil wir es theoretisch können. Manchmal kann man etwas auch einfach weglassen, weil es den Aufwand nicht lohnt. Das hier scheint genau so ein Fall zu sein. Lass die Funktionalität einfach weg und gut ist. Das Feature ist auch ohne eine super Sache. Bitte gib Bescheid, wenn ich nochmal testen kann. |
|
Guter Vorschlag. MR ist aktualisiert und der Code kann getestet werden. |
2Abendsegler
left a comment
There was a problem hiding this comment.
Sieht super aus und funktioniert klasse! Das können wir so mergen. Wenn du möchtest dann zieh noch die Commits gerade und gib Bescheid wenn ich mergen kann.
- hide by status: finds, owned, past events - hide by type: all available cache types - add "show cache type for DNFs" - layout in browse map style
9919ce9 to
16855c0
Compare
|
Alle Commits zusammengefasst, Code is ready to merge. |









More display options for search results on search map:
Layout of the options dialog is similar to the one in browse map: