Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#11834 closed New feature (fixed)

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

Reported by: Yuri Baburov Owned by: Aleksandra Sendecka
Component: HTTP handling Version: 1.1
Severity: Normal Keywords: colorize 500 http500 prettify
Cc: Gonzalo Saavedra, 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 Yuri Baburov 7 years ago.
How does it looks after applying patch
11834_2.png (68.0 KB) - added by Yuri Baburov 7 years ago.
Different stack
11834_green_yellow.patch (2.8 KB) - added by Yuri Baburov 7 years ago.
Screen shot 2010-02-03 at 18.39.27.png (125.2 KB) - added by Yuri Baburov 7 years ago.
Green-yellow
11834.2.patch (8.2 KB) - added by Yuri Baburov 7 years ago.
Patch allowing to customize debug colors.
11834.patch (8.2 KB) - added by Yuri Baburov 7 years ago.
Patch allowing to customize debug colors.
11834--2011-05-12.patch (7.7 KB) - added by Thomas Güttler 6 years ago.
patch which applies to 1.3.x SVN
11834_dimmed.patch (2.8 KB) - added by Aleksandra Sendecka <asendecka@…> 5 years ago.
buriy's first patch changed into grey-scale
11834.2.png (52.8 KB) - added by Aleksandra Sendecka <asendecka@…> 5 years ago.
and the debug page with a patch

Download all attachments as: .zip

Change History (33)

Changed 7 years ago by Yuri Baburov

Attachment: 11834.png added

How does it looks after applying patch

Changed 7 years ago by Yuri Baburov

Attachment: 11834_2.png added

Different stack

comment:1 Changed 7 years ago by Thomas Güttler

Cc: hv@… added

comment:2 Changed 7 years ago by Russell Keith-Magee

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

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 7 years ago by Yuri Baburov

Attachment: 11834_green_yellow.patch added

Changed 7 years ago by Yuri Baburov

Green-yellow

comment:3 Changed 7 years ago by Yuri Baburov

Status: newassigned

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 7 years ago by Russell Keith-Magee

Component: HTTP handlingUser 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 7 years ago by Yuri Baburov

Attachment: 11834.2.patch added

Patch allowing to customize debug colors.

Changed 7 years ago by Yuri Baburov

Attachment: 11834.patch added

Patch allowing to customize debug colors.

comment:5 Changed 7 years ago by Yuri Baburov

milestone: 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 6 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra added

comment:7 Changed 6 years ago by Thomas Güttler

Needs documentation: unset
Needs tests: unset

comment:8 Changed 6 years ago by Chris Beaven

milestone: 1.3
Needs documentation: set
Needs tests: set
Severity: Normal
Type: New feature

comment:9 Changed 6 years ago by Chris Beaven

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 6 years ago by Alex Gaynor

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 6 years ago by Chris Beaven

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 6 years ago by Chris Beaven

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 6 years ago by Jannis Leidel

Easy pickings: unset

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

comment:14 Changed 6 years ago by Idan Gazit

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 6 years ago by Paul McLanahan

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

Changed 6 years ago by Thomas Güttler

Attachment: 11834--2011-05-12.patch added

patch which applies to 1.3.x SVN

comment:16 Changed 6 years ago by Thomas Güttler

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 6 years ago by Jannis Leidel

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 6 years ago by Idan Gazit

UI/UX: set

comment:19 Changed 6 years ago by Matt Harasymczuk

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 5 years ago by anonymous

Owner: changed from Yuri Baburov to Aleksandra Sendecka
Status: assignednew

comment:21 Changed 5 years ago by Julien Phalip

Component: User ExperienceHTTP handling

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

Attachment: 11834_dimmed.patch added

buriy's first patch changed into grey-scale

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

Attachment: 11834.2.png added

and the debug page with a patch

comment:22 Changed 5 years ago by Idan Gazit

Triage Stage: AcceptedReady for checkin

comment:23 Changed 5 years ago by Idan Gazit

Resolution: fixed
Status: newclosed

In [16343]:

Fixed #11834 -- Improved technical 500 stacktrace display.

Thanks to buriy and Aleksandra for the implementation!

comment:24 Changed 5 years ago by Thomas Güttler

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