Is it not blindingly obvious that both are true? For certain things, maintaining your anonymity is beneficial and allows you to express your opinions without fear of reprisal. For other things, signing your name to your opinion forces you to put a certain amount of thought into your sentiment and be prepared to defend it.

So, while using my Facebook account to comment on TechCrunch (just like posting on my technical blog under my real name) is fine, you’re not going to see me regularly posting on 4Chan or even Reddit under my real name, because sometimes I want to sign my name, and sometimes I don’t.

Two weeks of car shopping has driven home two big points for me: User interface matters. Car companies aren’t all that good at it.

Really? Because last I checked, car companies are pretty good at user interface. It takes me less than 5 minutes (in any car) to figure out to make it start, go forward, reverse, stop, turn left, right, turn on and off the radio, change the station, change the volume, turn on the air, heat, defrost, adjust the seat, mirrors, steering wheel, put on a seat belt, and start driving. And yes, there are a lot of buttons. So?

On the dream in code forums, one person asks a similar question:

A new car can have over hundred controls. For example, 10 controls for radio, 5-10 for heating and ventilation, 10 for windows, 10 for wipers, washers and so on. Most people can master these very quickly. Why is it that the car with so many controls is easier to use than a video recorder that has few controls. What makes the car’s interface so good and that of the video recorder so bad.

I love this answer:

…a car’s buttons are shallow in depth hence why there are so many, and a camcorder has fewer buttons that do more things (depth) in conjunction with other buttons.

The last thing I would want to do, while driving, is deal with some sort of menu tree when all I want to do it turn on my headlights.

Apple certainly does create some exceptional user interfaces – the iPhone is obviously a shining example of that. And yet 8 out of 50 states prohibit handheld use of a phone while driving, and 30 out of 50 states prohibit text messaging while driving. (http://www.ghsa.org/html/stateinfo/laws/cellphone_laws.html) This is because devices which require concentration to use necessarily divert your attention from the more pertinent task, which is driving.

Humans think and remember in physical space; we have a well developed sense of spatial memory. This is what allows us to type while not looking at the keyboard, pick something up off of the desk without looking, remember where we left our keys (well some of us), and so on. This is also what allows us to reach down to the volume knob and change the volume on the radio without significant distraction from the task at hand (driving). We know where the volume knob is, and we know which way to turn it. It is a physical object in physical space and our brains have evolved to be able to interact with such objects without using a significant amount of focus.

When you change that user interface so that there is simply one button to enter a virtual menu of options, sometimes many levels deep, we’ve suddenly made the task one that requires a significant level of concentration. We can’t rely on our built-in spatial memory any more, because multiple functions are mapped to the same physical space. At this point, we have to build a representation in our heads to keep track of where in the virtual space we are. Which app am I in, which submenu am I on, where are the buttons on the screen, and so on. We’ve gone from something as familiar and simple as a knob to something that requires (comparatively) a great deal of thought.

Of course, car manufacturers have tried to reinvent the automotive user interface before. In fact, several have them have even developed some very Applesque interfaces. BMW’s iDrive is probably one of the best known of these, and although it went through a number of revisions, and some users were quite fond of it, the overwhelming response was negative.

The design rationale of iDrive is to replace a confusing array of controls for the above systems with an all-in-one unit…iDrive has caused significant controversy among users, the automotive media, and critics. Many reviewers of BMWs in (automobile) magazines disapprove of the system. Criticisms of iDrive include its steep learning curve and its tendency to cause the driver to look away from the road too much.
http://en.wikipedia.org/wiki/IDrive

This article on cnet discusses iDrive (as well as Audi’s MMI and Mercedes-Benz’s COMAND systems) in some detail. In the article, Wayne Cunningham rates each of the systems according to Jakob Nielsen’s Usability Heuristics. I find this interesting, as the second heuristic is “Match between system and the real world”, which is something that buttons and knobs are obviously quite good at, and nested menus of options are not.

Of course, if this type of design would function so poorly in an automobile, why do we love our phones, laptops, tablets, televisions, and video games so much in other facets of our lives? The obvious answer is that we aren’t driving while using them, and we want to be engaged with our technology. This should quite obviously lead not to the question of how to redesign the interface of the automobile, but how to redesign the process of driving. Since we are not able to use these devices while driving, we can choose to either design the device to suit the task (as discussed above), or modify the task to suit the device.

It isn’t Apple that is likely to succeed in this venture. The Distronic Plus cruise control system that Mercedes Benz is using is a step in the right direction. Google’s work on cars that drive themselves are even more so. Optimistically we have 10 years before cars that can drive themselves are available. At that point the game changes. The design of our cars won’t be constrained by the requirement that the driver maintain focus on the road.

Maybe then Apple will rock the world with its groundbreaking automotive interfaces, but until then, leave my knobs and buttons alone.

Take this basic code:

This is a somewhat contrived example, but basically, we want to give obj2 the value that obj1 has. We do a simple check to make sure that they aren’t the same before bothering to do so. This is more important in code where you’re setting a property (rather than just a variable) which may execute some other code, like setting a dirty flag or even writing to persistent storage.

Anyway, the code executes, and obj2 is assigned the value of obj1 (“a”). So what’s the problem? Let’s change the value of obj1 to DBNull.Value.

Should be no problem, right? The AssignValue sub will be called and obj2 will be assigned a value of DBNull.Value. Except that it doesn’t. Actually, what you get is an exception that states:

{“Operator ” is not defined for type ‘DBNull’ and string “b”.”}

Well, crap. Ok, we’ll check for DBNull.Value in our AssignValue sub.

Run our code again and everything works great. Wait, what if obj1 and obj2 are both set to DBNull.Value?

Another exception, of course!

{“Operator ” is not defined for type ‘DBNull’ and type ‘DBNull’.”}

Ack! Seriously? Ok, let’s change our AssignValue sub again. We’ll check to see if obj1 is DBNull while obj2 is not, or obj2 is DBNull while obj1 is not, or both obj1 and obj2 are not DBNull and not equal to each other.

Wow, we’ve finally managed to implement what should be a simple comparison and we only had to do 5 comparisons to do it. Maybe it’s just me, but this seems excessive for what we’re trying to do. I understand that it’s necessary to represent null database values in our objects, but generics (and therefore Nullables) were introduced in .NET 2.0 – stop using DBNull.

1. It’s a very, very, bad idea to attach handlers to the window scroll event.
2. Always cache the selector queries that you’re re-using.

If you’d like to explore this topic further, this jQuery performance optimization video by Addy Osmani is great. You’ll need to block off half an hour or so to watch it, but it offers some excellent tips that are really useful if you’re in and out of jQuery on a regular basis.

It’s often convenient to redirect mobile visitors to the mobile pages only on the first request in their browsing session (and not on every request in their session), because:

1. You can then easily allow mobile visitors to access your desktop pages if they wish – just put a link on your master page that goes to “Desktop version”. The visitor won’t be redirected back to a mobile page, because it’s no longer the first request in their session.
2. It avoids the risk of interfering with requests for any dynamic resources shared between desktop and mobile parts of your site (e.g., if you have a common Web Form that both desktop and mobile parts of your site display in an IFRAME, or certain Ajax handlers)

To do this, you can place your redirection logic in a Session_Start method. For example, add the following method to your Global.asax.cs file…

I frequently browse the web on my Android phone – in fact, I probably browse the web more on my phone than I do on my computer. I don’t want my mobile/standard preference stored in the session. I want it stored in a persistent cookie so that I don’t have to reset my preference every time I visit your site. This isn’t even difficult – here is an excellent reference to using cookies with .NET.

The section regarding the different methodologies for presenting mobile specific pages talks about using different Razor views for mobile/standard:

Since the Model-View-Controller pattern decouples application logic (in controllers) from presentation logic (in views), you can choose from any of the following approaches to handling mobile support in server-side code:

1. Use the same controllers and views for both desktop and mobile browsers, but render the views with different Razor layouts depending on the device type. This option works best if you’re displaying identical data on all devices, but simply want to supply different CSS stylesheets or change a few top-level HTML elements for mobiles.
2. Use the same controllers for both desktop and mobile browsers, but render different views depending on the device type. This option works best if you’re displaying roughly the same data and providing the same workflows for end users, but want to render very different HTML markup to suit the device being used.
3. Create separate areas for desktop and mobile browsers, implementing independent controllers and views for each.This option works best if you’re displaying very different screens, containing different information and leading the user through different workflows optimized for their device type. It may mean some repetition of code, but you can minimize that by factoring out common logic into an underlying layer or service.

If you want to take the first option and vary only the Razor layout per device type, it’s very easy…

The Razor views look very slick, and unfortunately, I haven’t had much time to play with them yet. Telerik recently posted a .NET Web Forms Views -> Razor converter on GitHub that looks like it would give you a good kickstart if you’re trying to switch over a project that you’ve already started.

click for results

I’m pretty happy with that 75%, but I think I’ll use it much like this programmer competency rating as a yardstick for improvement.

Do you want to find out what your reading level is? Click here to search.

http://fob.po8.org/student-code

This is slow and inefficient:
SELECT @var1 = tab1.col2
FROM tab1
WHERE tab1.col1 =
  (
    SELECT tab2.col2
    FROM tab2
    WHERE tab2.col1 =
    (
      SELECT tab3.col2
      FROM tab3
      WHERE tab3.col1 = @par1
    )
  )

This is better and much, much faster:
SELECT @var1 = tab1.col2
FROM tab1
INNER JOIN tab2
  ON tab1.col1 = tab2.col2
INNER JOIN tab3
  ON tab2.col1 = tab3.col2
WHERE tab3.col1 = @par1

My previous blog entry regarding Amendment 1 was on the first page of google’s search results for most combinations of Georgia, Amendment, November 2nd, etc. It was the top search result in many cases. I assume it was largely the same for Bing and Yahoo, although to be honest, I haven’t really verified.

That blog entry got a little less than 3,000 hits by November 2nd (thank you WordPress site stats). So assuming that every one of those page views was by a registered Georgia voter (which is beyond unlikely), roughly 0.1% of people that voted on that amendment read that blog post.

Now quite obviously, a very large percentage of people get their news from television, newspaper, friends, and other sites, but still – 0.1% bothered to do a simple search to research the issues that they were going to vote on? Really?