Better error page design

[rstacruz]

Would you like a better one? I can hack a nice-looking error page in a quick jiff.

Love your work on this gem by the way!

[haileys]

As you can probably tell, I'm not much of a designer!

If you'd like to try and spiffy up the better_errors error page, I'd really appreciate it.

However, please keep all styles and javascript inline. Please try and avoid images, but if you must use them, please inline them with base64.

Cheers.

[rstacruz]

Sure! let me see what I can do.

[andrew]

👍

[rstacruz]

I'm trying to figure out a better layout. Right now, here's where I'm at—not exactly pretty yet, but I'm more of trying to get the "wireframe" properly layed out right first. Thinking of making the backtrace section have their own scrollbars—saves you effort in scrolling back and forth!

Changes to the markup are pretty minimal.

[haileys]

Looks pretty nice! The layout is fluid right?

[neilmiddleton]

Works for me, although I would left align the error at the top rather than center as that's where the eye immediately looks.

[deanpcmad]

That looks great @rstacruz 😄

[jeromegn]

@rstacruz Here are my 2 cents: Looks awesome :) ... but, this page should first and foremost be giving out the details efficiently. Your design is visually pleasing but it takes up too much space. Sometimes the window might be small and it would be painful not to see much of the stack because of the huge amount of whitespace around the error description up top.

I don't know that we need the padding around the content either. If we do (for looks) then maybe shrink it a bit?

In any case, great work :)

[shuma]

That looks great, when are you going to implement that? =)

[excid3]

👍

[rstacruz]

@shuma You can see it on my fork of better_errors. You may have to go back a few commits though: I've made a lot of changes since.

Looks like I'll need to go back to the drawing board on this one though :\

[rstacruz]

Hm, I think I want to go with a more minimal approach like this.

To accomplish this:

1. Stack traces will be hidden by default to give way to the most important thing here: the code and the REPL shell.
2. the default code shown will be the first application trace (currently, better_errors picks the first trace, whether it be an application trace or gem/framework trace).
3. there will be a mini-stack trace preview showing the application stack trace (not shown yet). clicking it will show the full stack trace in a sidebar.

Not sure on this approach, but after using the prototypes of the previous designs for a while, they did infact feel cumbersome (hi @jeromegn! you're totally right!), I find myself always wanting the top application stacktrace anyway so I figured it'd be best to showcase that better.

Personally, I love the combined box of a code preview + REPL + line location—very convenient since 80% of the time, it's what I'll be digging for anyway.

[rstacruz]

Here are other prototypes I've tried. I've tried a lot (heh), but haven't been able to take enough screenshots along the progress:

• Another early iteration
• Boxed content area — the previous designs felt too heavy and I tried to figure out ways to make them feel lighter.
• 'Lighter' feel without boxes — I figured that the box around the content area just feels like clutter, and it's much more compact without it.
• Full-sized sidebar — this is where I realized that showing stack traces will always feel 'heavy', no matter what. I tried smaller variations, they felt even sillier.

[shuma]

@rstacruz I really like the one with two boxes. It feels simpler. Great job mate!

[gabrielecirulli]

I love it! Awesome work so far!
Just a suggestion, have you thought about a horizontal stack trace?

Here's a quick mockup of what I had in mind:

The red dot is the selected stack frame (which by default would be the first of the application, like yours). If you hover your mouse over the other dots the text slides around and changes to the information of the other stack frames.
I think it would require less space and if you made it possible to scroll around horizontally it could give you quick access to stack frame without really taking up much space.

Just my 2 cents, let me know what you think 😄

[haileys]

@rstacruz I like the most recent iteration, but I do feel that the stack trace should remain prominent.

[jeremyw]

I agree @charliesome -- I think the stack trace is much more important than the variables.

[negativetwelve]

I was just going to fix the lack of word-wrapping in the variables area but it looks like that is irrelevant if you guys are planning on redoing the whole design.

[rstacruz]

@gabrielecirulli I think it's too simplistic. A common use case I run into is scanning through the stack trace and seeing which ones are from controllers, and that is pretty inconvenient to do with something like that.

@negativetwelve Go ahead! There's no guarantee this will be completed properly or accepted in the end, this is still just a proposal; at least, it's going to be!

[rebyn]

This is pure awesome. +1

[rstacruz]

Just curious: how would you guys feel about a single-column mode?

(it should be possible to make a 1column/2column toggle later on.)

[9mm]

my .02 cents:

1. I use the params hash a lot, it would be sweet to have that not buried at the bottom (at the top wouldnt be necessary, but just not last?
2. I noticed the page would sometimes break for every long lines, and there's no way to scroll. Perhaps set some word-wrap

[9mm]

And I definitely would say 2 columns > 1, that way if you don't need one column you can get to the other without scrolling.

[ream88]

What about a responsive layout? On my 13" screen a 1 column layout would be super nice, but on my 27" lots of space is wasted I think.

And yes, show me the params hash! Definitely!

[fredwu]

These are top notch designs, awesome work @rstacruz! I agree with @jeromegn though - white spaces need to be reduced for more condensed content - especially the stack traces. A "busy" layout in this case would work since we care much more about the actual content than the containers and their visual. :) But yeah, I love the overall feel of the designs.

[rstacruz]

What's up? Here's what I've settled into for now: This is a responsive (:smile_cat:!) layout I've put together. I pretty much like it a lot: it has the application-by-default thing I was talking about, the REPL+code+location is still quite prominent and in charge, and it can do both single- and double-column modes. Not to mention that it doesn't look too shabby.

The threshold is at 1100px browser width, so it's enough to look okay on a 13" laptop maximized, but it reflows once it's a little skinnier.

Application frames in the backtrace are highlighted, so you can easily glance to see which one's from the framework and which one's your own code:

This thing is solid -- it wordwraps at the right places and is quite optimized to the best I can right now.

I'd love to work more on the styling though, I'm not convinced all that black is the way to go... but as far as layout, this is pretty much the culmination of everthing I learned from all those iterations I prototyped.

Check it out for now with:

gem "better_errors", github: "rstacruz/better_errors", branch: "redesign"

[deanpcmad]

This looks great! Maybe Rails 4 could merge this plugin :)

On 10 Dec 2012, at 15:50, "Rico Sta. Cruz" notifications@github.com wrote:

What's up? Here's what I've settled into for now: This is a responsive (!) layout I've put together. I pretty much like it a lot: it has the application-by-default thing I was talking about, and it can do both single- and double-column modes. Not to mention that it doesn't look too shabby.

This thing is solid -- it wordwraps at the right places and is quite optimized to the best I can right now.

I'd love to work more on the styling though, I'm not convinced all that black is the way to go... but as far as layout, this is pretty much the culmination of everthing I learned from all those iterations I prototyped.

Check it out for now with:

gem "better_errors", github: "rstacruz/better_errors", branch: "redesign"
—
Reply to this email directly or view it on GitHub.

[neilmiddleton]

👍

[rstacruz]

Please don't mind the "referenced this issue" messages—I'm syncing from upstream, so when I pull-rebase from upstream, that shows up... grr.

@charliesome You may take note that indentation isn't taken care off properly in the HTML, this is intentional: I've stayed away from re-indenting existing code so you can study the diffs better.

Also, I think .repl should have a click handler that does $('.repl input').focus() so you can click anywhere in the REPL area to start typing. :)

[rking]

@rstacruz - Redesign looks interesting, but a) it's not rendering quite right for me on Firefox (the left and right columns overlap), but b) I want to strongly add my support for a 1-column design

Each frame should just have an expandable section that shows locals and the REPL. Side-by-side is an utter waste of space IMO

[rstacruz]

@rking Try again (bundle install), I've just pushed some Gecko compatibility fixes.

Expandable accordion-style stack traces seem like a good idea, but (1) it requires a big refactor of the JavaScript, and (2) I predict that it will become very cumbersome quickly.

[rking]

@rstacruz - Just checked it out. It definitely renders better, but there's a usability issue with large var dumps. Before, it was a big side-scrolley occasion, but there was a scrollbar. Now you just see truncated text and the only way (on Webkit and Gecko) to get to the information is to highlight and drag.

[rstacruz]

Hmm. This is how unreasonably-large vardumps are supposed to look like: notice how it wraps nicely (it should also respect newlines, too). How does it look like on your end?

[rking]

@rstacruz - Yep, the large dumps are usable in the latest master here at charliesome/better_errors

[shime]

Great work, @rstacruz. Thanks man!

[kossnocorp]

@rstacruz thanks for that! Btw is it possible to override layout?