Skip to main content

Large Screens? Not For Me!

Thinking that I've lost it? No, you read that title right, I'm making a case for small screens (albeit many of them).

I've recently been given a 27 inch iMac by my advisor. This does nothing to change my feelings, I still think that Macs suck, and that they are one of the most gimped excuses for a computer. But that's for another post. Right now, I'll be making a case against big displays, and that holds for any computer, not just Macs.

The argument starts off with Fitt's Law. This is a law which relates the time taken to point at a target using a pointing device like a mouse, and relates the time to the log of the distance to the target divided by the width of the target. For convenience, I've listed the law, in mathematical form below.

Basically, all that it says is rather obvious. If you're trying to point at a tiny target located a mile away, you're screwed. But that's what happens with every large display. Note that I'm talking about large in terms of pixels, not physical size. It's perfectly fine to use a 1280x720 projector projecting on an IMAX screen (okay, IMAX fans, I've downgraded the IMAX effect, but it's just to make a point).

With a screen that's huge, in terms of number of pixels, your targets (like simple close, minimise or maximise buttons) become too tiny and too far away. This means a hell lot of wrist movement, when using a mouse, and that's never a pleasure.

The next thing is in terms of distractions. Mostly, I like to have just one thing open on my screen at a time, unless I'm referring to something else; but at any time, I just have one task open on my screen, and that helps focus by removing all distractions. With a small screen, there really is no place to keep too much stuff on the screen, and I end up using multiple workspaces. As a result, sometimes, during coding binge sessions, I end up writing code for hours on end (sometimes starting just after lunch, and continuing till dinner), never once switching to my workspace containing GMail or Facebook.

With large displays, I invariably end up having a browser open next to vim, and that's never good. It means more distractions, especially when you see the tab that prints out the number of notifications (yes, I know I can log out, but I'm addicted to the web).

Frankly, I don't really need so many pixels. I code in Vim, and that fits inside an 80x24 console. I could be fine with just a 10 inch netbook. The only time when I need extra space is when I refer to something else, like C++ reference, or StackOverflow.

So what's my ideal setup? A wide array of monitors (actually, just two), one with a browser open for reference, and another where I do all my work, ideally separated by a good amount, so that my primary monitor is right in front of me, and the secondary (used for reference) does not bother me unless I consciously look at it. Of course, it's with the cost factored in. All I'm saying is that I'd rather have two 17 inch monitors than one 27 inch monitor.

Comments

Popular posts from this blog

ERROR_SUCCESS

ERROR_SUCCESS. This macro would be familiar to all those who have done some programming in WIN32. It is the output of the GetLastError() function to check the thread's last error state when no error has occurred. Weird, isn't it? I mean, if it is a success, then why is it marked as an error in the macro? This is one example of a badly made API. APIs are considered bad when programming in them becomes non-intuitive. Software is said to be bad (or said to suck) when it seems counter-intuitive to the user. There is one very simple example of this. Start notepad. Type in any text. Click on close. The message that you see is: This makes no sense to me as a user. Of course, the programmer follows the approach that he creates a temporary file called Untitled , and in that file he allows the user to make all his changes. But how am I, as a user to understand that? A similar disconnect occurs even between two different programmers. That is why it takes a whole lot of effort to make

On Harry Potter and why I dislike the series

There could not be a better time for this post. There could not have been a worse time for this post. Now that the penultimate movie of the series is out, and my facebook wall filled with people who loved the movie. But this is something I really wanted to say, and I shall say it anyway. Harry Potter is pathetic literature. Now, you must be wondering why I say that. There are many reasons. Firstly, the storyline itself is flawed. When a writer sits down to write anything, he/she must set up some essential rules about what is happening. These rules must remain constant irrespective of how many times he/she changes his/her mind. This is so that the readers are allowed to have some sensibility in what they are reading. In the fourth book, Rowling goes ahead and kills Cedric. Then, at the end of the book, the horseless carriages are there again. Nothing special. We all knew that they are horseless. But then comes the fifth book, and BAM, the horses are actually winged beasts that only thos

Elements of a Story: The Whispers

I'm compelled to begin each post with a meta. That way, my blog posts seem less like essays or dissertations, and more like diary entries, or web logs. So here goes... I started this blog a little over a year ago. The main purpose of this blog was to experiment with styles of writing, and find an effective outlet for all the subjects I wish to rant about; saving my classmates the agony of having to listen to them. As I wrote this blog, I've experimented with so many styles, and have received comments claiming that my work is a shameless copy greatly inspired by so-and-so author/work. Fact is that I simply chanced upon that style. I read, so obviously, my work shall reflect the styles of those I admire, but I've worked out so many styles without even knowing that they exist, only to be informed of them later. Recently, I've been struck with the seeming absence of whispers as an element of a story. The more I've thought of the subject, the more I've been convince