> 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.
> > 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.
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)?
> > > 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.
> 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
> On Mon, Nov 2, 2009 at 6:57 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> > I'm not sure about the exact colors, but the visual distinction is a
> > big plus in my book.
> > > > 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.
> 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.
> Just chiming in that I'm also +1 to visual distinction, -1 to current
> colors.
> On Nov 3, 4:27 pm, 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". 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
>> On Mon, Nov 2, 2009 at 6:57 PM, Gabriel Hurley <gab...@gmail.com> wrote:
>> > I'm not sure about the exact colors, but the visual distinction is a
>> > big plus in my book.
>> > > > 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.
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
On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov <burc...@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.
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 <burc...@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.
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.
> 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 <burc...@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.
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?
-- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com
|
