Should SQL Server tools target wide screen formats instead of portrait formats?

There was a short discussion on the SQL Down Under mailing list this morning about screen resolutions for working with the SQL Server tools. In particular, the issue was about how unusable the tools are on the 1366×768 resolution notebooks that now seem to be the most common. While finding a notebook with an appropriate resolution is obviously the answer at this time, I started thinking that the product itself needs to address this.

SQL Server tools currently target a portrait 4:3 shape for minimum window sizes. Increasingly, portrait 4:3 format monitors are disappearing from sale.

While I loved the standard portrait orientation and prefer to work in it, the world has decided that watching DVDs on computer screens is more important than real work. So sadly, I think the SQL Server tools should now target wide screen formats by default. If you think, as I do, that the SQL Server tools should now be designed to be at least workable on 1366×768, vote here: https://connect.microsoft.com/SQLServer/feedback/details/636373/sql-server-tooling-should-target-wide-screen-form-factors#details

10 thoughts on “Should SQL Server tools target wide screen formats instead of portrait formats?”

  1. Isn't the new SSMS in 2011 written using WPF the same as VS2010 to allow for better resolution independance and more advanced UI?

  2. I raised this Connect item a few years ago when I tried out large fonts on a laptop at 800×600.  The item is marked as fixed, though clearly it is not.
    http://connect.microsoft.com/SQL/feedback/ViewFeedback.aspx?FeedbackID=297955
    The big problem is when there are OK/Cancel buttons off the screen to the right that you can't see.  These dialogs are not resizable and not really movable because you can't drag the title bar off the top of the screen.  And most don't have keyboard shortcuts for OK/Cancel that you could remember.  So you have to use tab and cross your fingers in order to engage the desired action.
    The easy answer is to increase the screen size (you are right that 4:3 laptops are going away, but so are laptops that don't support much higher resolution than 1366×768).  But I agree that a lower resolution is more optimal for folks who have trouble reading smaller fonts.
    What I think it comes down to is having a more broad testing matrix, but without incurring huge QA overruns. Make the *developers* do this QA as a part of the development process, by using the worst case scenario / lowest common denominator configuration.  If the engine team writes their stuff on case-sensitive collations, we won't have bugs in system procedures that only turn up on those collations.  And if the SSMS team designs their UI dialogs on 640×480, they might get annoyed, but we won't see any dialogs where we can't find the OK button.

  3. Hi Aaron,
    I recall that they had a default for minimum window size but my recollection was also that the default was 4:3 ratio based. I think they need to have a 16:9 ratio based minimum now and they should test for usability on 1366×768.
    Regards,
    Greg

  4. Justin, a lot of the dialogs use the same old code, even if they're launched from within the newer Visual Studio shell (check out the Tools|Options screens or the Agent job property dialogs, for example … they haven't changed a bit).  This "one-size-fits-the-developer's-resolution-so-ship-it" mentality is also true for a lot of extraneous moving parts that have nothing to do with SSMS… Setup, Upgrade Advisor, Best Practices Analyzer, Profiler, etc. etc…
    I should do another round of testing with Denali in 800×600 or 640×480 and see how much of the product actually becomes unusable.  I don't think there will be much at all that has been gained by using the new shell, at least in terms of accessibility for lower monitors.  For bigger monitors and multiple monitors, I agree with you completely.

  5. Greg, IMHO all they have to do is test for minimal height.  They are never going to go over on the width, regardless of aspect ratio.
    There are other issues too, such as how dialogs are laid out – again it proves that they do not test on 1024×768 or 1366×768, never mind with higher DPI font settings.  I'd be surprised if they do any testing on laptops at all, to be honest.  Check out this one from the CU patch program (still this way in 2008 R2):
    http://connect.microsoft.com/SQL/feedback/ViewFeedback.aspx?FeedbackID=402978
    http://www.aaronbertrand.com/voodoo/patch_ss1.png

  6. I've been using VMs a lot recently for testing and have not been maximising the screen hence loosing space at top and bottom. There's a few apps out there that don't work on short screens

  7. My notebook is 1600×900 and I have no problem with the tools. My last notebook, at 1280×800 was also fine from my point of view. So I'm not sure what the issue is — does something change at other resolutions?

  8. Hi Adam,
    Yes, as Aaron said, the biggest problem is the 768 height. The OK and Cancel buttons on many dialogs can't be reached except by guesswork. And this height for notebook resolution is becoming really common.
    Regards,
    Greg

  9. I opened a Connect item to report that I get screen artifacts and tearing in SSMS for SQL 2008, when the SSMS window is nearly the width of my screen.  
    My screen resolution is 1920×1200.  MS closed the issue as basically "We don't care".  I see repeated scroll bars and the screen can become unusable.  I included screenshots with my Connect issue — the problems do get captured in a screenshot.
    I even tried changing video adapters to use one with a completely different video chipset.  (AMD to NVidia or vice versa.)  I hope this gets fixed eventually.

Leave a Reply

Your email address will not be published.