Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#11834 closed New feature (fixed)

Colorized technical_500_response: django code is green, user code is red.

Reported by: buriy Owned by: ethlinn
Component: HTTP handling Version: 1.1
Severity: Normal Keywords: colorize 500 http500 prettify
Cc: gonz, idan@…, djangoproject.com@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: yes

Description

Pretty debatable feature. Helps to grasp easily what parts of the frame belongs to django, and what to user.

Attachments (9)

11834.png (80.9 KB) - added by buriy 5 years ago.
How does it looks after applying patch
11834_2.png (68.0 KB) - added by buriy 5 years ago.
Different stack
11834_green_yellow.patch (2.8 KB) - added by buriy 5 years ago.
Screen shot 2010-02-03 at 18.39.27.png (125.2 KB) - added by buriy 5 years ago.
Green-yellow
11834.2.patch (8.2 KB) - added by buriy 5 years ago.
Patch allowing to customize debug colors.
11834.patch (8.2 KB) - added by buriy 5 years ago.
Patch allowing to customize debug colors.
11834--2011-05-12.patch (7.7 KB) - added by guettli 4 years ago.
patch which applies to 1.3.x SVN
11834_dimmed.patch (2.8 KB) - added by Aleksandra Sendecka <asendecka@…> 4 years ago.
buriy's first patch changed into grey-scale
11834.2.png (52.8 KB) - added by Aleksandra Sendecka <asendecka@…> 4 years ago.
and the debug page with a patch

Download all attachments as: .zip

Change History (33)

Changed 5 years ago by buriy

How does it looks after applying patch

Changed 5 years ago by buriy

Different stack

comment:1 Changed 5 years ago by guettli

  • Cc hv@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 5 years ago by russellm

  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

Reasonable suggestion, but probably calls for different colour choices. To me, Red/Green implies stop/go or broken/good, which isn't the intention. There's nothing wrong with the existing stack trace colors, IMHO - we just need to pick a way to make a distinction between user and internal code. Collapsing the 'django' portions of the stack is another option.

Changed 5 years ago by buriy

Changed 5 years ago by buriy

Green-yellow

comment:3 Changed 5 years ago by buriy

  • Status changed from new to assigned

My friend designed suggested the green-yellow color scheme fix, i've updated patch and added new screenshot.
How about this version? I like it even more.

comment:4 Changed 5 years ago by russellm

  • Component changed from HTTP handling to User Experience

#13148 made some additional suggestions regarding the debug page, raising the UX issues for the debug page again.

I'm going to move this to the UX component so we can get some designer mojo on it.

Changed 5 years ago by buriy

Patch allowing to customize debug colors.

Changed 5 years ago by buriy

Patch allowing to customize debug colors.

comment:5 Changed 5 years ago by buriy

  • milestone set to 1.3
  • Needs documentation set
  • Needs tests set
  • Patch needs improvement unset

Russell, great idea.
I added also a better patch, that allows changeable and controllable colors.
It's not in RFC state (docs & constants are inlined), but overall it's very good prove of the concept, and you can play with it.

But if we considering real improvements of the debug pages,
I'd also add a way to do werkzeug-style of post-mortem inplace-debugging, also reducing default output,
and a better output for template frames.

comment:6 Changed 5 years ago by gonz

  • Cc gonz added

comment:7 Changed 5 years ago by guettli

  • Needs documentation unset
  • Needs tests unset

comment:8 Changed 4 years ago by SmileyChris

  • milestone 1.3 deleted
  • Needs documentation set
  • Needs tests set
  • Severity set to Normal
  • Type set to New feature

comment:9 Changed 4 years ago by SmileyChris

From the group discussion:

The agreement between core devs and me (or at least how i get it) was
that we decided that this patch needs to be a part of larger "debug
page usability improvement suite".

I'd be happy to just see just this in for now. We can iteratively improve the debug page, and getting colorization in would be a great start.

comment:10 Changed 4 years ago by Alex

As someone who hits Django bugs often enough (if you aren't pushing the framework to the limit you're doing something wrong :D) I'd really want a way to disable this.

comment:11 Changed 4 years ago by SmileyChris

I'm confused. Why would you need to disable this because you hit a Django bug? It still helps with readability of the traceback.

If you really wanted to though, you can disable it by setting TRACEBACK_COLOR_SCHEME = {'': ('#bbe',)} (althought it would be nicer if you could just set it to None for no colouring).

comment:12 Changed 4 years ago by SmileyChris

  • Patch needs improvement set

(or perhaps you don't even need that '' option taking a second look)

In any case, we can't use a dictionary here for the color scheme because the order isn't guaranteed so marking as needs improvement.

comment:13 Changed 4 years ago by jezdez

  • Easy pickings unset

Sounds like a great thing for our design BDFL to decide.

comment:14 Changed 4 years ago by idangazit

  • Cc idan@… added

Nifty.

I like the idea of making it easier to see in what parts of a traceback are in "my code" (versus code in Django itself).

This solution seems over-engineered to me for that purpose. Looking at the patch, I have configurable control over how packages are colored; I'm skeptical that most users require this kind of detail, let alone configurability.

Second, multiple colors starts to introduce design considerations that aren't being addressed. When I'm looking through a traceback, I'm afforded no indication of what these colors mean, nor am I provided a legend indicating which colors map to what parts of my source. I'm not wild about adding a legend to tracebacks; there's already quite a bit of information for users to process there without adding more.

Keeping in line with the original goal of the ticket, I'd propose that the solution simply help users distinguish between their code and Django code in tracebacks. With the exception of outliers like Alex, most users are hunting bugs in their code, not Django. With this simpler distinction, we can do away with colors, and rely on a simpler mechanic which is self-explanatory, like slightly dimming the Django frames. The goal isn't to make them light to the point of invisibility, rather to make them just different enough that the eye has an easy time skipping over the Django frames. Hopefully, this solution also obviates the need for Yet Another Setting.

comment:15 Changed 4 years ago by pmclanahan

@idangazit +1. Dimming sounds perfect, plus it'll work even for the colorblind.

Changed 4 years ago by guettli

patch which applies to 1.3.x SVN

comment:16 Changed 4 years ago by guettli

I don't think yet another settings variable is a good solution. I think this should be a small patch to highlight django code vs. other code. I think this
patch does not need tests or documentation. It needs to be committed, since it is very useful.

comment:17 Changed 4 years ago by jezdez

  • Needs tests unset

Well, it certainly needs a proper patch though now that we have a good proposal from idangazit. Documenting the change is also imperative to explain the reasoning behind it.

comment:18 Changed 4 years ago by idangazit

  • UI/UX set

comment:19 Changed 4 years ago by haras

  • Cc djangoproject.com@… added

I have been thinking about this for quite a long time.

Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide) them.

Fold those items:

  • Python path at the top yellow background.
  • (Hide or fold) django traceback entries

When I have a problem I have to scroll down (passing django calls) few pages until I am able to find which MY action caused an error.
I know looking at django callback may be useful, but in my case, hardly ever, and probably for newcommers also.

I am imagining this like that:

At the top of the error page, there are tabs.
Summary, Traceback, Request, Settings, and copy-paste view (feedback view).

Summary tab, contains this yellow background information with PYTHON_PATH initially folded, and traceback filtered out to include only information from project not calls from django itself.

Traceback, request and settings tabs as it is right now, but separated for easy of view.

copy-paste (feedback) - a standardize view for easy of copy-and-paste to the Internet message boards, groups and so on...

It would need a template refactor and some more js involved, should not be a hard thing to do.
I read that there is a plan to redesign an error page, but since then, those modifications should do the job.

Colored output of the trackeback does not solve my problem of scrolling few screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.

What's I am thinking is a tabs at the top which manipulates with visibility of certain divs of error page.
A quick temporary fix, before complete redesign of error page.

Discussion at: https://groups.google.com/forum/#!topic/django-developers/aQtKMRxdTHM

comment:20 Changed 4 years ago by anonymous

  • Owner changed from buriy to ethlinn
  • Status changed from assigned to new

comment:21 Changed 4 years ago by julien

  • Component changed from User Experience to HTTP handling

Changed 4 years ago by Aleksandra Sendecka <asendecka@…>

buriy's first patch changed into grey-scale

Changed 4 years ago by Aleksandra Sendecka <asendecka@…>

and the debug page with a patch

comment:22 Changed 4 years ago by idangazit

  • Triage Stage changed from Accepted to Ready for checkin

comment:23 Changed 4 years ago by idangazit

  • Resolution set to fixed
  • Status changed from new to closed

In [16343]:

Fixed #11834 -- Improved technical 500 stacktrace display.

Thanks to buriy and Aleksandra for the implementation!

comment:24 Changed 4 years ago by guettli

  • Cc hv@… removed
Note: See TracTickets for help on using tickets.
Back to Top