2

Before anyone says this is a duplicate, this question isn't about wording of Save (as draft) and Submit buttons or their positioning on a form.

For our app, we'll assume that the user knows that Save will save only data, and Submit will both save and publish (so that a supervisor or the general public will be able to see it, or you're telling an external (to the app) service to generate a[n] audio, video, slide show, etc.)

I've been asked to clone the record when the user submits, and then make the original no longer editable. The original record would be flagged as submitted/rendered. When the user goes back to the original record (in an attempt to edit it), we would show:

  1. a link/image to the generated PowerPoint, poster, video, article, etc.
  2. a button to clone the data (in case they want to explicitly create a different version because of a different recipient, and leave the clone as editable.)
  3. a button to edit the data (which would clone the record and land the user to that [new] cloned record's edit screen)
  4. a submit button (which would then again clone the record and leave the clone as editable, but will not land the user to the edit screen, but to the list of records).

As a user, I would be overwhelmed with the unsolicited generation of so many duplicate records, and I wasn't even given the opportunity to name the duplicates. It's like I have a Word document, and every time I print it, a clone would be generated and each clone would be named serially (prepend Copy x of [Original]).

What do you suggest us to do? How would we rework this?

If the answer to the question is "it depends", for which situations would be yes vs. no?

1

Seems like there's two cases of "cloning" functionality here from the user's perspective.

"Clone" as in I want to explicitly copy the file and use it as a template for something new.

and

"Versioning" as in as I make changes, the system is nice enough to track historical versions for me.

This secondary action should happen in the background by the system. Think of Time Machine on Mac OSX. I love the reassurance that the system is backing up older versions of my files as I make changes to it, but I couldn't care less how it's actually doing it. Much less, the fact that for the system the action for both copy and versioning is identical.

So see if you can have the system create copies in the background, but don't directly show users those historical versions in the listing.

So something like this:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • The above proposition makes a lot of sense. Is the published state displayed per version (of a file) or per file? How do I convince my supervisor that we create versions at "Save Changes [Only]" and not on "Save and Publish"? – Mickael Caruso Mar 31 '15 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.