Subscribe to
Posts
Comments
NSLog(); Header Image

Scorecard UI Problem

One of Scorecard 1.x's weaker points is nine-hole support. We're beefing this up tremendously with our 2.0 release, but are facing some crucial decisions when it comes to data entry and the user interface for such.

Below are two windows. The left is version 1.x, the right something I mocked up for version 2.0. Both windows appears as sheets (on Mac OS X, anyway) above Scorecard's main window.

Old VersionNew Version


In addition to beefing up support for the course's address (for Google Maps integration), we've had to add four more fields for the course rating and slope: two each for the front nine and the back nine.

For the purpose of this UI and anyone unfamiliar with golf who might have some input, the course rating and slope relate to the difficulty of the course. Both numbers are used when calculating someone's handicap index. The course rating is the sum of the ratings of the front and back nine, while the course slope is the average of the two ratings.

Ideally, we'd be able to drop the "Course" values and just do the necessary math, but the vast majority of people don't know their home course's front/back values. Most can get the values by talking to their head pro, but it's likely that only those who play only nine holes a fair percentage of the time will care to do so.

The problem stems from the fact that we only need two pieces of information. The equations are basically:

a + b = c
(x + y)/2 = z

The problems start to mount when the user enters "wrong" information - information that would result in, for example, a 1+1=3 situation. Do we put up a dialog box to alert the user? Automatically adjust one of the values (and if so, which?)? Do we dim (disable editing in) one of the text boxes? That hardly seems like the way to go - we'd be forcing a user to delete the contents of one text field just to edit another.

I suspect the vast majority of the people won't even enter the nine-hole rating/slope values1, but for those who do I want to make sure we get it right.

Additionally, people who play a nine-hole course, in this version, will have four text boxes that serve two purposes: the Course Rating and Slope will be the same as the Front Rating and Slope. What then?

If you'd like to mock something up, go ahead. If you have a comment, please post it below. I'm taking all suggestions at this point. Perhaps you'll solve some of the other things I don't really like2 in this layout.

P.S. Posting this is a part of my thought process. I'm not giving up at this point - I'm just starting. Forcing myself to write about the problems I'm having with something will undoubtedly help to make the solution clearer to someone - hopefully me. πŸ™‚

Footnotes

  1. For these users, we'll just divide the rating in half and use the same slope when calculating handicap indeces from nine-hole rounds. It won't be perfect, but it'll be close.
  2. I don't know if I like the "Holes:" radio buttons. I really don't dig the "tabs-inside-a-group-box" (the "Tees:" popup button controls the group box contents). And a few other things.

6 Responses to "Scorecard UI Problem"

  1. I think you should go with the "Footnotes 1" solution for all users.

    My opinion on nine-hole rounds are that they are a exception and being able to perform good at nine does not imply the stamina/quality lasts over eighteen. As a fact if you have a hcp < 11 the swedish hcp-system doesn't let you change the hcp over nine-hole rounds.

    So my conclusion is that if nine-hole rounds hcp is not perfect calculated for most golfers this will only be a neglectable percentage of the rounds. And for the "players" who only play nine-hole rounds - well the handicap is misleading from the beginning.

    1. Mats said on February 14, 2009:

      I think you should go with the "Footnotes 1" solution for all users.

      Potentially, but unlikely. Enough people asked for nine-hole scorekeeping that we don't want to do it half-assed. Also, the majority of our customers are in the U.S. (as you probably know) and so we have a handicapping method that includes those types of users.

  2. Your +/- buttons are wrong. You want a small square button ("gradient button" in IB3) and +/- art (steal from iChat) instead of text.

  3. Not directly a solution to your problem, but why not let users submit the correct data for their courses to a db hosted by you, then have a lookup button in the app?

    1. Jess said on February 16, 2009:

      Not directly a solution to your problem, but why not let users submit the correct data for their courses to a db hosted by you, then have a lookup button in the app?

      Because users often get things wrong and we don't want that to affect other users.

  4. I might be tempted to say, if both 9 hole slopes are null/blank, let the user enter one in without restriction. On the next entry, validate that it matches what you think it should be and error trap saying something like

    "The slope you've entered for this side is invalid based on the other side's slope. It should be X. If that is incorrect, please check the other side's slope and make sure it is right and that both the front and back slopes add up to the total slope for the course."

    A bit wordy. The wordsmith that you are can make that sound better though. πŸ™‚ Regardless, If they've entered a total slope and start to enter in splits for the 9 hole sides, I would definitely hold their feet to the fire. My guess is that you will only have a small percentage of people that use that functionality. It might be worth it to have a decent explanation in the help or notes.


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.