TAB formatting when editing code samples in SE -- Will it improve UX?

Question

Do you think that giving TAB formatting functionality will improve UX?

---

I've seen people complain about not been able to use TAB to format code in SE. There are many fixes such as:

• format code in a text editor before hand.
• use CTRL + K.
• install a user-script, if you're into that kind of thing.
• suck it up and use SPACE x 4.

---

The request to implement tab formatting functionality has been denied by SE, and refuted on the claim that this would damage TAB's native functionality in the browser.

As a developer who focuses on UX, I think there are solutions that avoid damaging Tab's native functionality for disabled users.

I believe that when editing code, TAB is expected by most users to create a tab, not jump to the next element in the page, and for convenience, a method of adding quick tabs can and should exist.

Answer 1

As a developer who focuses on UX, I disagree, on the grounds that I believe that when editing code, TAB is expected by most users to create a tab, not jump to the next element in the page.

I agree! When I'm editing code in my development environment, I'd like tab to create indentation. (In my case, four spaces rather than a tab character.)

However, when I'm writing my post, I'm not in my development environment, and I'm not editing code: I'm writing a post for a website. I expect my text box to behave like a text box. I expect to be able to tab out of it. I also expect that my key bindings won't magically change because I've started a line with four spaces or written <code> in my post - as a UX developer, you may recognise why this is not a great experience.

Now, my answer might contain code, but I don't expect to get any serious programming done in this editor I'm typing in anyway: I expect to get it done in Visual Studio, or Sublime Text, where I write my code before pasting it here. Also pertinent, in my case, is the fact my answers rarely contain code: the SE sites I use most frequently are ones that have nothing to do with programming, and even on Stack Overflow I'm more interested in theory-based questions and answers which contain little to no code (like these: 1 2 3 4).

Now, donning my own UX hat...

I'm a user experience designer and web developer who's presently deeply involved in accessibility and helping a site conform with W3C's Web Content Accessibility Guidelines 2.0. This means my job is about making sure those who are blind, have limited mobility, or so on can use the site effectively and have a great user experience.

A large portion of this concerns blind or visually impaired users who rely on a screen reader and keyboard controls to read and get around a page. Hijacking the tab key is one of the best ways to make that difficult or impossible for them, especially within a form control. Doing this is called a keyboard trap. A user who doesn't know the proper hotkeys to get out of a keyboard trap may need to simply reload the page and hope not to run into it again. This is a big concern when the keyboard trap in question is one of the most heavily used features on the site: the text box for writing and editing questions and answers, in its various incarnations.

This is a big deal, and one of the WCAG success criteria is aptly titled: No Keyboard Trap. It requires you to make special provisions if you create an element that "requires more than unmodified arrow or tab keys or other standard exit methods" to get out of. It's better to not be in that situation in the first place.

For the rest of us, we can go do our serious code editing in a serious code editor.

Answer 2

No, I don't think it will improve the user experience.

Personally, I never treated SE's editor as IDE, just ordinary text box allowing little formatting.

Code should be indented before posting and I find it totally sensible. JSFiddle is meant to write code from scratch, so IDE-like behavior is expected and important.

Users should not write code from scratch in Stack Overflow, but rather post existing code, which is expected to already be formatted/indented.

In case user want to answer with code sample, there are two common cases:

1. Short code sample, few lines of code: easy enough to indent manually.
2. Long code sample: better be tested first anyway, so user will use IDE first anyway.

Answer 3

Yes, as a user preference

I think this should be offered as a user preference (similar to keyboard controls); the behavior should be off by default. This avoids the keyboard trap.

Users who prefer this functionality will be able to choose it, even though it breaks the browser functionality.

Given the number of times this feature has been asked about (5 duplicates, listed here), I think making it a user preference is a reasonable solution.

As to how this could be implemented across sites, it should probably (if possible) only be available on specific sites, similar to how Developer Story is only available on SO.

Answer 4

Yes, I think it will improve UX if targeted properly.

I think any time a convenience can be added for a wide range of users, it's worth putting some thought into. Here is one solution I've thought of that allows the solution to target the users who want the feature.

What about enabling TAB's formating <code> between code tags? </code>

---

<code> If I were to hit TAB now, it would result in 4 spaces. </code> But not outside of the tags.

Advantages

---

• Avoids a keyboard trap. Impaired users can easily avoid using <code> tags, and if they do use them, navigating away from them can be done with arrow keys.

• It doesn't affect the editor's primary functionality. It targets users who have searched the tab issue and found that tabs work for formatting! <code> between code tags :) </code>

• The code for the feature is actually simple and fairly short. it can be done in just 365 characters [365 bytes]. Credit 100% to dandavis for this solution.

Try Before You Buy

---

Go ahead. Put it into the JS console of any Stack Exchange question page, and <code> use tabs between code tags! </code>. Or try the JSFiddle.

$("textarea").keydown(function (e) {
    var t = this.value,
    n = this.selectionStart,
    r = [t.slice(0, n), t.slice(n)];
    if (e.keyCode == 9 && t.indexOf("</code>", n) != -1 && t.lastIndexOf("<code>",
    n) != -1) {
        this.value = r.join("   ");
        this.selectionStart = this.selectionEnd = n + 1;
        e.preventDefault()
    }
})