In my application the user will describe a case, a case will typically have a title, description, date and some other attributes. The user will also be able to add attachments to a case.

The case must have an ID for the user to be able to add attachments. This ID is created when the case is saved for the first time. Therefore, the user will have to press 'save', then re-open the case to be able to add an attachment.

To provide a better user experience I want to save the case before the user attempts to add an attachment. I have thought of two approaches, both with their pros and cons:

  1. Two step creation - The user must first enter the title of the case only. When he saves the title, the ID is created and he is shown another form with the remaining case fields - description, attachments and so on.

  2. Background save - Save the case in the background when the user fills the title field and deselects it. The case is saved with the title only, and the ID is created. This is what I do at the moment.

I feel that my first approach is the safest one, where little can go wrong, but may be annoying for the user. My second approach is better for the user, but only if he actually enters the title first. If he tries to add attachments first, he won't be able to, and probably won't understand why. Also, if he decides to cancel the case, the title will still be saved.

Which approach should I go with? Are there other approaches that I have not thought of?

4 Answers 4


Does the ID depend on the title name? Why not just generate a random ID the moment the user starts the case? This sounds more like a technical problem than a UI design problem. Also discarding a case should be possible, as users might just abandon it and nobody wants empty files that you have to delete manually.

Should this really be the only way, I would prefer guiding the user through the two-step creation process. It's constrained and assures you that the user does what you expect him to do. It also makes validation more simple for both of you.

If you leave the order of input to the user, you would alienate him by stating that he forgot something, if he did it the (from your standpoint) wrong order.

  • No, the ID does not depend on the title, but.. if I generate the ID when the user starts a new case (before it gets the title) the empty case will show up on a list of all cases, but everything will be blank (while it's being edited), and it may look strange. This is a small issue though, and it might be overlooked. The two-step process will eliminate that issue, but be more annoying for the user, but you think the two-step is better?
    – sch
    Oct 3, 2016 at 7:50
  • Why are you concernced that it's annoying? Is it common for your users to leave the title blank or is the title depending on some other information that isn't available at the beginning? If no, then it shouldn't come unexpected to start with the title. I would be more concerned that unfinished cases show up in the list of cases, as Andre also states.
    – J_rgen
    Oct 3, 2016 at 8:03
  • I've sat in on some meetings where they write these cases, and the titles they set can be pretty.. random, they usually write the description first, so that they can get an idea of a good title. I don't want them to freeze on the first step, just cause they can't come up with a good title, but I think this will be easier with time
    – sch
    Oct 3, 2016 at 8:17
  • I will create a test of the two-step process, and have the actual users test it, and see what the feedback is
    – sch
    Oct 3, 2016 at 8:19

I would introduce the concept of a draft case. A draft case is a case that you create in the background to ensure that the user can manipulate the case as though none of the restrictions you outlined exists.

You can create a draft case when the user attempts to add an attachment, anytime a field is filled or immediately when the case form is opened. A draft case would have an auto-filled title that ensures the application will always be able to auto-save the case. You can use Untitled Case for example. Once the draft case is created, the user can fill the case form in any order they wish and can add attachments at any time.

An application populated with cases that the user didn't explicitly create would be a source of annoyance. So, you should also carefully manage the life-cycle of draft cases. If you have created a draft case and the user has not explicitly saved the case you should consider deleting it. Especially if the draft case is empty i.e. only has the auto-filled title. You may also choose to make the draft case an implementation detail that the user does not get to interact with directly.

  • 1
    This sounds reasonable, but it will take some work to get done, but I like it
    – sch
    Oct 3, 2016 at 7:55
  • You already do auto-saving so it's just a matter of pre-filling the title instead of waiting on the user to give a title. Oct 3, 2016 at 8:00

I would show the whole form with all fields and buttons but title disabled. Once title is filled in then create the ID, display it, and activate all fields and buttons. Save every time they leave a field. Provide a button to Cancel where you delete.


So you have a parent and child data storage scenario. Yay!

I'm going use the Schwartz and assume this is web based presentation using a relational database...

You probably have a Case table (name your tables singular, eh!), and a CaseAttachment table. Both tables likely have numeric primary keys. Getting that attachment stored to the DB requires a numeric foreign to the Case table...which is the crux.

So do this instead:

Add an Attachment table to the party.


download bmml source – Wireframes created with Balsamiq Mockups

Case, CaseAttachment, Attachment.

As the user uploads the images (or files in general), you save them into the database and then return back to the user interface the primary key.

Once the form details for the Case have been submitted, you can assemble the Case and CaseAttachment records, and associate the CaseAttachment entry to theAttachment entry that already exists.

If you're worried about orphaned Attachment records, it would be an easy maintenance routine to find them and purge.

You also get the added benefit of reusing attachments for other cases - for me this would be critical.

  • That would mean not declaring the referential integrity at the database. I don't like that.
    – paparazzo
    Oct 3, 2016 at 14:34
  • There is still full referential integrity with this design - I've added a diagram. Oct 3, 2016 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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