I’ve been helping out with organizing a 3-on-3 basketball tournament for my church (Lakeview Church) and we’re looking for teams to sign up!

We have a men’s retreat coming up in September and thought that holding a 3-on-3 tournament would be an excellent way to raise some funds for the retreat.  Here are the details:

When? Saturday, 8/14/2010 – Starts at 10 AM

Where? Christian Liberty Academy (502 W. Euclid Ave. Arlington Heights, IL  60004)

Who can participate? High school & Older

How much will it cost? $40 per team.  You can have up to 4 players per team.

How do I register? Click here to print out the registration form.  Fill it out along with a NON-REFUNDABLE check for $40 to Lakeview Church (65 E. Palatine Rd. #313  Prospect Heights, IL  60070).

When do I need to send in my registration by? Sunday, 8/8/2010

What do I get if I win? $$ + Bragging rights

Sign up TODAY!  Please let me know if you have any questions!

Anyhow, with the resurgence of my interest in UI-related work, I decided to pick up a copy of Steve Krug’s Don’t Make Me Think (2nd Edition).  If you haven’t read this book and have any sort of interest in web usability, I highly recommend you pick up a copy of it.  I’ve read about 2/3 of it thus far and it’s given me some really good things to think about and consider as I do my own front-end development work.  As the title of the book suggests, Krug’s big emphasis throughout his book is this:  Allow the end-users of  your website/web application to use the least amount of brain power to perform their desired tasks.  Don’t make them think. While usability issues are not always black or white and that they sometimes do come down to a matter of preference, I really like the fact that Krug gives some excellent, concrete guidelines that help readers to be able to distinguish between a usable website versus a not-so-usable website.  Even though the fact that our company’s software is a subscription-based web application with a very limited audience in mind (pharmaceutical professionals) means that not everything in this book is directly applicable, I think there’s a lot of UI-related gems to be gleaned from reading this book.

Once I finish this book (hopefully by today) I’ll definitely be looking to get my hands on some other UI-related books.  Any recommendations?

By the way, here’s the link to Krug’s book on amazon.

1. Vocational Training: In my case, I’d like to teach software development–anything from teaching students how to write programs consisting of nothing more than simple algebraic expressions all the way to full-blown applications that people can utilize to solve everyday problems.  This will be my focus in this blog post.

2. Gospel: Proclaiming the great news of the Gospel–perhaps most eloquently summarized in john 3:16–primarily through music, preaching, and the sharing of testimonies.

My reasons for wanting to teach software development in this context are numerous but in a nutshell, it is as follows:  While I, like most people around me, can get sometimes get into the habit of complaining about the things that I do not have in my life, when it’s all said and done I have been blessed with so much and perhaps more importantly, with so much to give.  I’ve been blessed with a good education, a  job that I enjoy, and in software development a skill set that is not only valuable in today’s marketplace but one that will only grow in its demands in the foreseeable future.  I would love to be able to share this skill set with those who may not be fortunate enough to have even the opportunity to learn this truly enjoyable (at least for some) and valuable skill set.

I am in a completely brainstorming mode here, but this is what I’ve been thinking of as it relates to actually carrying out this little dream of mine:

*Funds and Materials Needed: Plane tickets.  Lodging.  Room/building rentals to hold classes in.  Teaching materials.  Student materials (such as notebooks, writing utensils, etc).  Food for the students and myself (as well as any others who may join me).  LCD Projector.  Laptops/Netbooks (to be given away to students at the conclusion of the trip).  Backpacks.

*Fund Raiser: While I’d most definitely be willing to spend my own money to carry out this task, since I’m not looking to make even a single penny off of this endeavor, I think it would be perfectly right to attempt to raise all of the necessary funds through various fundraising activities.  I’m thinking some kind of a benefit concert/coffee house.  Musical skills can come in handy at times. :)

*Duration: 2 weeks.  I’d need to use my own vacation time to do this, which means it can’t be too long.  Once I arrive at my destination, classes would run from morning until early evening with free lunch and dinner.  Night time activities would consist of music as well as various forms of gospel proclamations.

QUESTIONS:

Here are some questions I have floating around in my head:

-Location? Where to?  To make the trip as cost efficient as possible, I’d like to stay as close home as possible.  Somewhere between the western edges of North America and eastern edges South America seems like a good candidate.  Haiti is one of the countries I’ve been thinking of, but I’m sure there would be plenty of other good candidates as well.

-Why overseas? To be honest, I’m not so sure I can answer this clearly.  I know that there are despicably impoverished places in my own country.  Not having to travel overseas would mean that the trip would be cheaper.  It would certainly be more convenient as my money, language, appliances, and cellphone would all work just fine.  I think when it comes down to it, though, wanting to go overseas is more of a personal, perhaps somewhat selfish motive of mine.  I feel that by traveling overseas to carry out this task, it would somehow enrich my experience and help me attain a better  understanding of what it’s like to do missional philanthropic work.

-The Gospel? Do I need to include the Gospel?  There’s a part of me that would prefer that this missional philanthropic endeavor simply be a philanthropic endeavor.  It would be easier.  I wouldn’t have to deal with anyone accusing me of carrying out some sort of a bait and switch scheme or a feeble attempt at proselytization.  And while I do not think it would be wrong for me to not include the Gospel (and am slightly open to the idea) I am a bit disturbed by the fact that if my purpose is to go help people why not go the extra mile and share with the people what is most helpful?  More helpful than knowing how to write code… more helpful than any practical skill set one can attain… something they can have and hold onto when they have absolutely nothing to hold onto?

-Why not simply give $$?  Why not work harder, make more money, and give to the expert philanthropists who are already involved in doing this sort of work?  Perhaps wanting to carry out this endeavor myself stems from somewhat of a selfish motive… however, I think most people will agree with me that giving money can get, well, a little bit boring.  I want to get my own two hands dirty in this kind of experience if I have the opportunity to do so.  Being able to carrying out this kind of task from start to end is a thrill that I only hope I will get to experience sooner than later.

This is all I have to say for now.  I would most certainly welcome your feedback either via this website, Twitter, Facebook, or email!  If, by any chance, you are even remotely interested in partnering up with me on this in any sort of capacity, please do let me know. :)

Anyhow, here are some (among many) pictures I took while I was out there.  Enjoy!

After listening to it, just in case you’re curious here are some of the chords I’m using (capo on the 4th fret):

024100

034100

2×2200

4×4440

…some of my favorite chords.

I have to tell you, I was in such a good mood at work today.  I finished up a small project which I had begun last week (it feels so very good to make your final code commits… even though you know that bugs will be found, requirements will change, and something will inevitably be wrong with your code), and today I had to come up with a UI design for a filtering component in our application.  To put it simply, our application has various “list” screens that list a lot of records and each of these list screens have a filtering component that can filter the records that are displayed to the user.  They pretty much function as search pages.  Anyhow, I was asked to come up with a design so that our users can not only search for records (existing functionality) but can also perform CRUD (create/read/update/delete) operations with their search settings.

Sounds like a ton of fun–was my first reaction. :)  I was enthused about taking on this task because I saw this new functionality as being such a useful functionality for everyone–end-users, QA folks, us developers, business analysts, etc.  I knew that anyone and everyone who uses the application would benefit from this functionality and find it extremely handy.  Another reason why I liked taking on this task–I was told only the very high-level requirements–namely, that this functionality should allow the users to perform CRUD operations with their search settings.  There was no story (i.e. requirements) written for this functionality and no mock-ups.  It was all up to me.  I love such freedom.

Well… without further ado, here are the steps I took to tackle this task.  The last step is still in progress. I call this my User Interface Design 090:

1. Screenshots: Since this was going to be an addendum to our existing search dialogs and list screens, I took screenshots of all of the screens that were going to be affected.  I then opened the images up in Gimp, cropped them so that only the parts I want are captured and then copied them into Open Office.  I always find that to be a handy way of printing out screenshots that fill up as much of the paper as possible.  There’s just something special about doodling on papers as opposed to staring at the monitor–it lets me be a little bit more creative.

2. Research: It didn’t take me too long to realize that I’m not the first person in the world to implement this functionality.  This has been done many times before.  Originality is good but why waste time trying to be original when there are already perfectly fine existing implementations of this functionality?  I looked at various implementations of this–Bugzilla (opensource bug tracking software we use), Twitter (did you know you can now save your search settings in Twitter?), eBay, and even my BlackBerry Bold–the email application.  I spent some time playing around with all of these applications.  I made mental notes of things I liked and didn’t like, things that made me happy as an end user as well as things that made me scratch my head a little bit.

3.  Doodling: After my research was completed, I went to the hard copies of the screenshots and simply stared at it for some time, trying to come up with a mental image of how I want this functionality to be implemented.  Slowly, little by little, I started drawing the necessary components–checkboxes, text fields, buttons, etc.  I also made various written notes on it–things that can’t be explained by drawing alone.

As I was doodling away, I tried my best to get into the mindset of the end user.  To me this is such a crucial step in UI design work.  In the end, when it comes to the UI, it is my end users that I need to please.  I can build UIs that make my boss super impressed, the QA folks really happy, and my fellow developers envious, but if my end users aren’t gonna like it then I have failed.  And that not only makes me look bad, but it makes my team look bad and the company look bad.  I tried (as best as I could) to get into the mindset of our end users who use this software–for folks who have absolutely no aptitude nor interest in building software.  And to be honest, I wasn’t exactly sure how I could most effectively accomplish this other than to simply take my time asking the What Would the User Do? question with every single doodling element I added on those screenshots.

One more thing to note–as I was doodling, I didn’t give too much thought to the limitations of the architecture/APIs.  As long as I knew I wasn’t doing anything crazy I was let myself doodle away.  I think it’s a bad idea to be bogged down with such limitations in your creative thinking stage.  I’m not saying ignore all limitations.  I’m just saying don’t worry about such things too much too soon.  I can’t see how that’s going to help you come up with a good UI design.

After I got done doodling, I imagined myself as an end user accessing my doodle-turned-UI.  As I went along this step, I made a few adjustments I thought were necessary.

I then went to Chipotle and rewarded myself with a 1110-calorie (yes, I did check my facts online) chicken burrito.  SO GOOD.

4. Mock-up: Scribbles you’ve got written down on pieces of paper are useful but it’s even better (and more useful) if you can get them down electronically.  After lunch, I made use of the Pencil Firefox add-on, which is a tool built specifically for UI mock-up purposes.  You can drag and drop various UI-related items such as checkboxes, text fields, dialogs, fieldsets, and many more.  It’s super easy to use.  You can then export your finished work into a .png file.

This step took me no more than an hour to complete.  Pretty impressive considering the fact that it was my very first time using this tool.

5. Consultation: After I finished mocking everything up, I sat down with my boss and discussed my mock-up with him.  A lesson to be learned here:  It’s a good idea to run your UI (or anything else, for that matter) ideas by someone.  It doesn’t have to be your manager obviously, but it should be someone who is familiar with the software as well as the end users’ uses of the software.  My discussion with him proved to be valuable since during our conversation a few things came up that I hadn’t addressed in my original mock-up.

6. Requirements: I got to write up a user story which details the new functionality.  We make exclusive use of Google Docs for such purposes at the office.  This is the first company I’ve worked for where that’s been the case and I’ve been really happy with doing it that way (What would we, software developers, do without Google?!?).   I included the mock-up (exported as .png files) in the story.  I tried to be as detailed as possible without specifying the implementation how-to’s of the new functionality in the mock-up.  Even though I will most likely end up working on this feature set, the right thing to do when writing user stories is to leave such details out.  Let others worry about the implementation details.

7. Review: Perhaps this should be bundled with the above step, but for emphasis-sake, I thought I’d make this into a separate step.  It’s never a bad idea to review.  If there’s one thing that being in seminary for 4 years taught me, it’s that you almost always discover mistakes when you’re re-reading through your essays.  I read through what I wrote down in my user story.  Surely, some minor edits were in order.  I then printed out a hard copy of it so that I can take it with me and re-read through it before I arrive at the office tomorrow.  As of now, the printouts are sitting on my desk next to me.  If I finish this blog post up soon enough I’ll be sure to read through it before I go to sleep. :)

And this concludes User Interface Design 090.

As always, I’d love to hear your comments/questions/feedbacks via this website/Facebook/Twitter.

If you’re not in the mood to watch the video, it’s an instructional makeup video.  :)  I met her (Hanh Bui) at Kollaboration,  which is an annual/semi-annual Asian-American talent competition show which I performed at 2 weekends ago.  She was one of the judges at the show.  Here’s a true YouTube celebrity with about 80,000 subscribers and over 2.8 million views of her videos.  Those are some crazy numbers, if you ask me.

While I”m not into wearing makeups, I’m at least a little bit flattered by the use of my music in her video.

2 rather brief blog posts in a row–I promise the next one will be much longer.

I like.

If you write code, write tests

The pupil asked the master programmer:

“When can I stop writing tests?”

The master answered:

“When you stop writing code.”

The pupil asked:

“When do I stop writing code?”

The master answered:

“When you become a manager.”

The pupil trembled and asked:

“When do I become a manager?”

The master answered:

“When you stop writing tests.”

The pupil rushed to write some tests. He left skid marks.

If the code deserves to be written, it deserves to have tests.

So here they are!

PART I:  First, I’ll start off with tips that deal with helping you (and your band) to become better prepared for band rehearsals:

1. Recordings: If you want to make the most out of your rehearsal, it is absolutely crucial that everyone in the band knows the songs before they get to the rehearsal.  It is very helpful for everyone in your band to hear recordings of the songs you’re planning on rehearsing before the rehearsal.  Unless the recordings deviate greatly from how you want your band to play the songs (which may accomplish nothing more than confuse the people in your band), email out the recordings to your band before the rehearsal–even if the recordings do not sound like how you want your band to play the songs.  For people who are in your band, being able to listen to the recordings will help them become mentally prepared for the rehearsal.  If you don’t have the recordings at your possession you may want to check out grooveshark.com or youtube.com and simply send the URLs of the songs to your bandmates.  Both websites contain enormously large databases of songs.

If, for various reasons, recordings of the songs you’d like to perform do not exist (i.e. in the case of originals) I’d say take some time to create a recording on your own.  Even a simple recording with just a guitar and voice will be very helpful for your bandmates.  And you most certainly do not need any “professional” recording equipment.  Just get yourself a cheap computer mic and use a freeware such as Audacity which will enable you to do multi-track recording on your computer.  The sound quality will be pretty bad; however, even a cheap-sounding recording is way better than no recording at all.  Trust me.  Take those extra 30 minutes to create a recording and you may very well save yourself and your band 30 minutes of rehearsal time because no one in your band knows the song.  If you’ve got a few hundred bucks at your disposal, do yourself (and your band) a huge favor by picking up some audio recording gears.  If you have a decent computer you can create some really nice sounding recordings with equipment that will cost you less than 400 bucks (including a condenser microphone, mic stand, cables, etc.).  It’s simply astounding how cheap these recording devices are these days.

2. Chord Charts: Spend some extra time to prepare nice, clean, readable, correct chord charts.  Please, please, please don’t be lazy and grab those online guitar chord chart/tabs and print them out!  They are not very readable and the chords on them may very well be wrong.  Anyhow, back to chord charts…: I’d suggest including the following in your chord chart (sorry, most of these will be painfully obvious): title of the song, key, tempo, sections (i.e. verse 1, verse 2, chorus, etc.), lyrics (duh), chords (duh duh), scan (the flow of the song–such as v1 -> v2 -> chorus -> v3 -> chorus -> bridge -> chorus…), composer, copyright info.  Here’s a screenshot of a chord chart for a song I play rather frequently (note: I cut out the middle, unnecessary portion of the chord chart):

Some additional notes regarding chord charts: If you’ve got a song where some musicians will play the song in different keys (for instance, if the song is in the key of F#, the guitarist may put the capo on the 2nd fret and play the song in E; the keyboardist may prefer to play it in G and transpose the keyboard down half a step) be sure to prepare copies of the chord chart in all the different keys.  Most of the copies of chord charts I have are in various keys.  For instance, if I have a song entitled Hello, I may have Hello(C).doc, Hello(B).doc, and Hello(A).doc.  If you’ve been playing in bands for any significant length of time, you should know by now that most musicians can’t transpose on the fly :)

3. Notes on Chord Charts: In many cases, it’s not enough that you have chord charts–you need some extra notes on them for yourself and your musicians.  On the chord chart, include some notes regarding items such as:  Who’s supposed to play the intro, which instruments should come in where, and highlight any important parts of the song.  And when you make copies of the chord chart, it might be a good idea to make copies of the chord charts with notes on them for all your bandmates to see.

For an example click here.

4. *Know* the song: If you’re the lead person in the band, you of all people should *know* the song inside out.  And not only should you be familiar with your own part, you should have a pretty good feel for all the others’ parts as well.  It doesn’t mean that if you play the guitar and are the lead singer, that you should also be able to play the keyboardist’s part as well as the drummer’s, etc.  However, you should at least know when each instrument/vocalist comes in and out and have a rough idea of what should be played.  Knowing what each musician should play (or sing) will help you discern how well your band is playing during the rehearsal.  After all, “that sounded really bad… period.” is not a very helpful comment for your bandmates to hear.  You, as a leader, should be able to say, “that’s not quite how it should sound… how about you try something like [blank]?” If you’re the lead person in the band, knowing how to play more than just your instrument and/or sing harmonies will be extremely helpful.  (And it is *never* too late to learn!)

And while we’re on the topic of *knowing* the song, you should spend a good amount of time practicing on your own before the rehearsal.  This is especially important if you’re the lead person in your band.  Practice is good and good practice makes perfect.  And while you’re at it, may I suggest getting into the habit of practicing with a metronome (if you’re not already in the habit of doing it, that is)?

…And now…PART II:  Here are some tips that deal with helping you with the actual rehearsal:

5. Metronome: I’ve recently gotten back into the practice of using a metronome during the rehearsal.  I’m sure are there are different ways of doing this, but here’s how I do it:  Come rehearsal time, I hand over the metronome to the drummer and the drummer sets the metronome in a “mute” mode while the thing clicks away.  Most metronomes, along with the ticking sound, have blinking lights that blink at the specified tempo, thereby allowing the drummer to put the metronome down off to the side and look at the blinking light via his/her peripheral vision.  That way if the drummer goes out of sync with the metronome all that needs to be done is to look away (instead of being torturously thrown off by the off-beat ticking noise) and attempt to get back in sync with the metronome.

Back in the day, a long long time ago, I once had the metronome hooked up to the sound system during a band rehearsal so that the entire band could hear the metronome’s ticking sound.  That was a VERY bad idea… so bad that I still remember it after all these years.  If you really want to annoy your band, give that a try sometime. :)

6. Sound Person: This tip might be way too obvious, but it’s a really good idea to have a sound person at the rehearsal.  It’s just too much work having to go back and forth between the mixing board and your instrument/microphone and attempt to adjust the levels and EQ.  I used to have to do this all the time and it can get pretty annoying having to constantly go back & forth back & forth.  I am so very thankful there’s always a sound person at my band rehearsals these days. :)

7. Only Certain Parts: In a song, not all sections of the song are of equal importance.  And, not all sections of the song are of equal level of difficulty.  Some sections are easier, some are harder, some are really important (where if you make a mistake at that spot, you’ve just killed the song and might as well do-over), and some are really not nearly as important.  During (better yet, before) the rehearsal, determine the parts that are of higher importance & difficulty, and focus on those parts during the rehearsal.  Don’t just play the song from beginning to end X number of times and call it quits.  And if you need to get nitpicky, get nitpicky but pick and choose when and where to get nitpicky.  Getting nitpicky over sections that are of higher importance is always a very good idea.  Getting nitpicky over sections that aren’t really all that important may not accomplish more than cause annoyances amongst your bandmates.

8. Is That All?:  When you think the rehearsal is almost over, ask yourself is there anything else that we need to go over again? Ask yourself (as well as your bandmates) if there are any songs (or sections of songs) you should go over again.

… and that’s it. :)   I hope these tips will be of help to you if you play in a band at any capacity.  Please let me know if you’ve got any comments and/or questions!