915414 - The devtools need a padding diet

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Brandon Benvie [:benvie]]

Attachment: devtools-padding-diet.png

While using the devtools it is often the case that screen real estate is at a premium, with the content competing with the toolbox for space. We use padding unnecessarily in a number places that doesn't necessarily help readability or aesthetics.

Comment 1

[Paul Rouget [:paul]]

This will be addressed by the new flat design.

Comment 2

[Paul Rouget [:paul]]

(In reply to Paul Rouget [:paul] from comment #1)
> This will be addressed by the new flat design.

not really…

Comment 3

[Paul Rouget [:paul]]

Darrin, how can we make out tools look more "dense"? Looking at Chrome (http://i.imgur.com/uglLeGv.png) our tools look really big.

Comment 4

[Brian Grinstead [:bgrins]]

Bug 942292 will save a little bit of space on the toolbar (breadcrumbs, sidebar tabs, console filters, etc)

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

It sucks that we have margin/padding on buttons in the debugger between the icon and the border of the button, and then *also* have padding/margin between the border of the button and the toolbar the button is in. If we had a flat design, we could consolidate those two cases of padding/margin into a single case and get some density there.

Comment 6

[Darrin Henein [:darrin]]

Im not against revising the mockups shorlander had originally provided to optimize for space at all, in fact I think it's a great idea. 

How do we want to approach this? For what I can see, there are many areas which could benefit from some reduced padding (table headings, etc.), as well as areas (buttons, toolbars) which could benefit from a slightly more involved visual redesign, like removing borders/margin on buttons, slimming the tab bar, etc.

One option is for me to provide some exemplary mockups which show how/where we can start saving space, and what I would change in relation. Thoughts?

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to Darrin Henein [:darrin] from comment #6)
> Im not against revising the mockups shorlander had originally provided to
> optimize for space at all, in fact I think it's a great idea. 
> 
> How do we want to approach this? For what I can see, there are many areas
> which could benefit from some reduced padding (table headings, etc.), as
> well as areas (buttons, toolbars) which could benefit from a slightly more
> involved visual redesign, like removing borders/margin on buttons, slimming
> the tab bar, etc.
> 
> One option is for me to provide some exemplary mockups which show how/where
> we can start saving space, and what I would change in relation. Thoughts?

If you can identify the things that just need less padding or other basic changes, I can work with you on making sure we get the values set correctly.  If you could come up with a few mockups as you suggested this would be a great start.

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Darrin Henein [:darrin] from comment #6)
...
> One option is for me to provide some exemplary mockups which show how/where
> we can start saving space, and what I would change in relation. Thoughts?

I would love to see this! 

I do have an additional concern, particularly around how the tools look on 1366x768 ( very common  low-rez laptop display ) vs 1080p or higher LCDs vs HiDPI / retina. Chrome is I think TOO compact on really large displays, for example the new iMacs with 2560x1440 displays.

I see 3 buckets of devices:

 - low rez ulta-portables, that may use external monitors
 - retina macbook pros ( a small but influential group )
 - a huge swath of people running PC laptops running 1080p screens at 14/15" screen size who likely need to squint to read regular sized text

What do you think about being responsive to different screen sizes in terms of padding and font size and other readability factors?

Comment 9

[Victor Porof [:vporof][:vp]]

How about adding a radio group in the options panel for specifying the spacing (along the lines of "compact", "comfortable" etc.), like gmail has (or used to have) for their email interface?

I do agree that handling this automatically might be a better idea, but I always hated what gmail decided was the best padding for my screen :)

Comment 10

[Paul Rouget [:paul]]

(In reply to Victor Porof [:vp] from comment #9)
> How about adding a radio group in the options panel for specifying the
> spacing (along the lines of "compact", "comfortable" etc.), like gmail has
> (or used to have) for their email interface?
> 
> I do agree that handling this automatically might be a better idea, but I
> always hated what gmail decided was the best padding for my screen :)

Design failure :) Let's not ask the user to take this decision.
I'm pretty sure we can come up with ways to optimize our design.

Comment 11

[Tim Nguyen :ntim]

Things to consider :
- Give some minimum padding to get minimum breathing space
- Use borderless buttons to make things look thinner

Comment 12

[Brian Grinstead [:bgrins]]

> - Use borderless buttons to make things look thinner

Bug 952100 is opened for reskinning the buttons to match the mockups (which are a bit thinner).

Comment 13

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Victor Porof [:vporof][:vp] from comment #9)
> How about adding a radio group in the options panel for specifying the
> spacing (along the lines of "compact", "comfortable" etc.), like gmail has
> (or used to have) for their email interface?
> 
> I do agree that handling this automatically might be a better idea, but I
> always hated what gmail decided was the best padding for my screen :)

The counterargument is that the tools could use more padding for readability on large screens but really suffer on small screens, eg http://note.io/1n30Edv (1080p) vs http://note.io/1milMbL (1366x768)

( screenshots using Fx30, apologies if things have changed since, doesn't seem like it )

I think Nick's point about the debugger buttons is also valid for controls within the tools, that any extra padding is always a problem.

Comment 14

[Brian Grinstead [:bgrins]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #5)
> It sucks that we have margin/padding on buttons in the debugger between the
> icon and the border of the button, and then *also* have padding/margin
> between the border of the button and the toolbar the button is in. If we had
> a flat design, we could consolidate those two cases of padding/margin into a
> single case and get some density there.

(In reply to Jeff Griffiths (:canuckistani) from comment #13)
> I think Nick's point about the debugger buttons is also valid for controls
> within the tools, that any extra padding is always a problem.

Just a note in regard to the complaint of double paddings, this is being updated in Bug 942292.

Comment 15

[Brian Grinstead [:bgrins]]

The network panel headers are shorter as a result of Bug 942292

Comment 16

[Brian Grinstead [:bgrins]]

I think we should close this bug, since the extra paddings have now been removed.  If we want to discuss changing paddings/font sizes/readability values based on different resolutions, let's do that in another bug or on the list.