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 professional file import UX that sets the benchmark the industry 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.

Thoughts? Please add it in the Feedback section or stop by #novacut on IRC.

Update: dmedia 0.2 basically implements these features - check out this demo video

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 ain't it. This is about making a realistic professional production workflow as efficient and stress-free as possible, without compromise.

Here are some assumptions to help narrow the focus:

  • We're on the production set of a movie or TV show... people are busy, things are hectic, and wasted time carries a high price
  • There's a dedicated workstation on-set used exclusively for importing cards
  • Imports are done in parallel batches by putting several cards into the several card-readers attached to the workstation
  • Importing is extremely repetitive... dozens of batches will be imported each day

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

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

If we want to truly push the efficiency of this workflow to its limit, we can only require the user to do 3 things:

  1. Insert cards into the card-readers to begin an import
  2. When convenient, glance at an indicator to see if the import has finished
  3. Remove cards from the card-readers when the import has finished

Requiring any more than this is unnecessary and means we aren't serving our pro user as well as we could. Notice that quite conspicuously we can't require use of the keyboard or mouse.

Pro users are exceedingly paranoid about data loss. dmedia as a technology can reduce workload and stress by replacing error-prone repetitive tasks with smart and opinionated automation. But dmedia as a UX still must garner enough of the pro user's trust that they can relax and enjoy the benefits. Our guidance is that 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

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

Notifying with NotifyOSD

Card is inserted


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 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 start 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.

And remember, these are pro users. There's a reason race cars have more gauges and knobs than your daily driver... utility.

Multiple cards are inserted


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


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

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.

After the import is complete, dmedia will unmount the card automatically, thus the eject icon is appropriate.

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. We don't want to invite the user into an error-prone and unproductive gamble that could, after all, cause data loss. So we will only display a notification when the final import finishes, when all cards can be safely 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 N cards
  2. Go do other work
  3. Notice that the aggregate import has completed

  4. Remove all N cards, insert N new cards...

So the UX trick is helping the user see the import as something that only completes in aggregate. This is why no mounts points are shown when the imports finish. And besides, by the time this notification is shown, there aren't any mount points anyway... the cards have already all been unmounted.

Import finishes - duplicates, no files


Rule number 3 - dmedia will be honest and tell the user when they should PANIC. Finding duplicates isn't necessarily a bad thing, but it might be a sign something is amiss, so we must always clearly convey duplicates to the user.

Part of helping the pro user relax is being forthcoming when there is any reason for concern. To enjoy its benefits, the pro user must trust dmedia, not 2nd guess it. Again, transparency builds trust.


This notification is used when no new files are found... again, we are very explicit about the number of duplicates found.


This notification is used when no files were found whatsoever.

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


When we display this notification, we want the pro user to know the process is absolutely complete, that dmedia has left no room for error. They can take these cards, throw them back into the cameras, and shoot the next scene.

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 grey 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 first time the dmedia importer is used, the import should not happen automatically. Instead, a yet to be designed welcome screen should introduce the user to dmedia: DON'T PANIC

This first run is irrelevant as far as the normal 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

The welcome screen might look something like this:


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. It will look something like this.


Thanks to James Raymond for the great mock-up!

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 the RenderMenu must clearly indicate the normal state vs a state where there are active imports.

Note: not the final icon, just something quick for illustration.


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.

Checking progress of current import

When you open the RenderMenu, the first item will always be the current import operation, assuming there is one.

There will be a progress bar and text something like, "File 83 of 126". If there are parallel imports, the entire batch is aggregated into this singled item. For example, if you added another card into the batch, the text would change to something like, "File 83 of 292".

Finding details about current import

If you click on the current import item, it will open the media browser and show complete details of the current import. If doing parallel imports, the progress of each card is shown independently, as well as the aggregate progress.

Canceling current import

In the pro use case we're dealing with here, it will be exceedingly rare that an import will be canceled. We will provide a mechanism, but it does not need to be readily accessible and must not be easy to invoke by mistake.

The option to cancel an import will be in the above details view.

Finding details of recent imports

In addition to any current import, the RenderMenu will show the past few completed imports. If you click on a completed import, it will open the media browser and show the full details of that import.


Right now both dmedia and Novacut have a laser focus on one thing: providing an industry leading workflow for HDSLR cameras like the Canon 5D Mark II.


Why are we doing this? Because we want to win. We want to lead. Say in six months of development we could have an okay editor for editing video from a wide range of cameras. Or we could have a video editor that in some decisive areas is the best video editor available for the cameras of the future. Obviously the latter sounds a lot more strategic.

To be clear, Novacut will be a general purpose editor capable of editing any video format GStreamer supports (i.e., basically everything). The HDSLR specific features are about important workflow niceties, not so about much the video editing itself.

There's a lot of low hanging fruit that can provide a far more practical workflow to HDSLR users. For example, after just a few weeks of development, dmedia already had an important feature that, AFAIK, no one else in the world has... it's database stores the shutter, aperture, ISO, lens, and camera that an HDSLR video was shot with. Photographers have long enjoyed this information in their photo applications. It's part of why one can become a great photographer so easily these days... as you review photos, you can see the settings and think, "oh, I should have stopped down the aperture a bit more in that photo, but it's just right in this other photo... F3.5 is the sweet spot for that shot".

The file import UX is similar low hanging fruit where with little effort we can offer a decisive advantage. This is extremely important for Ubuntu and the freedesktop because the file import UX is the very first experience a newcomer will have, and I guarantee it will impress them. Even before we have particularly capable editing (or any editing at all, for that matter), this will be a place where Ubuntu offers the absolute best workflow for professional HDSLR users.

As this is very new territory, no one has much of a lead on HDSLR workflow. And it's also an area where having a mature video editor with a long legacy is a disadvantage... that's a lot of code with the wrong assumptions (in terms of HDSLR) deeply baked in. By starting with a blank slate and leveraging web technologies like CouchDB, we can move considerably faster on these differentiating features... even though our proprietary competitors have substantial budgets and many developers.

Special Thanks

Special thanks to David Green for already tearing into the implementation work on this UX design when yet the paint had barely dried.


Feedback from MPT

MPT had this to say in an email on the Ayatana list:

To reiterate what I said on IRC, I think using either notification bubbles or a status menu for this is inappropriate. A notification bubble is inappropriate because the moment at which you want to know how many photos you've imported so far is not necessarily during the brief period that the bubble is visible. And a menu is inappropriate because you can't do anything else while you're viewing the things inside it.

I suggest instead investigating layouts for a window that lists import sessions, with columns for time, number of photos imported, size, and number of duplicates found.

Feedback from you

AyatanaDmediaLovefest (last edited 2012-04-15 19:59:54 by jderose)