Design guru? We need a file import UX that says DON'T PANIC

[Jason Gerard DeRose]

Tara (~frmdrt) is a professional photographer, and it was observing the many error-prone file management tasks that her software (Aperture) burdened her with that got me wanting something like dmedia. Professional photographers live in constant fear that they will accidentally lose or destroy, say, someone's wedding photos. We want dmedia (and Novacut and other apps built on dmedia) to inspire enough confidence that the user doesn't worry about these critical file management tasks.

Part of inspiring this confidence is having the dmedia backend robust and reliable. But equally important is getting the UX right. For professional users in particular, I think the UX needs to make the user feel confident that 1) dmedia wont even give them the opportunity to make stupid mistakes, 2) dmedia will do the right thing automatically without the user needing to intervene, 3) and dmedia will be honest and tell them when they *should* PANIC.

Although the dmedia backend will be just as appropriate for casual as for professional use, I have a strong hunch that the file import UX needs to be uniquely optimized for casual vs professional use because these two classes of users are actually doing something pretty different. For example, the typical pro user will 1) import from a card reader rather than by connecting a USB cable to their camera, 2) import several cards one after another in a batch, 3) have a much, much higher data volume. The pro use case is extremely repetitive, which is why it becomes error prone and stressful if you give the user the option to make stupid mistakes. What might be an acceptable mental workload for a task performed once per week can be totally unacceptable for a task performed dozens of times per day.

Here's a brain dump of things I've observed in Tara's pro workflow, with some of my own experiences tossed in:

1) Always de-duplicate (and the de-duplication must be flawlessly reliable). Whenever there is any doubt as to whether some files have already been imported, a pro user must be able to throw a card in and have it accurately find any new files. The pro user is horrified of manual de-duplication... never make them do it!

2) Always import all *new* files on the card... don't even give the user the option to import a subset, potentially skip files they actually want. Of course, some files will be rejected as unusable, but the import process is *never* the time to decide that. That should be decided only once the files are durably stored and you can change your mind.

3) Never make the user wait for thumbnails to be loaded before they can begin the import process. Obvious consequence of the above.

4) Don't require user intervention to begin the import process. Another consequence of (2). Perhaps the first time they import using dmedia, a confirmation dialog should appear to make it clear to them what's happening. This dialog should have an "Import automatically from now on" option that's checked by default. After that, there should be a NotifyOSD message telling the user that the import has started, another NotifyOSD to tell the user the import has completed. Of course, there should be a way to cancel the import (I like the idea of doing that through an application indicator). Automatically importing anytime a card is inserted - this is an area where I feel what's most appropriate for the casual vs professional user differs.

5) Import unobtrusively in the background without interrupting the user's current work. It's annoying to require an application to open just to do the import. And as dmedia is a cross-application media library that will be storing video, audio, and photos, there might not always been a single appropriate application to open anyway. If a dmedia-using application is open, the user should be able to continue to work... no one wants to sit and watch the import process.

6) If importing to a system with redundant storage (RAID1 or RAID10), format the card after the import has completed. Nothing is worse than trying to take a photo or some video and realizing your memory card is unexpectedly full. Then you have to 2nd guess yourself: is the card full because I forgot to format it after I imported, or is it full because I never imported these files? A core part of the dmedia design is that it tracks the "durability" the files (basically the number of copies) so that it knows when a file can be safely deleted from a specific device. This is one of the most stressful parts of the pro workflow and it will be a huge win if we can reduce the workload to: "If there are files on the card, then they haven't been imported"

7) When appropriate, tell the user to PANIC. When there are media files (original content captured by the user) for which only a single copy exists in the whole world, dmedia needs to indicate a state of PANIC. I would like an application indicator for long-running background processes, in particular for content-creation type stuff. Turning red like the reboot indicator would be a good idea. dmedia needs to do everything it can to resolve the state of PANIC without requiring user intervention (uploading to cloud storage, copying to removable media). Part of inspiring confidence is being forthright about when there is reason for concern, and this is pretty much the end-all be all concern for pro users.

Upon the recommendation by James Raymond (~animafreek), we're using google docs for doing quick mock-ups. Here is the doc for this feature: https://docs.google.com/a/novacut.com/drawings/edit?id=1GYuNMcuzLTOEMTAFwcQsXZszsbJoV3WI5SZAzKcb8ww&hl=en

Ping me on #novacut or ask in this bug if you would like write access to the doc.

[Tara Oldfield (frmdrt)]

When proof-reading this document for Jason, I started wildly nodding when I came to point number five. This somewhat involuntary response was triggered by memories of me dumping off memory cards from the last wedding that I shot. I wasted so much time just waiting for all 3500 photos to import; Aperture wouldn't even let me rate my photos and create sub-folders during the import process. If I could have rated and cropped photos during importing, I probably would have saved a good two hours. And time is of the essence when brides have internet access in their honeymoon suites; they are excited and want to see beautiful photos of themselves now not later.

The other point that I enthusiastically support has to do with file duplication. I'm quickly running out of space on my hard-drive; it's gotten so bad that I've started eliminating some of my HD movies that I purchased through i-tunes. So of course, it irks me when video and photo files end up duplicated; sometimes it takes me a while to realize duplication has happened (mainly because Aperture will separate duplicated files in the thumb-nail line-up) and that I need to do some trashing.

To sum up, a big thumbs up for points five and one from someone who usually works with thousands of photo files in one sitting.

[Jason Gerard DeRose (jderose)]

I'm digging something like this for the NotifyOSD when an import starts

notify-send "Searching for new files" "/media/EOS_DIGITAL" -i notification-device-usb

Tara like it too.

[Jason Gerard DeRose (jderose)]

By the way, to run the above notify-send command, you will need to install libnotify-bin:

sudo apt-get install libnotify-bin

[Jason Gerard DeRose (jderose)]

I wanted to clarify that this design bug is about the *import* process (importing newly captured files from CD/SD cards), not *migration* (importing an existing library into dmedia). These are quite different use cases because you will probably only perform a *migration* once, and it merits a lot of options and confirmation from the user at each step of the way. On the other hand, *imports* are that error-prone repetitive tasks that the pro user will do over and over again... the best UX is truly for them to occur with no user intervention at all.

I also wanted to provide a real life example to hopefully convince people that the low-volume casual use-case and the high-volume pro use case are quite different, merit a different UX.

Again, Tara (~frmdrt) provides my real-world use case. She shoots weddings in the photo-journalistic style (basically tries to capture candid moments, does more than just posed shots). In order to get enough good candids, you need to shoot an incredible amount of photos. For the last wedding she shot, it was her plus two assistant photographers (Jeff and I actually). And during the ceremony I shot video. By the time it was all done, there were 5 memory cards (2 x 16GB, 3 x 32GB) which were almost all full. There were over 4,000 RAW photos and around 60 1080p video clips.

A week of full on HDSLR movie or TV production will easily produce several *terabytes* of video. Can you image the poor schmuck that has to feed all those cards into a workstation over and over again? This is why we need an import process that requires no user intervention, is fool proof.

This is also a really cool opportunity for the freedesktop... no one currently has a good workflow for the pro file import process. We're not playing catch up here, we're setting the standard.

Making the UX right for importing multiple cards simultaneously is also important, a big opportunity. It's not just about trying to get the imports completed faster... more important is to interrupt said poor schmuck fewer times. Throw 4 cards into the card readers, do something else. Notice that *all* cards have completed, yank them out, throw 4 more cards into the readers.

[Jason Gerard DeRose (jderose)]

One more clarification. dmedia is appropriate for low-volume casual use as well, and I do care about those use cases. But I feel the freedesktop already handles those use cases very well, so I want focus on the place where I feel we can offer a decisive improvement... high-volume pro use.

There is always a chance that we will decide that the low-volume and high-volume UX should be exactly the same. But right now I want to focus on the high-volume use case without compromise, so we make sure to get it right.

I expect the pro vs casual UX to be at most subtly different, so we aren't going to be duplicating bunches of work. It's more an issue of appropriate default behavior.

[Jason Gerard DeRose (jderose)]

The prolific David Green strikes again!

Before I saw that you assigned this to yourself, I started this wiki page: https://wiki.ubuntu.com/AyatanaDmediaLovefest

[Jason Gerard DeRose (jderose)]

Just chatting with tonsofpcs in #novacut and he mentioned tracking the UUID of the cards, which can help us provide a workflow similar to many people are used to.

I've personally thought of tracking this for auditing and wear leveling, so kill 2 birds with one stone. Here's the explanation that tonsofpcs gave:

(08:54:56 PM) tonsofpcs: no, based on the reel you ened to know the reel
(08:55:12 PM) tonsofpcs: film guyss log while they shoot
(08:55:15 PM) tonsofpcs: in three places:
(08:55:17 PM) tonsofpcs: 1) Paper
(08:55:21 PM) tonsofpcs: 2) Video (slate)
(08:55:27 PM) tonsofpcs: 3) audio (read before clapping the slate)
(08:56:44 PM) tonsofpcs: the paper gets "reel" and "time" (or, for discrete files where you don't care how mmany feet into the film you are, "clip", often multiple times over due to multiple cameras at once, multiple audio recordings, etc.) and everything from the slate/audio
(08:57:25 PM) jderose: okay, i'm starting to get it...
(08:57:48 PM) tonsofpcs: the paper also gets notes on what happens (and often there are multiple paper logs with different notes, like a huge production would have someone doing continuity that will write "mike walks in from left out-of-frame")
(08:58:17 PM) jderose: okay, gotcha
(08:58:32 PM) tonsofpcs: the slate (both visual and aural) gets "Scene 7 Take A" or somesuch so that if the logging has issues, it can be found out later (this was more for the days when we didn't have isolated files so you could find the end points as you woulldn't load a new reel for every take)
(08:59:49 PM) tonsofpcs: the slate is also used for its most recognizable use -- a visual and aural 'clap' to synchronize the two tracks
(08:59:54 PM) tonsofpcs: (or more)
(09:00:33 PM) jderose: tonsofpcs: so we want to have novacut be able to drive production workflow... so you would pick the scene your working on (on a workstation, or phone or tablet or whatever)... you can see notes, add notes....
(09:01:39 PM) tonsofpcs: well, the film and video workflows are (usually) entirely different
(09:01:46 PM) jderose: after you finish so many takes, whenever a logical point is, you import the cards (while setup for next shot is ongoing)... this way someone can to rough edits right there so director and DP can review, see if they want to do anything again while it's still cheap and easy to do so
(09:01:52 PM) tonsofpcs: even if the media may be the same at this point, they're entirely different style
(09:02:41 PM) jderose: true, but i think we can caputure the tacking you want, and make it easy to associate the paper notes with the equivalent of the "real"
(09:03:22 PM) tonsofpcs: right, you just have to ask for the reel name/number on card insertion
(09:03:33 PM) tonsofpcs: yes, this requires a keyboard (maybe just a 10key).
(09:03:38 PM) tonsofpcs: (or a touch screen)

[Jason Gerard DeRose (jderose)]

Okay, this has been merged to trunk. There is still more work to do, but I'll open additional bugs for the remaining items.

[Timothy Kross (timkross)]

Fixed a typo in the description.