I’ve been thinking recently of how to rotate an image with javascript. I haven’t researched it too deeply and have not figured anything out. But then today came along a great stopgap. Use unobtrusive javascript and flash. Wow. This is a great idea!
Boston University’s A-Z ListingA common navigation element on university web sites is the A-Z list. In general, the lists work as a pseudo-site map. They are effective in getting people to common “tags” quickly.
A-Z listings by their very nature have small hit areas; each letter is linked to a distinct page. These small hit areas are trouble for physically impaired people or people using imprecise pointing devices. Fitz law states that there is a correlation between the distance from the final target and its size to the accuracy of completing the hitting task. In other words, a small link that is far away from the mouse pointer will be harder to click on than a big link that is close to the mouse pointer. A-Z listing are great stopgap solutions for findability, but trouble for usability.
There are a couple of solutions to this problem, but they are not used very often. Below are the A-Z listings for Cornell, Berkeley, and KU. Of these, KU’s is the least ideal solution. Its hit area is small and the spacing between the letters (hit areas) is small. The other two still have small hit area’s but have more spacing between the letters. The spacing should reduce the number of missed clicks.
The first solution to the problem is to increase the hit area for each letter. 
The hit area does not need to be indicated upon first impression, though that would be nice. It does need to have a indicated that area when the mouse pointer is hovering the letter. This small visual cue will confirm with the user that they are indeed about to click on the right letter.
The other solution is to group letters together. Boston University does this. The grouping of letters automatically increases the hit area, which in turn solves the problem of Fitz Law.
I’m starting a library of papers, articles, and other stuff that I run across and read.
Apple is commended for its well-thought product interaction. I have used both iterations of Apple’s iPod Shuffle and have a few suggestions to make the interaction richer. While the idea behind the Shuffle is to mix up your life by mixing your music is all commendable, I think there are a few drawbacks with the Shuffle in continuous play mode. These drawbacks can be easily overcome.
With ambient design features such as beeps and tones, Apple could overcome most of the drawbacks with the Shuffle. The lack of beeping to indicate that an action has been received by the device is the biggest UI issue with the Shuffle. The beep provides audible reassurance to the user that their request for the next song, to stop or to pause has been registered. The beep can then be repeated to indicate things like pausing - that is if the device is drawing a current while it is paused, which it might not to save battery.
The next feature might require a little more work and is specific to the way that I like to listen to music, so it might not have much applicability to the general populous. I listen to music by albums and playlists. It would be nice if the Shuffle could move forward by an entire album or playlist while navigating your music. The way I envision this working is by triple clicking the direction that you want to go. When you triple click, you move forward an entire album and a distinct sound is played to indicate your action.
The last feature has nothing to do with interacting with you music and everything to do with orienting yourself to the Shuffle. The Shuffle is a symmetric design with its squarish shape, circular controls, and small form factor. The controls are offset a little to one side, but that is not enough to orient the user to it. The Shuffle needs a physical indicator to give feedback to the user. A little raised dot on the track forward side of the control circle is all this is needed. With that slight tactile feedback, the user is completely oriented and ready to control his music selection.
Armed with these three seemingly easy to implement features (Audible indicators for tracking, album/playlist skip, and control orientation), the Shuffle can overcome some of its worse interaction design issues.
I am looking for a solution to filtering out my visits and my clients visits from Google Analytics. I am wondering if there is a way to add a custom “variable” to a browser that would be sent back via the http headers. If someone knows how to do this or another solution to my problem, would you please let me know?
Filtering via an IP address or a cookie won’t work. I use and my of my clients use DHCP and I cannot guarantee that cookies are present.
Wireframes in the web design world are quick sketches of the layout of the content, navigation, images, and other design material within a web page. They can also be used to map out the flow of an interaction to complete a task.
When it comes to wireframes, what is the best methodology to use?
I’ve used paper cutouts, drawings, InDesign, Omnigraffle, and Photoshop. None of the methods is better than the other, but I prefer drawings. Wireframes and prototyping are really useful for understanding the problem and coming up with quick solutions. InDesign, Omnigraffle, and Photoshop tend to be too cumbersome for the purpose. Wireframes and prototypes aren’t deliverables after all. The final product is the deliverable. It doesn’t make much sense building and nice prototype when the work on that prototype will simply be discarded in the long run.
Let me clarify a little bit, like most things in life interaction design is a iterative process. The designer draws an idea, thinks about it, modifies it, redraws it, thinks about it, and repeats. If the process is complex enough or there is a meeting with a non-technical stakeholders, then the wireframes need to be a bit more detailed. If the audience is simply a core set of technical team members, then the designs don’t need to progress pass the initial drawing stage. Once that audience grows beyond the core team, then the designs need to reflect some sense of final design at least in terms of color, buttons, links, and other easy to implement design features. The reason for this is because non-technical managers will get hung up on the design and won’t be able to focus on the real reason for the meeting. Usually the real reason for the meeting is to discuss the flow of pages, the placement of content, and the workflow needed to make the concept a reality. When the meeting gets hung up on the design, little progress is made.
