Then I found the as3smugmuglib project on Google Code. I changed the app to work with that API instead of my own code.

Because I used Cairngorm when I built the original app, the protocol code was isolated into the business classes (org.stevex.smug.business). The refactoring had little impact on the rest of the project.

I cleaned up a couple of minor bugs as well, so here’s a new release. It still doesn’t have any of the features that I wanted when I started this project (like a way to automatically upload new photos, or even batch uploading) but as usual I’m hoping to get back to it soon.

Here’s a zip file with the complete source: Smug1.zip.

Every time I hear about how expensive it is to run a successful podcast (like the NPR podcasts, some of which are begging for money to pay for $150k annual bandwidth bills), I think to myself, “I have spare bandwidth; I’d like to donate some”. But there’s no mechanism for me to do that.

And why not? I don’t think it would be that hard to do. Let’s take a rough cut at it.

The goal is for a provider to be able to share a particular piece of content, say a podcast, with as many people as possible, and accept donated bandwidth for distributing it.

One possibility is BitTorrent, which does a fairly good job of this, but would require a custom client. The biggest podcast client in the world is iTunes, and it doesn’t support BitTorrent, so any podcast that doesn’t want to lose most of its audience will stick with HTTP as the distribution protocol. We need a way of distributing URLs that will load balance to the donated bandwidth.

As a donator, here’s what I want to be able to do: Go to, say, the NPR website, and click on the “donate bandwidth” link. At this link I’d enter the URL for my Bandwidth Donation Protocol (BDP) service, the amount of bandwidth I want to donate (in megabytes or gigabytes) and a key or password. NPR’s service would then add me to it’s bandwidth donator pool.

Now when they have a podcast they want to post, they generate a URL for that podcast. Say it’s:

http://npr.org/content/hypotheticalpodcast.mp3

Before using my donated bandwidth, they need to upload the content to me. Their server contacts my server and says “here’s hypotheticalpodcast.mp3, and I’d like you to allocate 1 gigabyte worth of bandwidth to it”. In return, my server would generate, say, 200 unique URLs and return them to NPR. Now for the next 200 requests for this content, they can 301 redirect to my URLs and distribute the content at no cost to them.

Why generate the 200 URLs? Why not just use the same URL and stop answering after 200 requests? Because a single user downloading content might request the URL more than once (for example, picking up ranges of content), so the URL can cut off after a reasonable amount of time, but not be vulnerable to abuse by giving out the URL 500 times when only authorized to do so 200 times.

I’ve wanted to implement something like this for years but never had the time, so I’m throwing it out there: What do you think? Would it work? Would it help the podcasters being crushed by their own success?

My Ottawa Events site was recently hit by a deluge of spam – so much so that I had to disable commenting completely. I discovered Discus through Dave Winer’s blog, and it seems like it’s worth a shot, so I’ve enabled it on the Ottawa Events site.

I like the idea that I can sign up for an account with Disqus and that account works on any blog or site that uses them for commenting. These sorts of sites that provide hosted services to webmasters tend to get bought up by someone if they do a good job (as happened to FeedBurner, for example) so I’m not too worried about my comments disappearing, although that is a risk I take by letting someone else host them. Ottawa Events content is time sensitive, and the comments aren’t valuable anymore once the event has passed, so if Disqus did disappear, I wouldn’t lose a lot of valuable content.

There are two services that Disqus could be providing. One is simply managing commenting, which they’re doing, but the other is filtering spam. I don’t know how they do at that job, but if Disqus just becomes another spam target, their value disappears. Hopefully they’re well aware of that.

Consider Paste or Undo. If you click the Edit menu, you can tell from the enabled state of the Paste item whether or not there’s something on the clipboard that can be pasted. Same with Undo. If Save is disabled it means there have been no changes since the last save. The enabled state of these items conveys information.

I’d rather click Edit and see Undo greyed out, than click Edit, Undo, and have a dialog pop up telling me that there’s nothing I can undo right now.

It would be nice if your Help system included a description of all the menu items, and when they are available. An lot of the documentation I’ve seen includes descriptions of menu items that add no information (“Undo: Undoes the last operation”) and leave out valuable information like under what circumstance that item might not be available.
It’s unlike Joel to post bad advice. Perhaps he need a little SEO and posting something obviously wrong would be a great way to get a lot of people to link to him with corrections?

But there’s a warning:

Even the best coders do not estimate accurately. If you don’t understand and account for this, it will probably cause you unnecessary problems.

Do you understand that it’s wisest to multiply any coder estimate by either 5 or 2 to get a more realistic estimate?

I like that. Multiply by either 5 or 2. Pick one. That’s about as accurate a method as any.

I like to hear that IntelliSense is going to be fixed, but I’ve been hearing that for many versions of Visual Studio now, and I have a hard time believing it.  IntelliSense for C++ code has always been unreliable in the projects I’ve used it on (generally massive MFC applications).

Remember a product called Lookout?  It was a very fast, reliable search engine for Outlook.  Microsoft bought it.  I don’t know why they bought it, because they obviously didn’t use it – with Office 2007 on Vista, searching email is not fast and not reliable. 

For C++ users of Visual Studio there’s a tool called Visual Assist X, which is a fast, reliable IntelliSense replacement for Visual Studio.  It extends Visual Studio in a lot of ways, many of which don’t require any changes to your workflow.  For example, if you have a pointer and you type “pMyPtr.” as soon as you type the period, it will be replaced with a “->”.

One particular improvement VAssistX makes to IntelliSense that I find very useful, is you can type “pMyWnd->size” and list that appears as you type “size” includes all the relevant symbols that contain the word “size”, not just ones that start with it.

I’d love to see VAssistX become obsolete with Visual Studio 10, but I’m not holding my breath.  I just hope Microsoft doesn’t buy them, so that if Microsoft’s improvements don’t deliver, Whole Tomato still can.

The book is about web design, and how to create sites that users can use without thinking about them.  Kind of like how you walk into a room and reach for the lightswitch without first looking for it, because it’s usually in the same spot, there are strong conventions that, if followed, will enable users to use your site instinctively.  If a box looks like a search box, users will assume it’s a search box and type stuff into it.  Get it wrong and they’ll have to think about it, and web users aren’t good at that.

How much of this is true in software?

Users are usually much more invested in the software they’re using than in most of the websites they encounter, but that doesn’t mean as UI designers we shouldn’t try to learn some of the same lessons.  Both Microsoft and Apple published UI guidelines that helped define conventions that software developers have been using for the last 20 or so years to create applications that most users can find their way around with the lights out.

I have two comments on this.  The first is that from this perspective, the current trend away from standard user interfaces is disturbing.  IE7 takes away the menu bar in favour of a collection of toolbar buttons that each drop down a selection of menu items.  Office 2007 provides the ribbon bar.  iTunes has a lot of quirky UI behavour.  Plain old applications are passé. 

In some ways this is like trying to find new places to put the light switch. 

My other comment, and the one I’m really more interested in (since I don’t think I’m about to stop the swing from consistent UI design to style driven UI design on my own) is that the ways Steve does usability testing can be applied to software as well.

Good UI should also be something you don’t have to think about.  Unless you’re doing something completely new (and you probably aren’t), a dialog should fit the pattern of other similar dialogs well enough that the user already knows how to use it.  And the best way to determine whether or not you’re hitting this mark is usability testing.

A phenomenon that Steve talks about is one where companies try to do higher quality usability testing and end up going overboard.  By spending money on testers and studies and finding the right sample of users to test with, and coming up with extensive scripts and processes, the process becomes onerous.  Not something you can do on a whim.  So they end up not doing it very often.  That’s typical of every company I’ve worked for.

But that’s how you should be doing it.  Mock up a dialog, find a few users, and show it to them.  Ask them to use it, and see how it goes.  Do this often, and in a more or less ad-hoc manner.  If you have questions about how new UI should work, prototype it, and then put it in front of some users with roughly the amount of computer skill you expect your target users to have, and see how they use it.  Lather, rinse, repeat.

If you don’t approach it this way, you won’t do as much testing, and imperfect usability testing is still way better than none.

But what I found interesting is how they announced it: By showing the check-in mail that signified the committing of the code that implemented the fix into the main IE source tree. Check that out here.

A few things it reveals:

• This fix touches a lot of files. This wasn’t a simple fix.
• Microsoft uses Perforce for source code management. This is indicated by the //depot/path syntax used for the files.
• IE8 work is happening on a branch, called LONGHORN_IE8. Typically new features are added to the “main branch” (which usually doesn’t have a name). I wonder what’s on the main branch.
• Obviously some IE work started before source file names could be more than 8 characters long. LSTXBR1.H?
• Microsoft uses some sort of pre-checkin code review process. This is a good sign; we use this at on my team at Adobe and I think it’s proven itself valuable.
• No C# code in sight; IE’s core is still all unmanaged C++ code.
• The IE devs use a mix of extensions for C++ source and header files; cxx vs cpp, .h vs .hxx. Personally I’ve never worked on a project that used cxx and hxx, so they seem unnatural to me.

Nothing earth shattering, but an interesting peek behind the scenes nonetheless.

I’m really torn on C++ these days.  Some people believe it should basically be retired, in favour of one of the better alternatives like C# or Java, but C++ has a number of qualities that make it a truly enduring language.

It’s a humble language – it doesn’t impose any of its requirements on you.  You can use a bare minimum, portable runtime and write a C++ app that can be compiled and run on almost any platform.  When you do need to go looking for libraries, they’re out there by the hundreds of thousands.

Java, of course, requires a JVM, but also works to hide the platform from you.  When you’re coding in Java, your platform is Java, but in the real world, mainstream applications need to leverage the platform they’re running on.  Want to write a QuickLook plug-in for Mac OS X?  Or the equivalent preview handler on Windows?  You need to use native code.  There are all kinds of limitations that you bump into trying to write high quality portable client applications using Java.

C# doesn’t have that problem as long as you stick to Windows, but that’s the killer for C#.  You have to stick to Windows.  With the Mac platform making a resurgence, it wouldn’t make sense for anyone with the resources to do cross-platform development to start a new app in C#.  As long as the market for your application is big enough that 10% of sales would pay for the cost of creating portable code, it’s worth supporting the Mac.

With C++ you can use any UI toolkit.  Any system level API.  Anything.  No limits.  And thanks to the preprocessor, you can tune your code to the platform it has to run on.  That’s why C++ is going to be around for a long time.

I’m arguing in favour of C++ but MFC is still obviously a Windows-only UI technology, what’s up with that?  Well, often what happens in large cross-platform applications is the core of an application is portable, but the chrome is unique on each platform.  (Or, you write some kickass cross-platform UI that you use but not everyone has the resources for that).  Apps with chrome targeted to the platform are almost always better than portable apps that try to look the same everywhere.

So it’s very good to see Microsoft recognize this and update MFC.  Otherwise, we were destined to live with the 1995 look & feel of a default MFC application for even longer (or go shopping for UI toolkits that modernize MFC, but those come with their own sets of problems – like what happens when your tool vendor stops updating the toolkit you depend on).

“There is a larger number of MFC developers than we thought”.
– Pat Brenner

And it’s going to stay that way.  So thank you for the update.  Now where’s that improved C++ support in the IDE?

With Vista, the feature that would help was I/O Cancellation, the ability to cancel an I/O request without having to wait, in case it was hung in the kernel. 

And yet..

C:\Users\stibbett>taskkill /im someapp.exe /f
SUCCESS: The process “someapp.exe” with PID 7020 has been terminated.

C:\Users\stibbett>taskkill /im someapp.exe /f
SUCCESS: The process “someapp.exe” with PID 7020 has been terminated.

C:\Users\stibbett>taskkill /im someapp.exe /f
SUCCESS: The process “someapp.exe” with PID 7020 has been terminated.

C:\Users\stibbett>taskkill /im someapp.exe /f
SUCCESS: The process “someapp.exe” with PID 7020 has been terminated.

I think I’d be less disgruntled if taskkill could just *check* to see if the process is actually gone before gleefully announcing it’s success.