• Jeff Rubin's table showing usability objectives/activities during development life cycle (as discussion in class).
• An article (2007) in the Economist discusses what's missing to get to the next level of User Interface design... we've come a long way, baby, but there is plenty of room for improvement! The interesting thing here is that it suggests that touch-based, gesture-based GUIs (which were novel in 2007) might be the key to moving forward, breaking through to new usability. Hmmm...so did that work out?
• As an interesting follow-on to the above, a nice (2011) article in the CACM discusses whether we've made any progress at all with iOS-like GUI approaches...or whether we've actually moved backwards. What do you think?

Usability Lab info:

• The Usability Lab is in Rm104 and Rm104a (two-room setup). We will talk in some detail about setting up and running tests in lecture. Below are a couple of logistic reminders are how-to's
• Scheduling lab time: Normally we've done old-fashioned scheduling: paper on the door, you sign up. This works but is so last decade. This year I want to offer you an alternative: I've made an account on setmore.com, which is a for-pay (with free tier!) web app for allowing small businesses to schedule clients. Here is everything you need to know on how to use it.
• Here is a fairly complete description of how to use the lab: one part for firing it up, another checklist for shutting things down.

Java programming links:

• Here is a link to Sun's Swing Tutorial. A pretty nice little series of coherent introductions to Swing programming. As good as any book that I've seen.
• Packaging your final Java project as a stand-alone application. Putting everything is a single runnable jar is super-tight and clean. But requires a bit of know-how to make sure your program can find/access the resources in the runnable jar.
  
  The overall solution is based on the simple observation that you do not have your "home" filesystem in place when the app runs...or at least, not one your application knows anything about. Where you usually access resources by direct or relative paths with respect the executable (often by just placing resource files in the same folder as the application), none of this works in the context of a jar file. A jar file is it's own little world, that has to execute in the absence of any real file system embedding. Fooling with classpaths, etc. doesn't really work...because there are no paths inside a jar. The solution is to change how you access your resources in your code, by using "getResource" tools (all based on ClassLoaders) that know how to search for targeted resources where you tell them to look...in this case, inside the jar file. Note that this approach: using "getter" classes, is a desirable programming technique anyway, supporting the nice, clean packaging of code up into "packages" that help control the negative interactions and complexity in the code base.
  
  With this in mind, there are a couple of ways that you could implement this:
  • Slick but manual approach: You package in up yourself, and define your manifest, and away you go. Great if you really want to learn how it works in gory detail.
  • The automatic approach (recommended): just let Eclipse do the work for you. Most modern IDEs support exporting of Java projects as runnable jars. They essentially just do what was described above (last bullet) for you: package up the jar, create the proper manifest, poof, you're done.
• How to use Subversion for managing your team's codebase. For those who still like Subversion, and haven't discovered the beauty of distributed version control and GitHub yet. Before you click this link, I recommend checking out Git (and Github.com ... it's free). It'll change the way you see version control!

Android programming links:

• Because Google and about everyone else besides Apple wants programmers to develop cool new apps for Android, the official Android developer site is predictably very very good. I was able to go from zero to programming something useful in about four hours using the resources here. If you are a rank beginners with Eclipse development (I'd be surprised at the CS477 level) you should leave yourself more time....but even then, you should have a nice little test app programmed and loaded to a device in less than 6 hours.
• If you're an Android novice, I would recommend starting with a leisurely hour or two just reading about how the framework works. I really enjoyed the resources on the Android developers guide for this; read the Android Basics section is depth, then sample the Framework Topics a little just to see how different things work.
• Before you read much more, I feel it's best to get your feet wet. Head on over the excellent tutorials, and walk through a few. This will (a) help you get your dev. environment set up and figured out and (b) will give you an early feel for the Android development cycle.
• Particularly useful, in my opinion is the Eclipse ADT plugin. This provides a ton of useful tools for developing Android apps in Eclipse, most notably an SDK manager and an AVD manager to help you target your code to the appropriate platform you are shooting for... and/or for testing your code on multiple emulated platforms. Highly recommended!
• Another useful plugin, if you happen to be a fan of the GIT DVCS code management system, is the Egit plugin. Not without its fault, but useful once you figure it out. A much nicer GUI version control tool if you develop on a Mac is Source Tree, which I like quite well...although it isn't built right into your IDE. Dang nice for a free piece of software though. Or of course you can just use the tried and true command-line approach to Git (sometimes beats fiddling with plugins).
• Once you get over the startup hump, have a closer look at the more advanced training resources on the Android site. These articles cover some outstanding topics, e.g., designing for multiple screen sizes, and other tips for tackling what is most certainly the central challenge for all Android programmers: dealing with the *incredible* diversity of devices, screen sizes, and device capabilities out there.
• ANDROID DEVELOPMENT AND TROUBLESHOOTING TIPS: Problems that I've seen and solved. Shoot me a note with more questions and answers to add to this list, if you figure out a common problem that you don't see listed here.
• Google is no dummy, they know the value of consistency across apps on a platform! Check out this whole site devoted to training Android developers to use "standard" mechanisms and layouts, in the interest of producing uniform, consisteny GUIs across all Android apps. Very smart, Google!!
• Abe Pralle is an experience Android developer and have prepared a very nice guest lecture to intro Android programming. Here are his slides for that.

Links of general interest:

OK/cancel. Great UI community site, lots of funny UI comics, stories, etc.
The User Interface Hall of Shame
HCI Bibliography (a searchable bibliography)
HCI Reading list of good books (by Jacob Nielsen)