Usability of server error traceback collapsibles

Django Internals Accessibility
1

Hey all.

Please have a look at this UX issue: [Issue #35137](https://code.djangoproject.com/ticket/35137)

I already made some suggestions on how to improve the accessibility.

What do you think? What would be a good approach?

Cheers
Denis

2

Maybe just me but when I see that little carot/arrow thingy by the box it tells me that it’s collapsible - also the box itself kind of suggests that it’s an accordian. If you’re looking for UI stuff maybe one thing to look at could be the accessibility of the error pages? I’ve seen some comments that accessibility improvements are much needed.

3

Hi, I would like to write a patch for this, but this is also my first patch and might need light guidance, would anyone point me in the general direction for writing a patch?
I have read the contribution guideline and now will be searching the code base for this.

4

Hay!

I wrote this quick prototype to discuss the implementation.

unactive
unactive1531×173 7.68 KB

Notable Additions :

  • Hovering over an error reveals a message Click to Expand and there is an accordion style + at the right end of the error
  • When Clicked it changes to Click to Collapse and the symbol at the right changes to the -.
    active
    active1522×1076 38 KB

On the code side, made some changes to the toggle function

  function toggle() {
    for (var i = 0; i < arguments.length; i++) {
      var e = document.getElementById(arguments[i]);
      if (e && i < arguments.length - 2) {
        e.style.display = e.style.display == "none" ? "block" : "none";
        e.classList.toggle("active");
      } else if (i == arguments.length - 2) {
        e.classList.toggle("active"); 
      } else if (i == arguments.length - 1) {
        e.textContent = e.textContent.trim() == "-" ? "+" : "-"; 
      }
    }
    return false;
  }

and also added a couple of CSS rules handling the aesthetic side

  div.context ol li:hover::after{      /* #######ADDED###################### */
    content: "Click to Expand";
    position: absolute;
    background: white;
    color: black;
    padding: 5px;
    border: 1px solid #000;
    border-radius: 5px;
  }
  div.context ol.active li:hover::after{      /* #######ADDED###################### */ 
    content: "Click to Collapse";
  }

and

  div.context ol.context-line li span {       /* #######ADDED###################### */
    position: absolute;
    right: 56px;
    font-size: 30px;
    transform: translateY(-100%);
  }

If this sounds alright then I own the ticket and then submit a patch.

5

Some changes made per the suggestions in the ticket tracker

Behaviour:
When hovering a pointer over the button it will grow in size marginally and change colour (helping to indicate that its interactive)

6

@abhijeet-singh in the future please check discussions on tickets and whether someone else might be working on a task before creating a patch. From reading #35137, it seems clear to me @denisiko intended to work on this and put this forum thread together as part of working on a patch.

7

In my defence, the ticket was not assigned to anyone so I thought it might be ok to work on it , but you argument is perfectly valid too. I will ensure that this will not repeat in future

Thanks for pointing it out

8

Hi.

I don’t mind if someone goes ahead with their suggestions or even their own patch. I was just under the impression that now was not the right time to already implement something but rather discuss certain problematic UX issues. That’s why I did not yet come up with a patch.

So what would be the best approach now? Should I write my own patch so there are at least 2 design alternatives to discuss? Or do we wait for feedback on usability and accessibility?