 | |  |
|
| |
April 30th, 2008
How many browsers do you test with? I’ve got five… and all on the same computer at the same time. Of course, we have Firefox, Opera, and Safari. Those are usually the easy ones to get right. But wait there’s two more.
You can install the beta of IE8 right now, but doing that takes IE7 off your system, right? Not unless you have IE Tab installed. IE Tab is a Firefox add-on that loads the IE ActiveX control inside of a Firefox tab. But not from IE8 that you just installed, it loads the IE7 control. Sure you can emulate IE7 inside of IE8, but you need to restart the browser to enable and disable emulation. With the IE Tab trick, you can develop web apps and have all five browsers up at the same time.
Of course, I’m not saying that you shouldn’t test on the same browsers in other platforms. This is just a great place to start.
April 28th, 2008
With my alarm buzzing at 6:00, I ensured my arrival at the Gene B. Glick Junior Achievement Center by 7:00. Now if only I had bothered to check the temperature before putting on my Underoath T-shirt and cargo shorts, I wouldn’t have become a meat popsicle while waiting outside for the doors to open. If anything, my attire was my downfall…
Dramatic intro aside, we actually were waiting outside for about 20 minutes for the keymaster to open the doors so that we could start registration for the Indy Code Camp. I handled last names F-L, so if you were Faaita through Lyvers, then you dealt with me.
Anyway, registration went smoothly and so we all went to our first session. I attended Jeff McWherter’s talk on ASP.NET performance and optimization. I’ve only been in the ASP.NET game for a few months now, but I was already familiar with most of the standard tools like FireBug. Heck, I’ve even blogged about them. But I did learn about a neat little performance analyzer called ANTS Profiler. It can show you the amount time spent in each method as well as lots of other cool metrics:
Than I attended Michael Neel’s session on "Zen and the Art of Website Maintenance". I learned a lot about how they made samurai swords back in feudal Japan and so I thought my time might be better spent in Jeff Moser’s session "Better Know a Framework".

Jeff is the man and did a pretty darn good job. He showed code up on the screen the whole time (which was sadly the exception rather the rule). He basically just debugged through his sample app line by line explaining the classes and how the internals work. Nice job, Jeff! But the best part was definitely seeing who almost died each time Jeff threw a pair of InIn flip-flops through the crowd.

Next I went to Bill Steele’s "What’s New in Visual Studio 2008". After about five minutes, it started looking like the same content I had seen at other recent Microsoft events I’ve gone to, so I headed out and dropped by the speakers table. Shortly after, lunch came in the form of a butt load of pizzas. Mmm… good stuff. Next up, afternoon sessions!
Next on my plate was Alan Stevens‘ sessions on TDD with ASP.NET MVC parts 1 and 2. Alan is already well versed in ASP.NET MVC and TDD. That’s pretty obvious. Part 1 was mostly on the basics of MVC in the ASP.NET framework as well as the building blocks of TDD. Pretty interesting, but if you’ve stayed up to date with the blogs then you’d probably already know most of it. In Part 2 we dove into it further. Still good stuff, but my lack of sleep was starting to hit me. I enjoyed it nonetheless.
Lastly was Dan Rigsby’s session on Intermediate WCF. Jeff and I figured we could learn a little or at the very least get to harass Dan during the session. Both objectives accomplished! Dan’s a good guy though and rolled with the punches.
Overall I thought the code camp was a great success. Great job Aaron Lerch and the Indy NDA. I know it was a lot of work, but I definitely wouldn’t mind if there was a 2009 version.
April 25th, 2008
Should you ever allow a "Miscellaneous" category or section or tab or page in your application? When dividing your data up into different sections, do you always have a place for everything or do you have a place for most things and then everything else goes into the catch all "Miscellaneous" section?
Some applications use "Configuration" or "Options" to try and solve this problem. Visual Studio 2008 uses a "General" section:
"General" is not quite miscellaneous, but almost. These options don’t really seem to fit in the other subcategories of "Edit and Continue", "Just In Time", "Native", or "Symbols". So that at least seems to mean that they need their own section.
Firefox uses the same pattern in their Advanced section:
These options are at least grouped into sections, but they still don’t seem to fit into any of the other categories.
Outlook 2007 on the other hand has an "Other" tab:
This may as well have been called "General" as well. There’s no rhyme or reason as far as I can tell for the sections inside of "Other". Looks like another case of "Miscellaneous" to me.
In the fields of Information Architecture and Usability, a method known as card sorting is used to have potential users sort terms and labels according to how they would logically group them, in whatever order that might be.
In many cases, the users have a leftover category that they might simply label "Miscellaneous". Is this ok or is this just another usability issue to deal with and redesign later? Should "miscellaneous" never ever be allowed? Does inclusion of a miscellaneous category mean that your data isn’t organized in a intuitive way? Or will inclusion of a miscellaneous category just lead to users hunting around all the similarly titled sections until they finally check miscellaneous?
Or is that just too much of a Platonic ideal? Are there times where some fields simply don’t fit anywhere else? At some point do we need to throw up our hands and allow the wave of meaningless titles and labels flow?
April 22nd, 2008
Have you heard about Digsby? I was turned onto this by Scott Bauer and am a daily user of it now. Digsby is basically an email and social network aggregator:
It periodically checks your accounts for new messages, so that you don’t have to have all your different email accounts open (especially if you have more than one account at the same provider like Gmail which means you can’t have multiple tabs open and be logged into each account at the same time… but I digress). Via a flyout menu, you can quickly see an overview of all your unread messages and open, reply, or delete them right there. But that’s not the most intriguing aspect of Digsby. Where I see the most promise is the chat feature. You can put a widget on your blog which people that visit your site can interact with:
It tells the user if I’m online and if so allows them to start typing away. I’ll get a popup IM window via the Digsby client on my desktop and the chat has commenced. Google has a similar feature with their Google Talk embedded widget, but it’s much clunkier. Here’s Aaron Lerch’s impromptu description of it:
I got an IM via google talk with a big-@$$ web link, which I click and it takes me to a page that has a "launch talk" button, which pops a window that is the web version of google talk and includes a "Guest chat" tab.
Yeah… Thanks, but no thanks. I’ll stick with Digsby. Also, if you were paying attention you would have seen the "Digsby Widget 5/7" in the first screenshot. That tells me how many people are currently on my blog and whether they’re active or not. Sure, you can see that sorta stuff with Google Analytics or Feedburner:
However, unlike Google and Feedburner Digsby’s stats are in real time. Those are people that are on my site at this very second. I can even initiate the chat with them if I wanted to. Pretty sweet. Sure, that may not scale well in the future, but I’m a long ways from that being a problem…
Digsby is pretty full featured and supports Gmail, Yahoo, Hotmail, AOL, IMAP, POP, Facebook, MySpace, and Twitter… although for Twitter you’re really better off with Bitter
So if you break out of your feed reader and ever visit my blog, give the widget a try. I’m a nice guy. We can chat. Here I’ll give you a topic. Duran Duran is neither a Duran nor a Duran. Discuss…
April 17th, 2008
When you sit down to design a user interface, where do you start? Do pull up Visual Studio and start creating forms and dragging controls onto them? Do you go talk to the server guys to see what they need and then just go for it? Or do you wait until the design phase is done and then create a dialog for each class in the system? Doesn’t sound pretty, does it? Well, have you ever pushed away the keyboard and pulled out a pencil and paper? Believe me, I’m no fan of the old school input methods (I can barely read my own handwriting), but there may be some use for that dead tree after all.
With paper prototyping, you can design user interfaces (graphical or even hardware) and get real life user input about the usability of that interface without ever touching the mouse. Basically, the drill is to draw the different states and dialogs that your UI contains on several pieces of paper and then observe as users interact with them. During the session, a person playing the role of the computer puts down the appropriate pieces of paper as the user physically touches and interacts with UI, so that the paper prototype acts as the real application would… just in ink or graphite. Nothing in the UI (layout, navigation, etc) is the explained to the user beforehand. The user is simply given a task and is asked to perform the task on the paper prototype.

Right now, you might be thinking “Well, what the heck can you learn from this? It’s only paper!” That’s true, but the fact that it’s paper is key to the whole operation. The prototype only takes as much time and effort to develop as it takes for you to draw the dialogs. On the paper, the user can physically touch the buttons, links and other clickable controls and can even write character input into the appropriate controls. Better yet, the paper prototype can be quickly refined to fix discovered problems with the interfaces… sometimes even during the session itself! “We saw you had problems finding the place to input the name. Would you try it again with *this* prototype.” How cool is that?

So what sorts of problems can you really find from some scraps of paper? Well, let me tell you, dear reader:
Confusing UI and concepts
There are times when you really don’t know how to express your interface so that the targeted users of your application will be able to easily grasp and use the interface. Or worse, you may think that you have the interface nailed down… except that you don’t.
Maybe you think that adding an object by choosing the type of object and then clicking the “Add” button followed by configuring the object is a perfectly reasonable set of steps for the task at hand. Well, your users may disagree. Heck, your users may not even be able to find the dialog to add the object in the first place. They may even be “clicking” the options link in the upper right corner over and over because they’re sure that’s where they need to go to add the object. Acting this all out with a paper prototype will find that out.
Important pieces and not so important pieces
Sometimes you may think that a certain feature is really important. You’re positive that the user will have to have this flashing red spinning textbox. The interface just won’t make sense without the flashing red spinning textbox. You get to the paper prototyping session and the user doesn’t even touch the flashing red spinning textbox, but they keep commenting on how great the dull boring toolbar is. Now you know where your spend your valuable time.
Weird words and wrong words
Are you using terminology appropriate to the domain as well as words that your users actually know? Have you ever put “VOIP” as a label in a dialog and your users thought that it meant the Teen Girl Squad sound effect instead of Internet Telephony? I know I have…
But do you know what the best part about paper prototyping is?
You get all the bugs out of the way before you write any code at all!
Well, ok, not all the bugs, but a fair amount of them. You’ll have confidence that can be backed up with real data that your interface will, at the very least, not suck. Any improvements that need to be made after releasing the application should be minor adjustments… assuming that you’ve paper prototyped all the new features that crept in along the way too.
To get your feet wet in paper prototyping, check out PaperPrototyping.com, A List Apart and of course Jakob Nielsen’s Alertbox. To get your feet soaking and all prune-like, buy the book.
UPDATE: To see paper prototyping in action, check this out.
April 16th, 2008
Have you heard about REAL ID?
This is basically the US government’s way to turn state drivers licenses into national ID card and link them through one huge national database. And how will these IDs be used?
Once the IDs and database are in place, their uses will inevitably expand to facilitate a wide range of surveillance activities. Remember, the Social Security number started innocuously enough, but it has become a prerequisite for a host of government services and been coopted by private companies to create massive databases of personal information. A national ID poses similar dangers; for example, because “common machine-readable technology” will be required on every ID, the government and businesses will be able to easily read your private information off the cards in myriad contexts.
Social Security numbers are one of the worst privacy and security threats out there. Way too many businesses use them as IDs and as a means of authentication even though they are nothing of the sort. You might be saying, “Ok, Mike, yeah that sucks, but at least we’ll be more secure with REAL ID cards, right?”
And what will you get in return? Not improved national security, because IDs do nothing to stop those who haven’t already been identified as threats, and wrongdoers will still be able to create fake documents. In fact, the IDs and database will simply create an irresistible target for identity thieves.
So basically they’ll just become another way for you to lose your identity… and cost you money… and lose your privacy. As RealNightmare.org puts it, REAL ID is:
- REAL INVASIVE - Will create America’s first national identity card, increase the thread of identity theft, enable the routine tracking of individuals, and propel us toward a surveillance society
- REAL RED TAPE - Will mean bureaucratic nightmares, long lines, repeat trips, and higher fees for individuals trying to get licenses and IDs
- REAL EXPENSIVE - With a cost in the billions, REAL ID is a hidden tax increase that will force Americans to either pay higher fees to get their IDs, or pay more in state taxes.
- REAL POINTLESS - Will do little if anything to protect against terrorism
Sounds pretty hopeless, eh? At least, the second version of REAL ID isn’t as bad as the first version:
Original legislation contained one of the most controversial elements which did not make it into the final legislation that was signed into law. It would have required states to sign a new compact known as the Driver License Agreement (DLA) as written by the Joint Driver’s License Compact/ Non-Resident Violators Compact Executive Board with the support of AAMVA which would have required states to give reciprocity to those provinces and territories in Canada and those states in Mexico that joined the DLA and complied with its provisions. As a part of the DLA, states would be required to network their databases with these provinces, territories and Mexican states. The databases that are accessible would include sensitive information such as Social Security numbers, home addresses and other information. The foreign states and provinces are not required to abide with the Drivers Privacy Protection Act (DPPA) and are free to access and use the sensitive information as they see fit.
As they see fit? Mexico can do with my social security number as they see fit? Ugh…
If you’re sick and tired of all the identity problems and privacy invasions that already exist and don’t want to see the US become any more Orwellian, help repeal the REAL ID Act. There are states and congressmen that recognize this as a flawed system, but the gov’t isn’t backing down yet. There are several other resources like UnRealID.com, RealNightmare.org, and NO2RealID.org. Do yourself a favor and find out the truth about REAL ID before it’s too late.
April 7th, 2008
What is the first thing that you think of when you think about good software design? Extensibility? Interface programming? Loose coupling? Simplicity? TDD? Everyone has an opinion on what makes a good software design, may it be a thorough use of design patterns, conforming to coding standards, or just easy to understand… everyone has an opinion. It’s not hard to find lists of good elements. Just Google for it and you might come up with this list:
10. Considers the Sophistication of the Team that Will Implement It 9. Uniformly Distributes Responsibility and Intelligence 8. Is Expressed in a Precise Design Language 7. Selects Appropriate Implementation Mechanisms 6. Is Robustly Documented 5. Eliminates Duplication 4. Is Internally Consistent and Unsurprising 3. Exhibits Maximum Cohesion and Minimum Coupling 2. Is as Simple as Current and Foreseeable Constraints will Allow 1. Provides the Necessary Functionality
We all want to create good designs… something elegant and beautiful yet works perfectly. It should be easily understandable, or maybe diligently complex (hey, some people just like complex designs). Either way, whatever good design is, we want it.
But how about bad design? We seem to always know it when we see it (usually because it’s any design other than our own) and can immediately point out each area that is “incorrect”. But what are the real characteristics of bad design? What is something that you definitely do not want in your design?
How about Rigidity?
Is your software difficult to change? Does one change in one class in one module result in a cascade of changes throughout the class, throughout the module or even throughout the application? If modifying your application even minimally becomes an enormous task, you might have a rigid design.
Is your design Fragile?
We aren’t talking about the leg lamp here. We’re talking about design that breaks easily and often. Does making another small change in one component break something in another component? Do unexpected parts break when making unrelated bug fixes? Well then it just might be fra-gi-le.
Is it as Immobile as that car on blocks down the street?
Have you written some classes for your application that are banished to be stuck there forever? Are they coupled tighter than those two weird kids at prom? If so, your code is immobile my friend.
How Viscous is it? I said viscous, not vicious.
Do you write code that makes it easy to do the right things and difficult to do the wrong things or is it much easier to cut and paste the same thing a million times rather than reuse the original code?
Is it Complex just for the heck of it?
Is your code complex just to prove how smart you are? Or maybe to secure your job at Initrode so that the new class of freshouts can’t steal it away? Or maybe because you just don’t know any better? Well, that’s needless complexity at its best.
Does it Repeat, Repeat, Repeat, and then Repeat some more?
Is your motto “copy and paste away”? Have you ever realized that one of your for loops needs an extra check and then shed a tear when you realize that you need to make that same change in 42 other files? Did you skip over the DRY design principle when cramming for your software design exam in college? If so, then you’re bound to repeat your mistakes in life… as well as in your code.
Is it and by that I mean Opaque?
Can no one else understand you code? Does everyone groan when they have fix bugs in your old code? Do you groan when you have fix bugs in your old code? Your code may just be opaque then.
There are many ways to design a software system; some are good and many, many more are bad. Next time you design anything, whether it be a complete system, an application or just a component, make sure you smellcheck it and deodorize if necessary.
April 3rd, 2008
I attended Microsoft’s Launch Event today featuring the launch of Visual Studio 2008, SQL Server 2008 and Windows Server 2008 (but then how have I already been using VS2008 for the past few months? hm…)

We got there a little early, got our nametags and roamed about the Convention Center. After a little swaging, snacking and guitar heroing, we proceeded to the session.
Not too bad of a turnout. The first couple session were on new features in Visual Studio 2008 and web development. We were shown IntelliSense for CSS and Javascript. Pretty cool, although something you already knew if you’ve been using it or if you keep up on the blogs. Then he showed us how to use UpdatePanels and Watermarks… Um, how is that new?
You can see how the first half went. Anyway, the third and fourth sessions were on Office add-ins, mobile development and WPF. Saw some new controls for MFC (it’s about time the C++ guys got some lovin) including the ribbon, command buttons and hyperlinks.
And the prize for sitting through it all. Now we just have to see exactly what is trial software and what’s the real deal…
|
| |
 | |  |
|
|
|