Today brings and end to my focus on Python. My adventures into programming with python and pygame haven't ended, but I'm doing a bit of transition (just like I promised : ).
I recently started a new job (large video game developer) in a new city (on the west coast). I want to make an effort to start writing more, and this is my outlet. However, I'm so busy with all of these new things that I don't do enough programming in my spare time to produce many posts.
So instead, I'll talk about video games, software, and general technology topics. Of course, anything I say here is in no way representative of my employer.
Hope you enjoy the new cipher.sense!
17 January 2009
Glossy Finishes and Translation of Design
Jeff Atwood recently posted about the importance of pearls on a pig.
As you may guess, Jeff and I disagree. In my opinion, the "new" Windows 7 (beta) calculator has not had a UI redesign. It's just been themed so it matches the new Windows look.
If they actually did a UI redesign, then it should result in a BETTER INTERFACE. Why would you ever change your interface if you are not going to improve it?
Let's look at the "new" interface: All of the buttons are the same size. The primary input buttons (numbers) are white, except for some strange blank key next to Mod. (Anyone know what that's for?) In order to maintain the layout of the standard calculator and keep the equals on the bottom right, the operators are split on either side of the numbers, instead of being grouped. The hex-exclusive numbers (A-F) are not obviously greyed out in Decimal mode. (They look the same as the decimal button, which shouldn't be disabled at this point.)
Of course, this is still beta software at this point and things may be improved. Also, I'm not using the calculator. My impressions are based on screenshots. Lifehacker reports that Microsoft has added some nice functionality to the calculator, but what if they took a different approach to design?
How about having a keyboard-focused mode? When I use a calculator, I rarely use they mouse, but I never remember keyboard shortcuts for square root, memory, toggle negative, or several other complex functions (do they exist?). Having those easily accessible would be far more useful. Have an user-friendly way to store multiple numbers.
But instead, the new Calc just looks prettier. Garbage! I love pretty, but pretty without function is a waste of time.
That said, I haven't used a really good calculator app. I often just open a python interpreter because at least then I can store several variables and I get a better computation history.
Calc looks like a real calculator. Because we lose the tactile input, it's harder to use and (for me) even a simple command prompt is easier to use. Replicating the design of real-world objects has some utility in software design, but there are many cases where it is misguided. How many people remember where all the keys are on a (real) calculator? If they were laid out differently (but still sensibly), would it be that much harder to use? No. While your muscle memory would be impaired, it doesn't make that big of a difference. And since computer software throws all of that muscle memory out the window, it doesn't matter.
So if you're designing your app to look like a real-world object, think again. And read the Design of Everyday Things.
As you may guess, Jeff and I disagree. In my opinion, the "new" Windows 7 (beta) calculator has not had a UI redesign. It's just been themed so it matches the new Windows look.
If they actually did a UI redesign, then it should result in a BETTER INTERFACE. Why would you ever change your interface if you are not going to improve it?
Let's look at the "new" interface: All of the buttons are the same size. The primary input buttons (numbers) are white, except for some strange blank key next to Mod. (Anyone know what that's for?) In order to maintain the layout of the standard calculator and keep the equals on the bottom right, the operators are split on either side of the numbers, instead of being grouped. The hex-exclusive numbers (A-F) are not obviously greyed out in Decimal mode. (They look the same as the decimal button, which shouldn't be disabled at this point.)
Of course, this is still beta software at this point and things may be improved. Also, I'm not using the calculator. My impressions are based on screenshots. Lifehacker reports that Microsoft has added some nice functionality to the calculator, but what if they took a different approach to design?
How about having a keyboard-focused mode? When I use a calculator, I rarely use they mouse, but I never remember keyboard shortcuts for square root, memory, toggle negative, or several other complex functions (do they exist?). Having those easily accessible would be far more useful. Have an user-friendly way to store multiple numbers.
But instead, the new Calc just looks prettier. Garbage! I love pretty, but pretty without function is a waste of time.
That said, I haven't used a really good calculator app. I often just open a python interpreter because at least then I can store several variables and I get a better computation history.
Calc looks like a real calculator. Because we lose the tactile input, it's harder to use and (for me) even a simple command prompt is easier to use. Replicating the design of real-world objects has some utility in software design, but there are many cases where it is misguided. How many people remember where all the keys are on a (real) calculator? If they were laid out differently (but still sensibly), would it be that much harder to use? No. While your muscle memory would be impaired, it doesn't make that big of a difference. And since computer software throws all of that muscle memory out the window, it doesn't matter.
So if you're designing your app to look like a real-world object, think again. And read the Design of Everyday Things.
03 January 2009
The Problem with the Monty Hall Problem
If you're not familiar, the Monty Hall problem is a frequently discussed (in probability) and often confusing problem (for almost everyone).
Jeff Atwood recently posed a question to his readers that involves similar reasoning. The poor phrasing of Jeff's question and the response in the comments got me thinking about old Monty again.
I think the problem is not just the wording of the boy/girl part of Jeff's question, but when you get your information. The 2/3 answer assumes that you are making a prediction. This is the same problem with the Monty Hall problem.
Exploring the Problem
Say I was going to flip a coin twice. If I flipped it once and it was heads, the second flip is not more likely a tail since the events are independent.
However, if I said I was going to flip a coin twice and I want you to bet on the result before I flip any coins. If a coin is heads, you bet what the other coin will be, and if one is tails you bet what the other will be. You should be the opposite (for heads bet tails).
If a coin is going to be heads, it's more likely that the other coin is tails. (Possibilities: HT TH HH)
Or, to make this more like Jeff's original problem, you can only bet assuming one coin is heads. If both are tails, then we throw out that round (and this action is part of what makes the result not 50%).
This explanation also demonstrates why programming a simulator and examining the results is misleading. The simulator is working on predictive probability. If you wanted your simulator to work without predictive probability, then you'd have to program it at the point the decision is made. You should assume the initial condition (that you chose the left door and the middle door was shown to have a goat). Then decide whether to switch or stay.
I'll leave the programming as an exercise for the reader : )
Jeff Atwood recently posed a question to his readers that involves similar reasoning. The poor phrasing of Jeff's question and the response in the comments got me thinking about old Monty again.
I think the problem is not just the wording of the boy/girl part of Jeff's question, but when you get your information. The 2/3 answer assumes that you are making a prediction. This is the same problem with the Monty Hall problem.
Exploring the Problem
Say I was going to flip a coin twice. If I flipped it once and it was heads, the second flip is not more likely a tail since the events are independent.
However, if I said I was going to flip a coin twice and I want you to bet on the result before I flip any coins. If a coin is heads, you bet what the other coin will be, and if one is tails you bet what the other will be. You should be the opposite (for heads bet tails).
If a coin is going to be heads, it's more likely that the other coin is tails. (Possibilities: HT TH HH)
Or, to make this more like Jeff's original problem, you can only bet assuming one coin is heads. If both are tails, then we throw out that round (and this action is part of what makes the result not 50%).
This explanation also demonstrates why programming a simulator and examining the results is misleading. The simulator is working on predictive probability. If you wanted your simulator to work without predictive probability, then you'd have to program it at the point the decision is made. You should assume the initial condition (that you chose the left door and the middle door was shown to have a goat). Then decide whether to switch or stay.
I'll leave the programming as an exercise for the reader : )
Subscribe to:
Posts (Atom)