Enhanced debug output colors: django code is green, user code is red.

[Yuri Baburov]

Hi All,

Since you are discussing and applying different features,

I think it's time to ask what do you think of the subj.

It's at http://code.djangoproject.com/ticket/11834

It adds some helpful color beauty to django 500 output.

Sample pictures are here:
http://code.djangoproject.com/attachment/ticket/11834/11834.png and
http://code.djangoproject.com/attachment/ticket/11834/11834_2.png

I'm not a designer, so feedback is highly appreciated.

Also I don't know if the enhancement needs any docs writing or any
other work. Please advise.

--
Best regards, Yuri V. Baburov

[Dougal Matthews]

2009/11/2 Yuri Baburov <bur...@gmail.com>

Hi All,

Since you are discussing and applying different features,

I think it's time to ask what do you think of the subj.

It's at http://code.djangoproject.com/ticket/11834

It adds some helpful color beauty to django 500 output.

Sample pictures are here:
http://code.djangoproject.com/attachment/ticket/11834/11834.png and
http://code.djangoproject.com/attachment/ticket/11834/11834_2.png

I'm not a designer, so feedback is highly appreciated

 

I really like this, I always scan the traceback looking for items with with .virtualenv in the path so I can ignore them - its bugged me for a while. This is clearly a better solution.

I'm no designer either but I perhapsit could do with a bit of attention from one, I'm not that keen on the red (pink?) and green mix.

Also, documentation will be needed so users know what the colours mean but I'm not sure where in the docs. I can't see anything on the current error page.

Dougal

 

[Gabriel Hurley]

I'm not sure about the exact colors, but the visual distinction is a
big plus in my book.

One possible place to document it would be in the information
regarding the TEMPLATE_DEBUG setting here:
http://docs.djangoproject.com/en/dev/ref/settings/#template-debug

- Gabriel

On Nov 2, 2:03 pm, Dougal Matthews <douga...@gmail.com> wrote:
> 2009/11/2 Yuri Baburov <burc...@gmail.com>

>
>
>
>
>
>
>
> > Hi All,
>
> > Since you are discussing and applying different features,
>
> > I think it's time to ask what do you think of the subj.
>

> > It's athttp://code.djangoproject.com/ticket/11834

[Tobias McNulty]

I'm not a big fan of the red/green either.  They imply that Django code is "bad" and user code is "good".  What about something more subtle, like different shades of gray for the background and/or text, to draw your attention to the user code while making it easier to gloss over the Django code (but still readable if necessary)?

Tobias

--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

[SmileyChris]

Just chiming in that I'm also +1 to visual distinction, -1 to current
colors.

[Russell Keith-Magee]

On Tue, Nov 3, 2009 at 5:34 AM, Yuri Baburov <bur...@gmail.com> wrote:
>
> Hi All,
>
> Since you are discussing and applying different features,
>
> I think it's time to ask what do you think of the subj.
>
> It's at http://code.djangoproject.com/ticket/11834
>
> It adds some helpful color beauty to django 500 output.
>
> Sample pictures are here:
> http://code.djangoproject.com/attachment/ticket/11834/11834.png and
> http://code.djangoproject.com/attachment/ticket/11834/11834_2.png
>
> I'm not a designer, so feedback is highly appreciated.

I'm going to echo the tune of others in this thread - coloring
internal code sounds like a good idea, but the current color selection
isn't really appropriate.

> Also I don't know if the enhancement needs any docs writing or any
> other work. Please advise.

No - this is just a styling change, so no docs or tests are required.

Yours,
Russ Magee %-)

[tsmets]

Any color blind in the group with advise on this ... ?

\T,

> --
T. : +32 (0)2 742 05 94
M. : +32 (0)497 44 68 12
@ : tsm...@a3-system.eu
Do you skype too ...
Get Skype and call me for free ?

[Yuri Baburov]

Hi Tobias,

On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty <tob...@caktusgroup.com> wrote:
> I'm not a big fan of the red/green either.  They imply that Django code is
> "bad" and user code is "good".

The opposite, in fact.
Django code is green, "good", user code is red, "untrusted".

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[Tobias McNulty]

On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov <bur...@gmail.com> wrote:

On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty <tob...@caktusgroup.com> wrote:
> I'm not a big fan of the red/green either.  They imply that Django code is
> "bad" and user code is "good".

The opposite, in fact.
Django code is green, "good", user code is red, "untrusted".

Whoops, my bad.  I still think there are concerns about the colors, however.  They imply that something is wrong with the red code, which might not be the case.  There is also the concern of whether or not these colors are distinguishable to colorblind folks.  I think what you need to try to do is make the user code draw your attention first, and the Django code draw your attention second.  I don't think the current color scheme does that in an effective way.

Tobias

[Waylan Limberg]

On Tue, Nov 3, 2009 at 10:57 AM, Tobias McNulty <tob...@caktusgroup.com> wrote:
> On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov <bur...@gmail.com> wrote:
>>
>> On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty <tob...@caktusgroup.com>
>> wrote:
>> > I'm not a big fan of the red/green either.  They imply that Django code
>> > is
>> > "bad" and user code is "good".
>> The opposite, in fact.
>> Django code is green, "good", user code is red, "untrusted".
>
> Whoops, my bad.  I still think there are concerns about the colors, however.
>  They imply that something is wrong with the red code, which might not be
> the case.  There is also the concern of whether or not these colors are
> distinguishable to colorblind folks.  I think what you need to try to do is
> make the user code draw your attention first, and the Django code draw your
> attention second.  I don't think the current color scheme does that in an
> effective way.
> Tobias
>

Actually, they current colors look an awful lot like diffs as they are
displayed by on various sites (green lines added, red lines removed).
In fact, at first glance, that's what I thought I was looking at. One
more reason to change the colors I suppose.

--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Adam V.]

I've been running with this patch applied, and it is a useful
debugging addition, color choice aside.
One thing I ran into, though, is wanting to be able to assign colors
to various 3rd party libraries that I'm also using.

So for instance, giving MySQLdb it's own non-mine, non-Django color,
so I can note DB related problems easier.
That probably opens up a big configuration can of worms; I haven't had
the time yet to code up a patch myself.

- Adam V.
http://adamv.com

On Nov 3, 9:33 am, Waylan Limberg <way...@gmail.com> wrote:
> On Tue, Nov 3, 2009 at 10:57 AM, Tobias McNulty <tob...@caktusgroup.com> wrote:

[Yuri Baburov]

On Tue, Nov 3, 2009 at 11:37 PM, Adam V. <fla...@gmail.com> wrote:
>
> I've been running with this patch applied, and it is a useful
> debugging addition, color choice aside.

Thanks.
Of course, I will do something with current colors.
I think the situation here is that new colors on familiar things
always looks weird from first sight, then become "ok" and for someone
then become "great", like it was for me :) But some colors are just
much less weird then others :)

> One thing I ran into, though, is wanting to be able to assign colors
> to various 3rd party libraries that I'm also using.
> So for instance, giving MySQLdb it's own non-mine, non-Django color,
> so I can note DB related problems easier.
> That probably opens up a big configuration can of worms; I haven't had
> the time yet to code up a patch myself.

Well, I thought about this, the situation is like everywhere -- you
write simple improvement, people tell you "let's go further" and they
suggest more enhancements :)
I think, the only good alternative is subclassing an ExceptionReporter
class and being able to choose your alternative with one-liner, say,
in configuration.
I'll propose new patch.

By the way, django_extensions app does the following:
# usurp django's handler
from django.views import debug
debug.technical_500_response = null_technical_500_response
for their purposes.
is it point of extension? or is monkeypatching ok here?