It uses ClickOnce for the installation (because it was really easy to do from VisualStudio), and is pointed at the svn repository for updates - so although I’ve never tried it, the theory is that it will have automatic updates built-in. You can download the install files from the project page linked above.

Of course, UI is hard, far harder than coding for developers. It’s tempting to skip the tough part and do what comes naturally — start banging away in a code window with no real thought given to how the user will interact with the features you’re building.

Remember, to the end user, the interface is the application. Doesn’t it make sense to think about that before firing up the compiler?

I found this particularly interesting and timely in light of the topic being the brunt of a recent April fool’s day joke on The Daily WTF. When I read that post, I actually found it surprising that programmers would think it satirical to consider designing the user interface first. Of course, the rest of the post gets a bit more crazy but I won’t touch that part.

Jeff talks more about the benefits of paper prototyping:

Paper prototypes are usually pitched in terms of doing low-fi usability studies, and rightly so. But I find a paper prototype tremendously helpful even if I’m the only one that ever sees it. I need to create an image in my mind of what I’m building, as it will be seen by the world, before I start pouring the concrete to make it real.

Figuring out the GUI definitely helps you get into the guts of what you need to accomplish in the end, and so it is definitely a helpful task. I think there is another tremendous benefit that to this however: developing a nice user interface.

Okay, so this seems like a less than earth-shattering revelation. Many programmers totally miss the mark on this though. Consider the traditional approach: write a command-line app or hardcode everything in, get the code working, and then write a GUI on top of it to expose to the end user. By doing this, you automatically box yourself into writing a GUI based on your underlying API or database layout.

I think there is a big benefit to taking a step back, totally forgetting about all the underlying API stuff you did, and think up a design for the best possible UI that you can for the problem you’re trying to solve. Pretend you’ll be the one using it every day for the rest of your life.

What you come up with may be totally incompatible with your API; that is okay. In fact, it may even point out fundamental flaws with the way you’ve done things (hence the benefit of the initial paper prototype..). It may work exactly with your code. It may require a translation layer of sorts, to convert what the underlying code is doing to how things are represented in the UI. It may also require compromises in the UI to be able to write a translation layer. All of these are good outcomes though because the end result is you generally have a much nicer UI than you would get if you just stick a pretty face on the raw API.

To use a simple example, consider the Google MyMaps interface. Underneath, the database is storing locations using their latitude and longitude, and assigning a name to them. The ultimate simple interface to this would be:

Of course, what Google actually did makes much more sense - even though it involves a whole lot of code that translates mouse clicks on the screen into map pixel offsets, and then those into latitude/longitude:

In a lot of situations, the success of your software can come down to how nice and/or easy to use the GUI is, regardless of how powerful it is underneath (I’m sure you can think up many examples of this .. perhaps in say, the operating system world). Whether or not you actually design the UI first is inconsequential - ultimately you need to design the UI for the end users, not for the API.

Via BoingBoing

Each user can create a number of stations, and for each of them, you can add artists to it, control how much variety it plays, and rate songs as they play.

An interesting feature is you can search for and play songs on demand - but what happens is it shows songs that are currently playing on other user’s stations, and then tunes you into that station. The song starts at the beginning, but if you continue listening, the next song that plays is determined by the station. In this sense, “stations” are more like dynamic playlists - it’s an interesting concept.
My stations are at: http://www.jango.com/users/3393756. Enjoy!

On that note, I recently had to switch my home phone number. It’s not really a big deal since most people call my cell phone anyways, but basically Unlimitel pulled out of operating in Kingston. I am now with les.net (which has a really nice interface by the way - letting you pick and add DIDs to your account in seconds, see your balance, automatically send you a reminder when your balance is low, etc). I looked into porting my number over, but was told that I would be charged a $150 fee to port - I have to wonder if that would still be the case in a couple of days?

First off, as the article correctly points out, VoIP does require power, so if you lose power, then you lose your phone line. This can be dealt with by getting a UPS (battery backup), and in fact, I’ve seen some providers that build batteries in to their modems/analog telephony adapters (though unfortunately, it’s not very common). It’s also true that your broadband connection is probably not as reliable as your PSTN lines - there are simply more things that can go wrong.

However, the article falls apart at this point, and starts arguing about how software changes to the security system could break everything (because on a PSTN they couldn’t? why are you upgrading your alarm system remotely/autonomously?), and how your TiVo, fax machine and conventional modem won’t work. I’m not quite sure what that has to do with security, nor am I sure why you’re using a conventional modem when you have a broadband internet connection.

The CBC article points out that one user went for a year and a half before noticing his alarm didn’t work. This is entirely his own fault. If you change your wiring, your service provider, or anything else, it’s just common sense to test the equipment hooked up to it. Surely if he added a new jack he would have picked up the phone to see if there was a dialtone instead of assuming everything worked. This is above and beyond the fact that most alarm systems suggest you test them at least monthly, ensuring that the sensors and sirens and phone connections are all working.

On a bit of a tangent, I’d also like to note how ineffective alarm signalling usually is: unconfirmed alarms are basically the lowest priority calls police will go on, so they often will not drive to your house until long after the alarm went off, if they even bother to show up at all. Here, the police charge businesses $60 for the second false alarm, $120 for the next, and so on (I’m not sure what they do for residences). Not to say that alarm dialing is useless, because the panic buttons should still get someone there pretty fast (it requires a human, as opposed to a motion sensor which can be a malfunction or pet), but if you think that the SWAT team arrives seconds after the alarm goes off with guns drawn, you’re sadly mistaken.

The best defence is to have neighbours that will hear your alarm going off (loud outdoor sirens help), notice the kids moving your big screen TV into a black van parked in the driveway, and call the police. Or get a big dog.

Based on the tone and conclusion (”But hardwired land lines seem to be the most solid answer for now anyway.”) of the original article, it sounds more like some Slashdot readers speculated - that the phone company is pushing for this drivel to be published because they’re starting to feel the sting of VoIP on their bottom line. I pay under $10 a month for my home phone service, have all the “features” that cost extra on PSTN lines, and can make multiple calls simultaneously if I want to - even a basic line with the telco is $25+, and if I were to get 4 or 5 lines with all the features active, I would be in the hundreds of dollars per month.

It would be great if the phone companies would leverage their existing (more reliable) network to basically run a second VoIP-only internet alongside the existing internet infrastructure, bringing the best of both worlds together - but unfortunately this will never happen because it would be too easy to use other providers, not pay outrageous long distance charges, etc.

I should also point out that if you’re using this, you should be sure that you don’t “whitelist” localhost in your mail server, or otherwise people can just connect to your SMTP server locally, and send mail without requiring a username or password. If they use SMTP you can’t see what script or virtual host sent the mail either way, but at least if you require authentication you can see what account is being used if it becomes an issue.

2.2.0 is a fairly signifigant release, adding a fair chunk of new functionality, fixing lots of bugs (over 200) including some long-standing bugs that have been around since the 1.x series. Among these are some bugs in the call handling that dealt with certain situations where you pass a call from a queue to a ring group, or going to a cell phone, and then forwarded back to another extension, etc, that were sometimes causing voicemail to never pick up, and some other strange behaviour. I was busy rewriting the modules API to make everything a bit more solid, and wrote a fancy new module administration interface. I also ported a nice new design done by Steven Fischer, which was a much needed upgrade from the basic look that the interface had from the start. I’ve also written some new modules (announcements, phonebook directory, misc applications, speeddial) and done some work on a half dozen others. Overall, we’re quite happy with this release and definately suggest that anyone using 2.x upgrades.

Going forward, there’s a few things I’d really like to do - write some hooks to use QuickForm, to make writing GUI code a lot simpler; finish my text-to-speech and manualconditions modules (which I’ve started on already); finish the daemon to write config files (instead of having the web server invoke a script); write the framework for a user portal; and add a menu before going to voicemail to allow callers to do various things besides leave voicemail.

Now, if I just had a clone or two that could my other day-to-day tasks like go to work, I would be set.