Ubuntu Wiki

Ayatana + dmedia == Lovefest

TV and movie production with HDSLR cameras produces two things: 1) super pretty moving pictures and 2) piles of memory cards that must be imported.

This import process is highly repetitive, time consuming, and error prone... like it's begging for opinionated design to come in and make life easier for creative professionals.

We believe that by leveraging technologies like NotifyOSD and Application Indicators, we can give the Distributed Media Library a file import UX that sets the benchmark the proprietary world must catch up to.

This is particularly exciting for the freedesktop because no one yet has a good solution to this problem, but clearly these cameras are the future. We're leading, not playing catchup.

Below is the design work-in-progress, but nothing is final and we're eager for help and guidance.

-- jderose 2010-11-28 12:10:50

Know thy user

This design exercise is focused solely on professional TV and movie production with HDSLR cameras. We will also develop an import UX appropriate for home users, but this design isn't it. This is about making a realistic professional production workflow as efficient and fool proof as possible, without compromise.

Here are some assumptions to help narrow the focus:

• We're on the production set of a TV show... people are busy, things are hectic, and wasted time carries a high price
• There's a dedicated workstation on-set used exclusively to dump cards onto
• Files are imported using USB card-readers, not by connecting a USB cable to the cameras
• There are two sets of memory cards and while one set is in use, the other set needs to be imported

• Importing is extremely repetitive... each set of cards might be imported a dozen times a day

• When memory cards are inserted, the user's intent is always to import all new files on the cards

• There is never variation in the import process, so any options are a burden

We must sympathize with our pro users and remember that an acceptable mental workload for a task performed weekly can be totally overwhelming (and error prone) for a task performed dozens of times per day.

To initiate the import process, the user will merely insert the cards into the card-readers. It's an unnecessary burden to the require the user to interact with the software to begin the imports... in this context, they have already clearly communicated their intent.

When all cards have finished importing, the software must clearly indicate this to the user... with a NotifyOSD to catch their eye if they're at the workstation, and with the persistent state of an Application Indicator that they can easily check if they missed the NotifyOSD.

For background on high-volume pro use cases in general, please see lp:678024.

The file import UX must inspire confidence that: 1) dmedia will do the right thing automatically, 2) dmedia wont even give the user the opportunity to make stupid mistakes, 3) dmedia will be honest and tell the user when they should PANIC

So what's the best UX for this user?

Notifying with NotifyOSD

Inserting a card

Imports will start automatically without user intervention. However, the user does need some reassurance that the card was inserted correctly, that the import has begun.

When the card-reader is connected via USB or FireWire (very likely the case), using the USB or FireWire icon is appropriate and might also help disambiguate between card-readers. For example, when using a FireWire card-reader:

The word "new" in the notification summary is extremely important... constant reassurance that dmedia wont create duplicates, will never make the user manually de-duplicate. The user needs to know that they can insert a card at any time without negative consequences (especially as the imports happen automatically).

I personally feel the notification body should be the card's full mount point. Akshat mentioned on #novacut that this might seem "scary", but for pro users I personally disagree. I don't think this overwhelms them, and it does offer a gentle invitation to learn more should they ever want to (or need to).

I think dmedia needs to always convey transparency. We shouldn't overwhelm the user with useless details, but at same time, we shouldn't dumb down or remove potentially useful information without good reason. There's a fine line.

Pro users are all rather trained to constantly micro manage their files, 2nd guess their software... they become so out of necessity. They're rightfully paranoid about making a mistake and loosing their data.

dmedia (as a technology) can relieve the pro user from the burdens of file management, will allow them to relax and focus on being creative. But dmedia (as a user experience) still has to build enough of the user's trust that the user will let go.

Inserting multiple cards

dmedia supports multiple simultaneous imports. If the notification from the first import has already expired, a new notification is displayed and the 2nd imports starts automatically.

If the first notification is still present, the two are merged. I believe the summary should be conspicuously changed to be very clear that both cards were detected and are being scanned.

Import finishes

Pro users can be comforted by data, and this is a place to reassure them with the right kind of data. Pro users have a very good feel for file size because they deal with it constantly... they have a good feel for how many pictures will fit on a card of a certain size, how many minutes of video. This is also a point when the pro user will do a sanity check that dmedia can't do for them, e.g., "I thought I filled that 32GB card, but it says it only imported 10GB, what's up?". Transparency builds trust.

We also reassure the user with that word "new" again, constantly reinforcing our contract to never create duplicates that must be manually resolved.

I strongly feel that the card should be unmounted once the card is imported, thus the eject icon is appropriate. We don't want the user to feel the urge to eject/unmount the card before they remove it, and we don't want them getting any "unsafe removal of device" warnings. We want them to see this notification and think, "it's done, I can snag the card". We shouldn't show the notification till it actually is safe to remove the card, till sync has been called and the card unmounted.

Notice that unlike when the card was inserted, the mount point is not in this notification. There is a good reason for that, see below.

Multiple cards, import finishes

Most likely the memory cards will be imported using several external USB card-readers. In this case, there isn't technically a way for the software and the user to be clear on which card-reader is which. So we should only display a notification when the final import finishes... when all cards can be removed.

As the card-reader or card usually will be the bottleneck, parallel imports are an easy way to reduce import times.

But more importantly, parallel imports are an opportunity to minimize the times we must interrupt the user. With 4 card-readers, we should interrupt the user 1/4 as many times as with 1 card-reader. We want the workflow to be: 1) insert 4 cards, 2) go do other work, 3) notice that the aggregate import process has completed, 4) remove all 4 cards, 5) insert 4 new cards.

So the UX trick is helping the user see the import progress in aggregate. This is why no mount point is shown when a serial import finishes, we want it to conceptually match when a parallel import finishes in total.

And remember, we aren't maliciously tricking the user, we're doing them a favor. In practice, cards will typically have roughly the same amount of data, will take roughly the same amount of time to import. The user will appreciate getting more work done. Pros have work to do.

Import finishes - variants

Rule number 3 - dmedia will be honest and tell the user when they should PANIC. Finding duplicates isn't necessarily a bad thing, but finding duplicates might be a sign something is amiss, so we must always clearly convey this to the user. Part of letting the user relax is being very clear when there is reason for concern. We don't want the user to have to 2nd guess dmedia when it tells them, "trust me, everything is fine".

This seems appropriate for when no new files are found... again, we are very explicit about the number of duplicates found.

Automatically format the cards when safe

This is the last and most painful pain point in this workflow. Nothing is worse than to start taking a photo or shooting video and realize that your card is unexpectedly full. Then you have to 2nd guess yourself... is the card full because I forgot to format it after an import, or because these files haven't been imported?

If during the import you can immediately store the new files with sufficient durability (for example, say our workstation has a RAID10 array), then the card should be formatted after the import completes, before the notification is displayed. The steps should be:

1. import all new files from all cards
2. unmount cards
3. format cards
4. display notification

We want the aggregate import completed notification to mean, "These cards are ready to throw back in cameras to shoot the next scene. Everything is fine. Relax.". We don't want pros to ever have to 2nd guess themselves. Files on the card? Then they need to be imported, period. There should be no error prone gray area.

Normally pros format the cards in the camera, generally immediately after they import. But this is probably the most error prone part of workflow. You only have to space out for a moment and grab the wrong card, format it, and poof, the single copy of those files just vanished. And you wont realize it till later because you thought you grabbed the card that was already imported.

Note that to avoid the bad FAT32 fragmentation problems, pros format their cards rather than merely deleting the files. HDSLR/DSLR cameras feature the format operation very prominently in the camera's menu.

First run

It should be mentioned that the very first time a pro user uses the dmedia importer, the import should not happen automatically. Instead, a yet to be designed welcome window opens explaining that dmedia will import all video, audio, and image files automatically when they insert a card.

This first run is basically irrelevant as far as the 90% use case goes, but it is an important first contact with the user during which we need to reassure them about the usual: 1) dmedia will do the right thing automatically, 2) dmedia wont even give the user the opportunity to make stupid mistakes, 3) dmedia will be honest and tell the user when they should PANIC

Application Indicator - the RenderMenu

We're proposing an application indicator to aggregate the long running background processes characteristic of digital content creation. We're tentatively calling this the RenderMenu.

The intent is to use the RenderMenu to allow you to control and see the status of long-running headless servers doing things like importing files or rendering video. We want this to be more than just a place to minimize content creation apps, but this requires that the application have a clean client-server design where the backend can run independent of the graphical user interface.

Pending render jobs should be dispatched automatically without the user needing to start them. At the same time, they should never interfere with work the user needs to do... render jobs should automatically throttle back or stop entirely when the user needs the system resources. This gives us high average utilization, but without the creative downtime during which the system (or a specific application) is basically unusable.

We feel it's highly intrusive to require an application to be open simply for the sake of importing or rendering, especially as the application is often unusable anyway (either because the application explicitly locks the user out, or because the application becomes too unresponsive for work to be practical).

The details of the RenderMenu aren't final, but we do feel something like this is the appropriate place to aggregate information about the dmedia import operations.

At a glance indication of active imports

We don't want the user accidentally removing memory cards during an import, so I believe the RenderMenu should clearly indicate the normal state vs a state where there are active imports.

Normally the RenderMenu will be set to STATUS_ACTIVE. When one or more import operations are in progress, the RenderMenu will be set to STATUS_ATTENTION. When all import operations are completed, the RenderMenu is set back to STATUS_ACTIVE.

Note that the notification displayed when the importing completes provides an informative summary of the import, not merely an indication of the state change. Whereas the RenderMenu status never provides summary information, just a way to tell at a glance whether there are active imports.

Finding details of recent imports

Launching media browser filtered to recent imports

Canceling an import operation