A design was just introduced for a brand new application offering the user to delete something.

The user experience is as follows, the user clicks delete on the object. Upon clicking delete, the deleted object turns opaque, with a big red delete button overlaying the object, next to a smaller cancel button.

The developers on the team asked the question, "Can't we just use the built-in javascript confirm dialog" for this? Their argument is that they would have to write new code for this, and the user experience would deter from most other web applications delete experience.

The designers argument is that this specifically calls out exactly what is being deleted, and would allow us to keep a uniform deletion experience across all of our applications.

In general, what are your opinions on "re-inventing the wheel" with basic HTML components like this?

3 Answers 3


The confirm dialog is modal to the window, while your solution is modal only to the element.

My argument is that in case you accidentally clicked the delete button, you'd have to take action no matter what in case of a global confirm. Also, you lose context, which may erase everything the user had in their short-term memory.

My second argument is that there are many sites with inline delete functionality. I guess actually stackexchange uses them somewhere (perhaps careers.so ?)

Of course, an argument can be made with a powerpoint prototype and user testing that users are able to recognize what's happening.

The new code to be written is so short that it could be written here, into this post.

But instead, it's in this fiddle here. It's a whopping 31 lines.

I'm always surprised how people try to avoid to write simple nice-to-have things which makes people's life easier. You should make them care about it somehow I guess.

  • Great points. There is definitely an argument around maintaining that context. With regard to it being only 30 lines, I think a dev could make an argument that it's 300% more code than a simple if(confirm("Are you sure...")) has and would become less scalable as it increases in complexity.
    – Matt Wolin
    Commented Dec 26, 2013 at 22:23

In the early stages of the intranet age and with the introduction of JavaScript I would say that your developers were right. But today, almost 2014, with an upcoming 25 year anniversary of HTML on the internet, I'd say your developers make themselves look old.

Today we use complex web applications and not just simple JavaScript enabled web pages. Thus we need to implement technologies closer to what desktop experience is. We have our files in the cloud, can edit our spreadsheets in the browser or on mobile devices.

If I where to see an out of the box JavaScript confirm dialogue, in an application developed today, I would roll of my chair in laughter. Tell your developers to get in the game and do some reading up on HTML 5, CSS 3 and also some of the popular JavaScript frameworks.

Example of inline delete confirmation dialog

enter image description here

  • I agree with you to some extent. As a dev I think it is a slippery slope when trying to implement overly-sophisticated user experiences for things that are built into the browser. With so many browsers and versions it can become difficult to maintain uniformity across browsers. Also, with regard to "If I where to see an out of the box JavaScript confirm dialogue, in an application developed today, I would roll of my chair in laughter." gmail, and pretty much every web-based email client makes use the js confirm out-of-the-box.
    – Matt Wolin
    Commented Dec 26, 2013 at 22:25
  • @MattWolin: excuse me, but where does GMail do this? Apart from leaving the page with unfinished edits where it's actually a different mechanism (onunload rather than confirm)
    – Aadaam
    Commented Dec 26, 2013 at 22:37
  • Unfortunately I don't have access to gmail from here so how about a different example. Click the 'x' next to your previous comment and you'll see that this website does it.
    – Matt Wolin
    Commented Dec 26, 2013 at 22:50
  • @MattWolin I've updated my answer with an example of an inline delete confirmation button set. Commented Dec 28, 2013 at 8:47

I'd focus on W2C - Workflow + Consistency + Convenience

Whatever user experience you devise, needs to be (in decreasing order of importance):

  1. A good fit in your Workflow
  2. Consistent across your app, to as much extent as possible
  3. Convenient to Code and re-use

In your scenario,

  • if a Javascript confirm dialog
  • which is always going to be modal to the window
  • with buttons that read Ok and Cancel

...fulfills W2C for you, then your developers are probably right. You do not need anything fancier.

If either factor does not suit you, even if it's just the labeling of Ok / Cancel buttons, your designers are justified in wanting a custom built solution.

The custom solution could be:

  • a simple jQuery modal with tailored look and content
  • a more innovative, lesser seen inline delete mechanism

It doesn't matter which, so long as it feels right in your workflow, it is an experience that you will be able to keep consistent for similar actions (most deletes in your case), and if it does not take much longer to code than it deserves.

I'd let go of worries like - "am I reinventing the wheel" or "am I creating a UX that people aren't used to seeing in other apps".

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.