Chrome Dev Tools & Inline Dynamic JavaScript

If you are using Chrome dev tools to debug your application then you might have come across this situation.  If you dynamically load some content, and that content contains an inline <script> tag, then annoyingly you can’t see that script under Source in the developer console.

Thankfully there’s a nice simple solution to the problem: insert the following tag at the end of your inline script:

<script>
    //...
    //@ sourceURL=MyInlineScript.js
</script>

This will make the script appear in the Sources list under the “No Domain” section:

InlineScript

Remember that if the inline script is part of a Razor view then you will need to escape the @

<script>
    //...
    //@@ sourceURL=MyInlineScript.js
</script>

Update

Since this post was first written the syntax has been changed to use //#

<script>
    //...
    //# sourceURL=MyInlineScript.js
</script>
Advertisements

Are Your Users “Sure”?

Are You Sure?

You’ve probably been asked the question a hundred times already today: are you sure you want to do that?

Cancel

Are you sure you want to delete that file?  Are you sure you want to log out?  To change that extension?  To update this setting?  Are you sure about anything any more?

One of my pet hates is working with an application that is constantly doubting me.  “Yes I’m sure – that’s why I clicked the button!”

Based on personal experience and absolutely no real data, I estimate that I answer “no” to that question…once a week?  A month?  Not often, certainly, and yet over and over again I have to keep expressing my certainty about every little decision.

Just Stop Asking

I’ve been working on a new version of an existing web application recently and one of the key UX decisions has been to stop asking unnecessary questions.  If the user says “jump” then don’t ask if they’re sure; don’t even ask them “how high”…just do it!  We want to trust our users to know what they are doing – wherever possible, we want to do the most obvious thing first and ask questions later.

But What About…

Ah, yes, good point.  Quite often, users don’t know what they’re doing.  And quite often, they’re going to do something wrong.  This, presumably, is the reason that we are constantly asked if we really want to do something: if we complain later then at least the developer can say “well you did say you were sure…”

So how can we account for the (hopefully rare) mistakes and still not get in the way of the average user?

Our approach is to make everything undoable.  Make the consequences of even the serious-sounding actions (“delete this forever?”) recoverable if they happen by accident.  In fact…

Make it as difficult as possible to seriously cock things up

When the user deletes something, give them a little notification saying “Great, that’s gone… unless you click this: [Undo]”.  It doesn’t need to be a big notification – just something that they’ll notice if they’re sat in a cold sweat thinking they’ve just thrown away the last 4 hours’ worth of work.

Undo Popup

Promote Exploration

There’s another up-side to this approach – it encourages users to play around and explore.  If they are confident that they cannot accidentally break something permanently then – hopefully – they will be happier to try something and see what happens.

In a lot of applications, “fear of breaking it” can be a pretty serious barrier to adoption.  It makes sense as well – if someone is not too computer-literate then they probably should be worried about doing something wrong.  But if, when they accidentally delete next months payroll, they have a big friendly button saying “don’t worry – just click here and everything will be back to normal” then you hope that they will worry less about clicking that button next time.