Version: 1.8.0 (using KDE 4.6.0) OS: Linux I currently support several hundred Linux users running KDE. These users have migrated from Windows on my recommendation, on the basis that Linux is more reliable, stable, and though not as familiar as Windows, ultimately more user-friendly. This has met with some success, however there are lingering issues. The number one application I get complaints and support calls about, is digiKam. Specifically, the downloading of photos from camera has been a sticking point for a large proportion of my users (greater than 50 percent in fact). I believe that this stems from the way digiKam handles album creation and photo selection at photo download time, and wish to suggest some changes that I believe would be both minor, and eliminate these difficulties. I emailed Gilles with my concerns. He seemed receptive, and suggested I create a bug report here. After spending a significant amount of time on training, I believe I have identified the key points at which users become confused and/or unable to progress through the import process. 1) Photo selection. Most of my users are unable to tell when a photo has been selected. They also do not understand the idea or mechanics of "group selection" using the keyboard. Suggested alternative: Photos should be automatically split into "events", displayed vertically/sequentially, with a single, large "collage" style icon, and the date the pictures were taken in plain language next to the image (eg Thursday, 25th August, 2011 - not 25/08/11). A large "Import photos from this event" button should be placed next to each event. 2) Album Creation. Most of my users are unable to understand how or why albums are created. When they do see the button to create an album, they accidentally create it as a sub-album of some other album, as the top level is not selected by default. They then usually claim their photos "are missing". Suggested alternative: Do not allow the creation of sub-albums during the import process. When a new album is to be created, prompt for an "Event Name", and place it alphabetically or chronologically in the main album listing. Sub-Albums could then be created later, but most users do not have the patience to organise their photos after import, so removing this step seems prudent. I hope this information is taken in the spirit intended. digiKam is definitely my photo management application of choice, but I feel that feature creep has perhaps removed some of the focus from ease of use in more recent releases. Please understand that if I could contribute with code I would do so, but feel that any code contribution I might make would be harmful to the stability of your software as my experience with C/C++ is limited. Thankyou. Reproducible: Always Expected Results: digiKam becomes easier to use.
Malvern, This file still valid using digiKam 2.4 ? Gilles Caulier
I'm afraid so Gilles. I have tested with Digikam 2.4.1. The addition of the "Download New" button is quite welcome, but the report is still well and truly valid. Events are not auto-split (nor is any demarcation shown between them), photo selection is still non-intuitive and album creation still, by default, can cause accidental sub-album creation.
I want to be able to create a sub-album during the import process, because i mostly store pictures by date and i don't know before importing which dates i have.
Pierre, that's fine, but by default when the user clicks "Create Album", digiKam creates a *sub-album* as the top level is *not* selected by default, which it should be.
Note : Since 2.3.0, i introduced a new Camera Import Setup dialog page where you can set a default DOWNLOAD album somewhere in your collections. You press download and that all, new items will be copied always at the same place. You manage it later from album view. Gilles Caulier
i must say that i have some difficulties to understand which directory is selected when you enter the 'import' screen. i was thinking it's random? perhaps the one which is selected in the album view? a problem i have since around one month is that when i create a (sub) album in import, before it was selected by defaut and now it's no longer the case (the parent stays selected). i think when you explicitly create a sub-album that's to use it immediatly...
Go to setup camera dialog page, there is a section where you can select default Download album. If this option is not set, album select dialog is started at download time... Gilles Caulier
Gilles, that option should be set by default if it's going to be useful, meaning digiKam will need to create some kind of "Unsorted" directory. However, I still maintain that events should be autosplit based on date, and an album name prompt displayed for each of them.
>However, I still maintain that events should be autosplit based on date, and an >album name prompt displayed for each of them. Just select right album auto creation in imaport windows setting sidebar. I you use default DOWNLOAD dir option, sub-album date based will be created at import. Gilles Caulier
Gilles, I've updated this bug to 2.5.0 as I am now testing against openSUSE's upcoming 12.2 release. Let me say that the actual importing process seems much improved, no longer locking Digikam's main window. Kudos! I have also played with your "default directory" option in conjunction with album auto creation. I was going to suggest this be the default but realise this would probably annoy most users, so I will ask instead... would it be too much, when creating an album, for the dialogue to simply automatically choose the highest level directory? This would avoid accidental creation of sub-albums, and it's such a minor change that would make such a big difference to workflow.
Islam Wazery is planed to work in-deep on digiKam Import tool, through Google Summer of Code 2012... It's not yet official, we need to wait final choice from Google for next Monday... If he is retained (as i hope, and as i want), we will work Islam and i on this report... Gilles Caulier
Sounds good Gilles. Looking forward to it. :)
Hi all, Gilles, it is really my pleasure to work on this :), Malvern I will take all of the info you supplied into consideration, also I will keep you updated and take all of your feedback.
Much appreciated Islam. Let me know if there is anything I can do to help during the process. As I said previously, I would offer to contribute code, but I fear the quality would be very poor.
Malvern, We will appreciate all checks, tests, report about new implementation, to see if all new features work fine and if no side effects have been introduced with new code. Gilles Caulier
Hi Malvern, It is now confirmed that I will work in the Import Interface in GSoC 2012, Please check the mockups for the new UX provided in my proposal page http://community.kde.org/Digikam/GSoC2012/CameraUserInterfaceRevamp and sure all of your feedback are welcome. Thanks Islam Wazery
Hi Islam, thanks for the link. The goal outline seems good. I have also looked at the mockups. I therefore have a couple of notes I hope are helpful: 1) If the import interface is going to switch to preview when a user double-clicks a photo, make sure that pressing escape takes you out of preview, and that while in preview mode, the left and right arrows on the keyboard move you through the photo strip above. Come to think of it, that would be helpful in the main interface as well... I've always had trouble getting out of preview mode, and being forced to use the mouse to navigate it is annoying. 2) Make sure you set a sensible default camera path. Typically I would expect this to be the same as the default album path displayed when the application is run the first time. That way, when the user selects "To New Album" it will, by default, be created under their top level album path. 3) If you're going to do video preview, make sure video playback is stable. Video codecs can still be an issue on Linux - even simple ones like MJPEG frequently cause crashes. You'll need to handle video playback crashes gracefully so that they don't crash digiKam and instead merely cease video playback (without locking the application). 4) If you are going to revamp the geolocation feature, please add an option to disable the damn thing or detect whether blue-marble is installed so it isn't listed as a dependency for digiKam. I hope this feedback is useful to you, and I will do my best to be communicative during development. Many thanks.
I notice this report has been updated to digiKam 3.0.0, but haven't noticed any changes at the link Islam posted above. Have I missed something? Is there any place I can view the changes and give feedback during the development process?
Thanks Malvern for your interest. In the link I posted, there are two sections in its end (TODO, and Completed) in them I describe the tasks I am currently doing and the ones I finished. All the code is in a separate feature branch (development/3.0.0), and now I am working on the views for the Import Interface. The last thing I want to say is that all your notes are taken into my considerations and I will message you if any help is needed, thanks again :)
Malvern, Do you tried last digiKam 4.2.0 ? It sound better for you ? Gilles Caulier
*** Bug 349979 has been marked as a duplicate of this bug. ***
This problem still reproducible using last DK 5.4.0 bundle ? https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWlRJenM Gilles Caulier