junhopark.com

I’ve been meaning to write this post last weekend but oh well, better late than never, right?  Last Saturday I attended ChicagoWebConf which was organized by DevMynd.  It was good.  I learned some rather useful things and all in all, I’m very glad I made it out.  Here’s a list of tracks I took:

-Quality Development with HTML5 and CSS3 (Shay Howe)

-Real Typography for the Web (David Demaree)

-Web Accessibility (Mark Meeker)

-The Right Way to Wireframe (Russ Unger)

-The Visualization Renaissance (or more appropriately titled Using SVG w/ Raphael.js) (Sam Tesla)

-User Experience Thought Process (Ryan Singer)

Of these, my favorites were Real Typography for the Web and User Experience Thought Process.  Both came with excellent presenters and they presented on exactly the kind of thing that I was expecting to hear from those guys.

David Demaree did such a good job of explaining why typography is so important to a web application (or, any application/website/product for that matter) and how correct typographical usage can drastically improve the usability of the application.  It’s so much more than things simply “looking pretty”.  Good typography serves very useful & tangible purposes.

Ryan Singer did an excellent job of walking the audience through his thought process when he’s working on a UI design.  I loved it because it was extremely practical and he did a great job of actually demoing the very thing he was talking about.  He took a sample web app that had various usability flaws and by the end of his talk, he had created a prototype of this web app with some very significant usability improvements.

For $75 (early bird fee was $50.  Wish I could’ve jumped on that) I really could not ask for any more.  I can’t believe the whole thing only cost attendees $75 or $50!  AND they gave us breakfast and lunch.  It makes me wonder why software conferences & training often cost SO freakin’ ridiculously much.

Great job in putting this together, DevMynd!

One of the main purposes for keeping this blog is for me to think through and reflect upon things and to remind myself of the lessons that I’m learning.  I keep myself pretty busy (there never seems to be enough hours in a day) and from time to time (more often than I would like) I will go through an entire day without having reflected upon what I’m doing and how I can improve upon my work.

So I thought I would press pause for a bit and give myself some reminders on writing good software.

1. Write first, refactor later.  While I was in school I really disliked writing papers, not necessarily because I didn’t enjoy writing papers, but more so, because it usually took me extremely long to write an essay, even a simple 3 to 4-page essays.  And one of the reasons why it took me so long to write papers was because I often thought and long and hard about each word I was putting down on paper as I was typing out the words.  I tried to write “the perfect paper” as I was typing crunching out the paper, and well, that usually turned out to be a not-so-good idea.

Same thing with writing songs.  It usually takes me an excruciatingly long  time to write a song because I try to write the perfect lyrics as I’m writing them down.  Again, bad idea.  The better idea, as I’ve learned from other songwriters, is to write down the words as they’re streaming out from my brain.  Almost in an unconscious fashion.  And once a draft has been composed, go back to the lyrics and do a rewrite.  And another rewrite.  And another and so forth.

When I’m writing code, I find myself having to remind myself that it’s perfectly O.K. to not write the perfect, most optimal, most readable code on the first try.  It usually saves me a ton of time to type out what simply works and then go back and perform refactoring.  Write tests to make sure that as I’m refactoring, I’m not breaking my own code.

2. Details, details, details.  It’s easy to write code that works 95% of the time.  It’s so much harder to write code that works 100% of the time.  Pay attention to the details.  Over the last few years in my career, I’ve been writing more & more front-end code and it’s often really easy to gloss over all of the different ways in which end users will interact with the application.  Don’t just assume that users will interact with the application in ways that I would.  As I’m writing code, I need to always try to break my own code.  It’s interesting to me just how much easier it is for me to break someone else’s code rather than my own.  If someone else wrote the exact same code that I wrote and I was asked to test both my code and this other person’s code, I can guarantee that I will find a ton more bugs with this other person’s code.

3. Code slower. I get a rush from getting things done.  It applies to pretty much everything in my life.  Oh how I love crossing things off from my various TODO lists.  It’s the same thing with writing code.  As a paid employee, I’m basically paid to produce as much as possible, as quickly as possible, in the highest quality possible.  As such, I find that there are times when I will write code only to later realize that I probably would’ve been just fine to code a bit slower and give myself more time to more deeply think about the code I’m writing.  And perhaps this conflicts with my point #1 above.  Or perhaps it doesn’t.  The point is, I must not forget that I’m not paid to create software that simply works in the time allotted but rather, to create software that does its job as well as it can possibly do.

I’m getting one year older in just a few short weeks and like many of my friends, I’m finding that the older I get I find myself becoming less & less voluntarily-open about disclosing my age (unless I happen to be around a bunch of old fogies… in which case I’m more than thrilled to share my age).  This has led me to (again, like many of my friends) revealing only my birth date and not the birth year on my Facebook account.  I decided to reveal my birth date since it alerts my Facebook friends when it’s my birthday, which then causes a whole great number of my friends to write a brief message on my Wall wishing me a happy birthday, which then causes various sorts of warm & fuzzy feelings to take place inside of me.

Nothing wrong with warm & fuzzies.

With that said, I’ve noticed there’s gotta be some sort of a relatively mild-to-major bug with Facebook when you view Facebook on your mobile browser.  Well, this issue is, at the very least, apparent with the native browser on my BlackBerry, which tells me that this issue is most likely apparent for a great number of people.  It may very well affect you.

I’ll try to keep the gist of this bug short.

To see this bug in action, open up the browser on your mobile phone (again, I have no clue exactly how wide-spread this bug is) and go to www.facebook.com.  After the page loads, if any of your friends’ birthday is today then it will remind you in the notification section towards the top of the page.  If only a small number (2? maybe 3?) of your friends’ birthday is today then it simply displays your friends’ names which are hyperlinked to their Facebook profile page.  However, once that number exceeds a certain threshold, Facebook will render yet another link whereby if you click on it, you’re taken to a Today’s Birthdays page whereby you can see ALL of your friends whose birthday is today.  And when you click the link to take a look at this page, you will see  just how old each of your friend is.  The annoying/bad/scary-for-some-of-us is that I know for a fact that Facebook will reveal your age even if you specifically tell Facebook to ‘Show only month & day in my profile’ in your Profile Edit page.  See a picture of this in action below (I’ve blurred out the profile pictures and the names so that my friends will still continue to be friends with me):

Facebook - can you please tell me how old my friends are?

So what can you do if you don’t want your age revealed on Facebook?  Well, no guarantees this would work but my guess is that in your Profile Edit page, if you specify ‘Don’t show my birthday in my profile’ then Facebook will (probably) not remind any of your friends when it’s your birthday even on their mobile browsers.

Another option?  Change your birth year to some ridiculous number, which is what I have decided to do.  I would think this trick would work since no one sane would then believe how old you are.

As of today I am over 100 years old, at least according to Facebook.

***EDIT***: Even if you don’t have a mobile device to try this on, you can see this in action by going to http://m.facebook.com

**2nd EDIT (3/23/2011)**: It looks like Facebook finally got around to fixing this issue.  Sadly as a result, however, this blog post has now become completely irrelevant.

One of the things I’ve been enjoying about work since I made the switch last November is being able to get my hands dirty with front-end web development and being able to work on things that directly impact the usability of the application.  It’s been fun designing and writing code that will allow our clients to have an easy & efficient way of interacting with our software.  It’s been challenging as well–such as trying to make the front-end behave the way I want it to in IE 6.  I can’t believe some (a whole lot) people still use IE 6 but there’s not much I/we can do about it, at least for the moment.

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.

For some time now I’ve been really interested in going overseas for the purposes of doing missional philanthropic work.  And by “missional philanthropy” I am specifically including the following 2 components:

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.

Do you remember how in college there were classes that were actually below 100-level?  The classes that some folks were required to take but they didn’t count for any credits?  Well, in trying to come up with a decent title for this blog post, I thought I’d throw in a 090 at the end of the title there since this post will be, in some ways, kinda like those sub-100 level classes.  Simple (or simplistic, even), easy, basic-knowledge kinda stuff.

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.

So… I’m scrounging around the internet looking for some TDD-related tidbits and I came across the following at www.artima.com.

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.

At work we have a huge product release coming up very soon.  There are a lot of new features to the application, which means that there has been a ton of changes to the code, which has meant a lot of hours for testing.  As a result, I’ve been having to help test–in volumes I don’t think I have yet in my software development career.  I’ve had to run the application through a variety of test scenarios as well as going back to bugs and verifying that they, in fact, have been fixed.  In the last week or so, that’s where 90% of my time has been spent.  While I’m a little sad about not being able to code nearly as much as I’d like to at work, I’m glad for the lessons I’ve been able to learn in my very brief stint as a QA personnel/software tester.  One thing I’ve been realizing is just how incredibly expensive writing buggy code is.

Having to devote so much of my time towards verifying bugs that have been fixed has given me a rather fresh awareness of just how expensive writing buggy code is.  If a developer (say, Developer X) writes code that isn’t quite right (or extremely wrong) in the first place and commits his/her code, well what happens?  Since QAs do not tend to test code that have been committed right away this means that once the code has been committed, chances are pretty decent that the at least 1 other developer on the team (say, Developer Y) will start making use of the code that Developer X has committed.

Fast forward a few weeks and now it’s time for some testing by the QA (Tester A).  Tester A finds some issues with Developer X’s code and files a new bug (expense).  And the expense comes from more than simply identifying the bug.  You see, often times it’s much easier & faster to see that something works than to see that something doesn’t work.  Unless Developer X is just a horrendous developer and most of the code he writes is buggy (in which case he should be doing something else…) QA will most likely give the developer some benefit of the doubt, which can amount to be an expensive “task”.  I’ve been noticing this a lot in my own testing.  When I come across buggy code, the first thing on my mind is not that there is something wrong with the code, but rather, that I must not be seeing something correctly.  At this point, I will almost always re-perform my testing (expense) and my understanding is that this is true for other, more seasoned software testers as well.  When a code a person is testing does not quite work right the first time around, that same piece of code may very well be tested at least 2 or 3 times before a bug is eventually filed.  Again, expensive.

Okay, so after the bug is filed, Developer X then has to go back to the code that he wrote a few weeks ago and try to remember what he did (expense).  There is also the hidden expense of  disruption to his flow of work.  And of course, unless the code that was written was super simple, it’s going to take some time to recollect why the code was changed.  Thanks to source control, seeing what changed is a simple task.  Trying to figure out and/or remember why something changed can be a pretty tricky task.  The Developer X thinks, thinks, and thinks (expense) and looks through not only his code but code that others have written which may very well have changed since the time he originally wrote his code (expense).  After some time, the developer figures out what’s wrong and fixes up the code.  Developer X commits his code.  Updates the bug that was filed in the bug tracking system (expense)–a process which often takes more time than one would like.  It tends to take a lot of time because trying to write something that is both concise & informative can be a tricky thing.  You don’t ever want to write (or read) an essay in the bug tracking system.

Once the code has been committed and Tester A has been notified, he may need to drop everything that he was working on in order to test this code, which means disruption to his flow of work (expense).  Re-testing code can be a very disruptive thing.  Once Tester A tests the code and verifies that it is working (hopefully) Tester A has to go back to the bug he filed into the bug system and make updates to the bug ticket (expense).  And once this takes place, there will have to be, at some point in the future, yet another test to verify that the bug has been fixed (expense).  While this last step isn’t completely necessary, I think it’s much too risky to leave this step out.

Obviously, if upon re-testing the code Tester A sees that either the bug hasn’t been fixed or worse yet, more bugs have been created as a result of fixing the original bug, well… that just means more and more expense.  And honestly, having to re-re-test code sucks.  BIG time.

At any rate, let’s say that Tester A finds that the code has been fixed and things are working correctly.  Not all may be done at this point, however.  Remember Developer Y?  The developer who made use of Developer X’s buggy code?  Developer X’s buggy code may mean that Developer Y has to go back to the code he wrote (expense).  Bug(s) may be filed against code that Developer Y wrote to no fault of his own (expense).  Developer Y may get really frustrated at Developer X (expense).  And if this kind of thing becomes a pattern, this will mean more & more expense for the entire team since other developers are going to become growingly weary of any code that Developer X writes, no matter how simple it is.

So, to sum it up:  As developers, it is critical that we write code that works the very first time around.  Code that works results in efficiency, happy developers, happy testers, happy managers, and less money wasted.  Writing buggy code results in slow-downs, demoralized developers, cranky testers, angry managers, and a lot of money wasted.

I briefly alluded to this in my last blog post, but sometime early last year, I launched a very simple website for my parents’ shoe repair store (www.moodyshoerepair.com).  And when I say simple, it is *very* simple.  All it has are a number of static pages with a few pictures and some blurbs pertaining to the store.  You know the website is a simple one when the most complex part of the website is the CAPTCHA validation that exists in the ‘Contact Us’ page.

At any rate, here are some things I’ve done so far to maximize the benefits of this website:

1. I submitted the website’s URL to various websites that act as a gateway to other businesses–such as Yelp and Manta.  I thought this would be a good idea since websites such as yelp.com holds information pertaining to a ton of other businesses.  I see it as free advertisement.

2.Business cards:  I ordered new business cards for cheap through Vistaprint and included the website URL in the card.

3. Google AdWords.  I was offered a free trial for Google AdWords.  I believe it was a $10 credit.  It was my first experience with Google AdWords and it was a positive experience.  I was basically given a slew of options that would help AdWords decide when to display the ad (like how you see random ads off to the side when you’re reading your emails in Gmail).  I could decide on options such as keywords, locations of the end users, and types of devices (computers and/or  mobile devices).

4. Google Analytics: I got Google Analytics set up for this website so I can track all sorts of useful information–such as how many people visit the website, how they get to the site (i.e. via search engines, by typing in the site’s URL, or via other websites), which pages people visit, how long they stay on various pages, etc.

5. Pingdom: I got Pingdom setup for this website.  Pingdom is basically a website monitoring service that sends out alerts when the sites it’s monitoring go down.  Being that a website is only useful if it is actually visible to the world, this was a no-brainer.  Very nice is the fact that they have a free edition of the tool.  I got it set up so that it texts me if moodyshoerepair.com goes down.  Pingdom has definitely saved my butt a few times.

6. Facebook:  Although I thought it was silly, I still went ahead and created a Facebook page for it.  I bugged some of my friends to see if they would become a “fan” of Moody Shoe Repair.  22 fans and counting.  Wonderful.

Well, this pretty much sums up everything I’ve done to maximize the site.  It’s been almost a year since the site has gone up and all I can say at this point is that the site is most definitely being underutilized.  I know it’s being underutilized because of the information that Google Analytics tells me.  I know it’s being underutilized because of the (low) number of questions I receive via the website’s contact form.  In order to better reap the benefits of the website, I know that I need to put up some more information that both potential & present customers would find useful–information that tells customers how much it actually costs to get various types of items repaired.

I’ve thought about implementing a customer-login section in the website whereby customers can login and check the statuses of their repairs and view their repair/order history.  However, I decided not to pursue it (at least for now) since I didn’t think that was going to be very helpful in generating new traffic to the website.

Also, I’ve thought about creating a blog for the business as well as a Twitter page.  Again, I decided not to because I question how many customers who frequent the store (or any shoe repair for that matter) would be the kinds of folks who check out blogs and tweet.  I may be wrong here and might be underestimating the tech-savviness of the customers.  I’ll need to do some more research on that.

If you’ve had similar experiences before with trying to cash in on the benefits of a business website, I’d love to hear from you.  Are there things you’ve implemented  that have helped you reap the benefits of your (or your client’s) website?

I have a few minutes to spare while my Ubuntu workspace is being patched up with some security updates so I thought I’d share a little blurp or two about RimuHosting which is the hosting service I’m using to host www.junhopark.com as well as www.moodyshoerepair.com (my parents’ shoe repair business located in Joliet, IL–go check ‘em out if you need shoe repair done!  I can almost guarantee you once you go get your shoes repaired, you’ll be thinking to yourself why did I not think of this before??).

Anyhow, sometime last year, I was looking all over the web (and I mean all over) for a hosting service that could handle Java web hosting.  I googled like crazy and it appeared that they were either too expensive and/or got horrible reviews.  I was discouraged.  And then somehow (I forget how…) I stumbled upon RimuHosting, which has definitely met my needs.  And since RimuHosting’s been good to me, I thought I’d share some highlights of their service in this post:

1) They offer a VPS (Virtual Private Server).  You can read a nice summary about it here on Wikipedia but what it basically boils down to is that on a single server, there are multiple “virtual servers” which runs its own operating system and and can runs independently from the other virtual servers.  It can even be rebooted independently.  End result: It’s sorta like having your own server but at a price that is actually affordable to an average joe like myself.  So… what all this means is that via RimuHosting, you can have yourself a virtual server and you can do what you want with it.  Read about all the things you can do with RimuHosting’s virtual private server here.

2) Their price:  I’m subscribed to their lowest-costing plan at $19.95/month, which I think is quite reasonable for the services I receive.  I get 160 MB of memory (puny, I know–but works for me) and 3.94 GB of disk space (note that your OS and related files will take up a pretty big chunk).  You can always pay them more money to get more memory.

3) Their support:  Those guys have been top-notch.  I haven’t had to use their support in awhile, but in the beginning when I was just getting started with them, I had to make use of their support on a number of occasions.  And those guys were lightning-fast with their responses.  Very impressive.  All support communications were done via web forms and/or emails but the response time was great each and every single time.

For Java hosting, I’ve read over and over again online that it’s a very bad idea to go with shared hosting and so the only obvious choice for me was to go with a VPS.  Simply being able to reboot the darn server has been such a huge plus for me as opposed to a shared hosting plan which I had been using for a number of years before RimuHosting.

Okay, Ubuntu has finished updating.  Now onto installing Chrome on this thing and enjoy faster browsing.

-Junho