For those of you that are interested, I’ve begun development on Version 1.5 of Slideshow. For more information about the script and some of the upcoming details, check out the Slideshow JS project page.

Overall, I’ve received some really positive feedback and am doing the best I can to incorporate all of the features that have been requested. I’m also going to be addressing a couple of lingering bugs that have been discovered. Once I get closer to releasing the next version, I’ll be sure to outline all of the squashed bugs and feature requests.

If you’d like to be notified whenever the next version is released, sign up using the link on the project homepage or leave a comment on this post.

I’ve spent part of this weekend overhauling my site. This was driven by the need for greater organization of content, and better support for visitors. Here’s a quick rundown of what I’ve done to improve the site…

Moved from Chyrp to WordPress

Importing all of my previous content into WordPress from Chyrp was a little more tedious than I was hoping, but it wasn’t terrible. If you’re planning to move from Chyrp to WordPress, here are my recommendations (because I know there are those of you out there that have done it):

• Backup your database and files first.
• Export your current RSS feed to a file on your local machine. To do this, simply load up the site in Firefox and choose “File>Save Page As…” and select “Web Page, XHTML Only.”
• Install WordPress.
• From the WordPress dashboard, select ‘Manage’, ‘Import’, and select ‘RSS.’ Use the file that you saved in Step 2.

If everything goes correctly, WordPress should list all of the posts that you’ve just imported and generate a success message. Before you’re done with this step, you may want to browse the site and examine your posts - importing from XML can sometimes result in some odd behavior (as a result of how WordPress’ editor and browsers parse CDATA tags differently). Your content is all there, you just may have to clean up some of the residual tags. You can do this by editing a given post in HTML mode.

Built a customized theme

At this point, I’m more concerned with publishing content than building a custom theme, so I met myself in the middle: I found a theme called Simplicity that I really liked, but it still lacked a few things that I wanted. I spent some time tweaking various aspects of the theme and organizing it in such a way that it was conducive to how I’m wanting to organize all of my information.

Because of the amount of modification that I made to the Simplicity theme, I ended up saving it as its own theme. It’s currently not publicly available, but if you’re interested in using it, leave me a comment.

Updated FeedBurner

Chyrp and WordPress each publish separate feeds. Luckily, I had been using FeedBurner prior to migrating to WordPress, so I was able to update the feed from withing the FeedBurner dashboard. This should take care of current subscribers all the while allowing me to maintain stats with no real loss of data.

Unfortunately, this may result in a few readers displaying information differently. For instance, Google Reader displays the RSS 2.0 feed differently than Firefox’s Live Bookmarks. Additionally, some readers may show a lot of my previous posts as new posts.

Installed the latest version of Google Analytics

During my time of using Google Analytics, they released a new version that I never actually used on my old platform. This is nothing more than sheer laziness, but it’s given me the change to incorporate the new version into this site.
Overall, this migration was a relatively painless process. Hopefully content publishing will be much easier, comments will be managed more efficiently, and overall visitor experience will be better.

Recently, WordPress 2.5 was released and its corresponding minor bug-fix release, version 2.5.1, was released as well. This was a relatively solid upgrade. The overhaul of the interface was a welcome change; however, the upgrade ended up causing some major problems with its RSS syndication.

First off, there was some under-the-hood changes that changed how users access RSS feeds based on how the permalinks are configured. For example, if you’re using permalinks in the format of /year/date/day/title, then you should use the RSS format of /feed/rss.

Secondly, the upgrade actually broke RSS2 feeds. You can read an entire forum post about it here on the WordPress forum. This was quickly addressed and the bug fix is available in this changeset. In my opinion, these are the types of bugs that should’ve been found during testing of such a major release - I don’t get why something like this wasn’t caught.

Lastly, I was burned twice on the RSS issue. Once I patched my installation with the bug fix that I just mentioned, I noticed that my RSS2, ATOM, and RDF feeds still weren’t working. I ended up tracking it down to a problem with failing to encode an ampersand. Specifically, the author’s ‘friendly name’ included an ampersand and it was written into the database without being encoded - parsers do not like the ampersand if it isn’t encoded as it’s usually used as a delimiter for key/value pairs. Because of this, the XML used in publishing the feed was invalid.

Once I made this modification in the database, all of the feeds went live again. Just like the WordPress developers should have caught their RSS issue before releasing, I should have caught that issue when configuring the site.

Yesterday, I got my invitation to try out Dropbox. As of now, there are clients available for Windows and Mac. According to the forums, the team is working on a client for Linux. You’re given 2gb of storage, and several invitations to pass out to friends.

I’ve got a few invitations remaining, so let me know if you’d like one. In the coming week or so, I’ll try to post my thoughts on the service.

I’ve received some good feedback on Slideshow JS, and some people have even emailed me with contributions and/or ideas. I’ve got a list of small fixes and features that I hope to eventually implement, but it may be a while before that happens as I’m busy with a couple of other things.

If you’ve used it and have a feature request or have discovered a bug, please email me at tom at tommcfarlin dot com and let me know!

I’m currently working on a web application and am trying to take advantage of the ASP.NET AJAX framework (which I think is kinda weak is comparison to some other frameworks, but I digress).

I was attempting to use the modal pop-up control, but the framework is apparently manipulating a node in the DOM before it has been closed. If you check out Microsoft’s support page, you’ll notice that they don’t have any real solutions - only workarounds. Lame.

Unfortunately, none of these workarounds are feasible given the current environment in which I’m working so I’m having to essentially create my own modal pop-up. If you’ve got experience with this issue and have come up with a solution (versus a work-around), please leave a comment.

Edit June 5, 2008: Commenter tbela99 suggested verifying that all of your existing XHTML is well-formed (with no closing tags). This is always a step that should be done prior to releasing; however, it’s a difficult thing to do whenever you’re adding functionality to a project that has already been released. tbela99 made a couple of additional suggestions that are more JavaScript oriented, as well - check out the comments.

Recently, I purchased an LG Voyager. Since my previous phone was a smart phone, I did a massive amount of reading and debating before purchasing the Voyager - I actually wanted to downgrade my phone, but not lose a lot of functionality that I was used to having. The Voyager is not a smart phone, but it has a lot of features that allow me to maintain the same features, which is what I want, and it does so for less than half the cost. After using it for a few weeks and finding that I do not miss my smart phone at all, I figured I’d share my thoughts of my experience with some of the features of the Voyager that allow me to maintain all of the same functionality as a smart phone (for much cheaper).

A note about Outlook and Google services
It’s important to note that if you’re looking to know if the Voyager will sync with Microsoft Outlook for email and calendar, then this review is not going to cover that topic. I sync everything with Google services and Google provides a lot of functionality that makes it easy to push their services to cell phones via SMS. I also want to add that the Voyager comes with a full HTML browser so it is possible to check your Outlook email via the web interface, but that’s not the focus of this post.

What I wanted out of a phone
As previously mentioned, aside from making calls and sending/receiving text messages, I want my phone to provide access to my email, my calendar, and to have the functionality that will allow me to casually browse the internet to, say, read my RSS feeds. In addition to access to these services, I’d like my phone to ping me when I’ve received a new email and whenever I’ve got a calendar event about to occur.

Additionally, as much as I love having the full QWERTY keyboard, I found that I actually missed sending quick text messages using the numeric keypad. Smart phones are wide enough such that it basically requires two hands to type any type of message and that frustrated me at times. Luckily, the Voyager has both.

Lastly, I ended up disliking Windows Mobile - I probably should have seen that coming, but either way, I digress as that isn’t the point of this post. Basically, I wanted to “de-grade” to a dumb phone from a smart phone in order to save money, but maintain smart phone functionality all the while.

HTML Browser
The first thing I want to point out is the quality of the browser on the LG Voyager. It’s a full HTML browser (versus the usual WAP browser found on most dumb phones), so, excluding things such as JavaScript, the phone renders pages almost exactly the same as you’d see on your desktop. Matched with the speed of the Verizon EV-DO network, you get a really solid browsing experience. The browser was one of the selling points of the phone for me - with this browser, the touch screen, and the EV-DO network, I have web access to almost all of the usual pages that I use. Most major sites also have mobile version available, such as YouTube, Facebook, Flickr, and Google, if the standard version doesn’t load.

Getting Email
Because I maintain everything using my Gmail account (with the exception of work email), I had been syncing my previous phone’s email client using IMAP with Gmail. This proved to be nice, but, seeing as how I’m at a computer most of the day, the benefits of IMAP weren’t as strong as I could basically just respond to the email from my machine. The phone ended up, more often than not, notifying me of whenever I had received a new email. In the rare case that I wasn’t near a computer, it was nice to be able to send an email from my phone.

Since the Voyager is not a smart phone, it has no true email client that most phones like the Treo or the Blackjack have; however, Gmail offers the ability to automatically forward emails as they are received. Since you can send a text message to any phone on the Verizon network at [phone-number]–>

Obviously, this doesn’t allow me to respond to an email, and the email is truncated because of space limitations of cell phones, but it provides notification that I do have an email so I can respond whenever I get back to a computer, or I can open up the browser on the phone to respond if I absolutely need to respond at that time.

Calendar Notifications
The second major point that I want out of my phone is the ability to have my schedule available with me, and to have the ability to add, remove, and update items on the go. With my previous phone, I was able to do this; however, I’d then have to run the synchronization application in order to have both calendars updated. With Google Calendar, I can keep all of my data centralized, and, by using Google Calendar sync, I can sync my work calendar with my Google Calendar automatically.

Similarly with email, I’ve setup SMS calendar notifications to be sent to my phone 15 minutes prior to an event starting. This works much in the same way that Outlook notifies me on my desktop at work, and also the way that Windows Mobile’s calendar works. If I need to see a more detailed schedule, I can again launch the browser to view and/or modify my events without having to initiate a syncing process.

Miscellaneous
The phone also has other good features, but the primary thing I wanted to show was the ability of using the Voyager as a smart phone though it lacks features that most smart phones have. In addition, Verizon’s BroadbandAccess plan for smart phones cost $50 a month whereas dumb phones have unlimited web access for $15 month. With this phone, I’ve been able to save money without losing any features of a smart phone.

Until later,
Tom

Recently, I’ve been working on a project that will ultimately require new users of the system to create their accounts with stronger passwords than the application has typically allowed. Existing users will be required to update their accounts with stricter passwords. The software is a distributed web application, and the code that I am working is a the application layer.

I’ve used a couple of design patterns to essentially build a framework that allows us to setup a password object and add and remove policies to it at runtime via XML flags. Policies are nothing more than rules that will evaluate the password against a single requirement, such as its length or whether or not it contains a specified number of digits and/or symbols. For every policy that the password is evaluated against, the framework will generate a set of error messages as well as a password strength rating and will return them once the rating process has completed.

Ultimately, this will all be bound to the front-end when the overall project is completed; however, for now, there’s no UI against which to test the framework’s performance. Since testing is arguably one of the most important phases of software development and since there’s no true UI to provide any level of feedback from this framework, I chose to take a true test-driven development approach to the password and its policies.

Write Test Cases First
Because we designed the software upfront, we new how the system should behave before we actually began building it. This made it relatively easy to write test cases first - we new what our inputs were going to be and we new exactly what outputs to expect for each case. After writing these cases, I found myself to be more conscientious of the code I was writing for the actual system.

Although it’s wrong, it’s not uncommon for developers to first build their application and then right the test cases (numerous articles are available online about this). This is incorrect for a number reasons primarily because you’re basically writing tests for a system you’ve already built - in the same way that writing code after the test cases made me more aware of what I was writing, writing your test cases after building the components will likely result in writing cases that fit the existing system. This completely misses the mark on the purpose of Test Driven Development. Writing test cases to fit the software is backwards - write your software to fit your test cases.

How long did it take?
This took a little bit longer to do for several reasons. First off, writing a test suite to cover branches, statements, outputs, etc. of your system adds to the amount of time to complete the project (or phase of the project). Couple that with updating various components and then developing new test cases for those changes, you’ve got a pretty full plate of things to maintain. Ultimately, it may result in a slightly longer period of time to complete, but if this is taken to account in project planning it shouldn’t be that big of a deal. Additionally, you’re only increasing the quality of the software, so I’d argue that it’s worth it more often than not.

Combinations and Permutations of Policies
This was the fun part. Initially, we started off with a small set of policies; however, as the project matured and we gathered more input, we had to create additional policies. This resulting in us testing possible error messages as well as the various strength ratings for each arrangement of the policies. It’s really not that big of a deal if you’ve got a couple of people working on the project, but it’s easy to see how fast something can increase in complexity by simply introducing one or two more components.

Overall Impressions
Building this framework using Test-Driven Development was great. It prevented the project and it’s various combinations of outputs from getting away from us very early in development. It also resulted in a great feedback of a system that doesn’t have an interface with which to interact. Finally, it generated a strong sense of software quality once the system was developed and all of the test cases passed.

Maybe I’ll revisit this project to show off the interface once we’ve finished it, but that’s not really something I’m planning to focus on showcasing. We’ll see.

That’s it for now,
Tom

With the next version of Ubuntu Linux coming out in about a month, many of the Ubuntu blogs have been buzzing with a range of topics - discussions on new features, examples of the improvements, reports on bugs that have been addressed (and new ones that have popped up) - most of which are relatively normal. One recent post, however, caught my attention - The #1 Problem in OSS Usability and What I’m Going To Do About It. I’ve been tossing around the things that she’s discussed in that entry, and figured I’d post my thoughts here.

The author makes some really good points in her article and so I’m going to try to avoid repeating too much of what she has already said. Before getting into it, though, I’d like to concisely summarize my opinions on development and usability without going off on a tangent:

1. Programmers should not be the sole people responsible for building the interface. They should be responsible for designing the software and building the interface around specifications determine by designers - not throwing in an interface element for every single function in the software.

2. Designers should not pretend that they are programmers, but should have a solid understanding of what the software is supposed to be doing. Don’t decorate the interface with unnecessary elements - minimalist, intuitive design is key.

Unfortunately, one of the down sides of open-source software is that a large majority of the interfaces for software that is developed is done so by programmers. That’s why it’s not surprising to see something like this, versus seeing something like this
on any given Linux distribution.

So why is her idea awesome?
First off, she not only understands usability, but she understands what the problem is with regard to usability in the open-source community. Usability is something that is already greatly ignored in software development, but even more so in a community that is primarily made up of geeks and software developers. We care more about something working versus how it looks, and it shows whenever you look at almost any piece of software that’s been hacked together.

Secondly, she’s got direction on how to address the issue. Because lack of research is the largest factor contributing to low-levels of usability, and because there’s no set standard or method of documenting the research, there’s no way to move forward with improving usability if there’s no reference on what to improve. Developing formalized documentation from the open-source community is an awesome place to start.

Lastly, she knows where to begin. She doesn’t really have a half-baked idea - she’s not only addressed the problem or how to solve it, but she’s addressed how to get it started, has explained how’s she’s going to do it, and has the personal investment in the project to keep it going. She’s got direction and you can’t drive anywhere without good directions.

Why I think this will work
Having “Open-Source Usability” is something that I’ve never really thought about, despite the fact that it makes sense. I’ve typically associated the open-source community with geeks - people that care more about good looking code rather than graphical user interfaces, people that care more about decreasing the number of cycles their algorithm costs just for the sake of decreasing it, and, generally speaking, people that care more about increasing functionality rather than experience.

When I first read this article, I was kind of quick to write it off - not because I thought it was a bad idea, but just because I didn’t think it was feasible. I’ve read the article several times and have been thinking about it for a few days. The more I thought about it, the more interested I became in this whole initiative. I then began to think about the open-source community and if it would be, well, open for something like this. I kept thinking about all of the ways in which people who care about design, usability, etc. would be deterred from Linux - then I realized it has nothing to do with the operating system. It has to do with what you’re passionate about doing, and being able to see the manifestation of your work - Linux is definitely provides a platform for doing this. I then began to think about other platforms that was open to a wide array of different users each with a range of different interests where they all cooperate - Wikipedia. I’m sold.

Open-Source Usability is step in the right direction for not only continuing to bring Linux into the mainstream (because I hold the opinion that it still isn’t ready despite so many awesome advances in the past three years), but for improving on the open-source model that has worked so well over the past several years (over a decade, even!). I’m pretty excited to see where this will go.

Joel on Software is a site that anyone and everyone oriented in application or web development should read. Nearly every post he makes has value to it, but his most recent post on web standards is excellent. It does an amazing job of saying absolutely everything that should be said and nothing that shouldn’t be said and it does so in best way possible.