Mini-Microsoft is pretty controversial while being wildly popular with Microsoft employees and enthusiasts. Heck, he was even interviewed by Business Week last September (article here). I would have to say that you've garnered a wee bit of popularity if you're the subject of a Business Week article. Anyway, Mini's quest is for a leaner, meaner Microsoft and he's quite passionate about the do's & don'ts we employees see around here every single day.

In response to Mini-Microsoft, Robert Scoble (Microsoft evangelist extraordinaire) has put together a long, but very interesting essay about how to "shut down Mini-Microsoft" (essay here). He's not rallying the corporate police to seek out and destroy Mini, but rather espousing ways in which we can resolve the issues that Mini rants about.

Here, here Robert! Although it reminds me somewhat of Jerry Maguire's "why do we work this way" essay written in the wee hours and distributed to everyone in the office the very next morning, I like it. A lot!

• A terabyte of space for everyone. I love FolderShare, but dude, sign me up!
• Top-of-the-line machine with dual monitors running Vista for every single employee. I have dual monitors and I must agree...they increased my productivity significantly!
• Public compensation change logs. My first reaction to this is that I like the transparency, but I'll have to give it some more thought.
• Remove corporate speed bumps. Agreed.
• Force marketers to explain there decisions in public. Hell yeah. Accountability. I like most of our code names and it really irritates me when we screw them up for the final products (Whistler was much better than Windows Server 2003).

Go read the entire essay. It's quite interesting.

~tod

tags: microsoft mini+microsoft

Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug

I especially like this book because it is exactly what it claims to be: a relatively short, easy to read book about web usability. In fact, the author explicitly states that he "worked hard to keep this book short - hopefully short enough you can read it on a long plane ride." Being a very busy person at work and home I really, really appreciate this!

I highly recommend this book for: anyone who is the slightest bit involved in developing or designing a web site's user interface...period. The reason I say this is because:

• it's a great starting point for someone who has no experience with web site usability.
• it seems like a great [and quick] refresher for anyone who does have usability experience.
• it's an interesting read because the author's character really comes through [versus being dry and boring].
• it really is short enough for a long plane ride or a few nights 'bedtime reading.'

A few highlights of things I learned and/or appreciated:

• First and foremost, don't make your users think! For example, descriptions [for categories, products, lists, etc.] should be clear and concise.
• Users really don't read web pages, they just scan them for keywords.
• Users satisfice when selecting where to go next on any given page. This basically means we tend to choose the first reasonable option instead of examining all of them before selecting one. And yes, I realized that I do this.
• Following conventions is a good thing. Forget about reinventing the wheel and just use techniques and design patterns that people are already comfortable with.
• Keep the visual noise to a minimum [don't try to cram in everything and the kitchen sink].
• Omit needless words. Get rid of half of the words on every single page. When you're done with that...do it again. It may sound harsh, but it's true.
• The "You Are Here" theory. Make it blatantly obvious where you are in the site structure at all times [using page titles, highlighting, home link, tabs, etc.].
• Always have a search box...unless your site is a single static .htm page.
• Keep the home page simple! Remember, it's purpose is simply to get across the big picture.
• Usability testing doesn't have to be hard, in fact, it can be down right simple. Just grab your neighbor for 15 minutes.
• Usability tests...small scope frequent testing is better than a single (or few) large scope test(s).
• "The Reservoir of Goodwill" - Don't use it all up and try to refill it when you do use some!
• Last, but certainly not least. Always keep accessibility in mind when designing. Steve is referring to Section 508 of the 1988 Amendments to the Rehabilitation Act, which specifies accessibility standards for information technology (like web sites).

Check out Steve's website, sensible.com, for more information about him and his book(s).

~tod

tags: web+design usability

You've heard of Jeff Foxworthy's "you might be a redneck..." catch phrase right? Well, Jeffrey Palermo has started his own: "you might have a legacy enterprise application...."

You can't figure out which copy of the source code is the one deployed to production.

The comments are worth reading too. Check 'em out. And yes, welcome to my world.

~tod

tags: software+development

A little over a year ago, I was making the transition from a systems engineer to a developer and posted that I was 'choosing C#' as my entry point language. Honestly, that was a bit naive of me. I didn't really 'pick' C# as much as I chose to learn the .NET languages which happened to include C# along with VB.NET and ASP.NET.

I'm bringing this up now because of Karl Sequin's post, titled Language Proficiency - C# or VB.NET? (found via JasonHaley.com). In a nutshell, his point is that a good .NET developer should be proficient enough to read and code in either language when the need arises. I couldn't agree with him more.

Over the past year I've primarily used C#, but the primary web application I work on is written in VB.NET. That means I've had to frequently flip back and forth between the two. Personally, I'm glad that I was forced to do that because it's made me a better developer. Although I feel more comfortable with C# I can read/write either language when necessary. And with the assistance of Carlos' CodeTranslator, I can very easily correct any syntax errors that inevitably popup when I switch between the two.

So the question really isn't whether you should be a C# or VB.NET developer, it's are you a .NET developer. I would expect any .NET developer worth their salt to be able to work in either language without losing too much brain power. So there you have it, the unadulterated opinion of an SE turned developer.

~tod

tags: dotnet