AyatanaDmediaLovefest

Revision 63 as of 2010-11-29 21:54:46

Clear message

Ayatana + dmedia == Lovefest

Note: this is a work in progress, not yet complete

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.

added.png

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

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 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 new 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

searching.png

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:

searching-firewire.png

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.

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

Multiple cards are inserted

searching-other.png

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.

searching-2x.png

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

added.png

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

added-lots.png

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

The user is notified when the import begins for individual cards, but only when the import has completed for all cards.

Import finishes - duplicates, no files

added-with-duplicates.png

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.

no-new-files.png

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

no-files.png

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

added-lots.png

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

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