Bug 328855 - Manual geotagging is unintuitive or misleading
Summary: Manual geotagging is unintuitive or misleading
Status: RESOLVED DUPLICATE of bug 388219
Alias: None
Product: digikam
Classification: Applications
Component: Geolocation-Workflow (show other bugs)
Version: 5.4.0
Platform: Debian testing All
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-16 02:53 UTC by Philippe Cloutier
Modified: 2022-01-10 15:46 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Cloutier 2013-12-16 02:53:13 UTC
Digikam supports geolocation. In the ideal case, the device exporting photos already has the images geotagged.

When a photographer without a GPS device wants to use geolocation, manual geotagging needs to be done. I tested this use case today and had the impression I was using some advanced photography software for a while. The interface is highly unintuitive and even misleading, as reported in bug 275180. (However, FWIW, I use digikam about once every 2 years and do not master it at all)

The user trying to understand how geotagging works will likely try tagging a single photo to start. He will likely click the globe at the left, the globe at the top or the globe at the right. These are all useless for geotagging. The top one in particular got yours truly truly confused - having tried the 3, I ended up with 3 maps displayed, and not seeing how to "exit", I resorted to restarting Digikam to go back to the pictures list! The right panel is particularly confusing too. Rather than saying the image is not tagged, it suggests that geolocation is broken. The early stage of my confusion is pretty well explained in the question from John Stumbles: http://mail.kde.org/pipermail/digikam-users/2012-May/016195.html

At this point, I had installed documentation and found some documentation about sidebars, which didn't help. I went to Google and found http://scribblesandsnaps.com/2009/11/03/geotagging-photos-with-digikam/. Although the menus changed since then, I finally managed to reach the geotagging dialog. That wasn't the end of the story though...

In the dialog, I was able to move the map and "select" a location. But after applying the changes, nothing changed. The final enlightenment only came after more Googling and reading rawi's reply to the above digikam-users post. The whole process must have taken more than half an hour, for a seasoned KDE user. Finding http://userbase.kde.org/Digikam/Geotagging_in_digiKam_2.0 at the start would have helped.
-------------------------------

Lots of usability improvements to geolocation could be made. Bug 299827 requests an improvement specifically for bookmarks. My specific problem had 2 parts: reaching the geotagging interface and managing to use it. Bug 184833 has suggestions helping with the former. This ticket should deal more specifically with the latter.

The problem with the geotagging interface has 2 sides:
1) Nothing says how it should be used.
2) A couple of problems suggest the interface should be used in a way it cannot be used.
Because of 2), users are likely to conclude that geotagging is broken rather than trying to cope with 1). Therefore, the core of this ticket shall be 2).

All maps in Digikam (left pane, center, right pane and geotagging dialog) display a crosshair in the center. For the right pane, this crosshair is justified, helping to locate the precise location. For all other maps, this crosshair is misleading. This is particularly problematic in the geotagging dialog, as the user will naturally think the pointed location is the one he is selecting.

Secondly, the "Apply" button is always enabled. The user can therefore conclude that merely moving the crosshair at the desired location constituted a change which can be applied.

These 2 problems are truly misleading and should be fixed first.
------------------------------------

For completeness, I come back to the first side of the geotagging interface's problem. When you selected a single image, you may find it surprising that you have to effectively re-select which images you want to tag. Drag and drop is handy but not discoverable. There could be text explaining how to use. I think it is legitimate that the primary mouse button is dedicated to map navigation and cannot be used to locate a photo. However, the menu brought up with the secondary button could offer more than Copy coordinates. It could offer, say, directly setting these coordinates for all images, or for all selected images.

Finally, there should be a section dedicated to geotagging/geolocation in the handbook.

I did not notice much change on this between 3.5.0 and 4.0.0-beta1.
Comment 1 caulier.gilles 2016-12-01 10:08:59 UTC
Any feedback with current AppImage bundle for Linux ?

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 2 Philippe Cloutier 2016-12-04 17:03:02 UTC
Thanks Gilles.
I had not used Digikam since I filed this.

I tried an AppImage of 5.4.0 on Debian 8 but this seems mostly broken. On launch, I am prompted about the collection. Whether I choose to do nothing or to consider it as a mobile collection, there are discreet errors later if I try to show image previews. A tooltip reads "L'emplacement d'enregistrment[sic] de cette image n'est pas disponible actuellement".

I have tried using 2 maps anyway, but I am still far from having understood how manual geolocation should work.

I intend to retest this next time I upgrade my distribution (which will take several months), unless someone says I can test on Windows.
Comment 3 Maik Qualmann 2017-12-25 20:06:49 UTC
*** Bug 388219 has been marked as a duplicate of this bug. ***
Comment 4 Maik Qualmann 2017-12-25 20:07:40 UTC
*** Bug 388221 has been marked as a duplicate of this bug. ***
Comment 5 Maik Qualmann 2019-10-03 21:01:05 UTC
*** Bug 412578 has been marked as a duplicate of this bug. ***
Comment 6 caulier.gilles 2020-08-02 14:57:28 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 7 Philippe Cloutier 2020-08-02 21:29:35 UTC
Gilles, can you clarify which file you are referring to?
Comment 8 caulier.gilles 2020-08-02 21:32:58 UTC
This bugzilla entry in fact...
Comment 9 caulier.gilles 2022-01-09 04:41:19 UTC
Hi Philippe and happy new year,

Can you reproduce the problem with digiKam 7.5.0 pre-release AppImage bundle
for Linux available here :

https://files.kde.org/digikam/

Best regards

Gilles Caulier
Comment 10 Philippe Cloutier 2022-01-10 14:10:57 UTC
Thank you very much Gilles, happy new year to you too

Unfortunately I have not used digiKam in years, and I gave up on KDE software recently: https://www.philippecloutier.com/blogpost141-The-Epik-of-Konqi-s-Krazy-Army
I have no intention to use digiKam again and have no access to a recent desktop Linux install, so it would be costly for me to retest this.
I appreciate very much your efforts, but I unfortunately prefer to hereby orphan this ticket.
Comment 11 caulier.gilles 2022-01-10 15:46:32 UTC

*** This bug has been marked as a duplicate of bug 388219 ***