Interface speed is more important than publishing speed

By Serdar Yegulalp | 2016/07/14 08:00

This is something that came to me when I was using Movable Type. Hitting Publish on a page required me to wait for it to finish all of its operations synchronously before I could continue to do anything. What I really wanted was to be able to save the page, trigger those events in the background, and only need to be notified in some way if things went wrong. With MeTal, we have that, but it still has limitations I want to overcome.

Right now, the UI for publishing is async -- when you send a page off to be published, you get a notification in the interface that X jobs have been queued, and you see them tick down in batches of fifty.

The bad news is that this still requires you to keep that particular page open to get any feedback about what's going on, which somewhat defeats the purpose.

I'm looking into several user-selectable possibilities for how feedback is provided.

  1. Run queue in same window (existing default).
  2. Run queue in another window (or tab), close when done
  3. Run queue in another window, leave open when done, or play a sound, or jump to the published page.
  4. Run queue in background process, email on completion always
  5. Run queue in background process, email on error only
  6. Never run queue, always use scheduled tasks, with email feedback determined by the scheduled task's setting

Obviously this last one is only useful for hosts that allow scheduled tasks, but I have yet to find one running today that didn't.

Some other ideas that are orthogonal but also useful:

  1. Use some late-breaking web feature, like the Notifications API, to provide a notification no matter what tab you're in (although this will only really work if we have a tab somewhere devoted to running the queue, as you can't do this outside of the context of a loaded page)
  2. Create an add-on -- initially for Chrome, as that's what I use -- to monitor for queue actions and provide feedback.

The main problem, then, isn't so much running the script as getting feedback about it back to the user in a timely way -- to honor the asynchronicity of the process all the way.

Tags: UI/UX asynchronous performance publishing

comments powered by Disqus