RSS Feed

The Design of Software (CLOSED)

We have a couple spots in a product where we use the concept of "Priority" in places where a user can manipulate it.  In these applications, we need to be able to determine a single choice from among multiple options, and this priority concept is used to pick one.

My question is this: when people think of priority, do low numbers win or lose?  For instance, A's priority is 1 and B's is 99 -- which one wins?

FWIW, users in this context are business-oriented, but analytical.  Think power spreadsheet users rather than programmers.

Lower numerical value = higher priority. Priority 1 or 0 is the most high priority item. A lower numerical value wins.

A. Gorilla problably prefers big endian to little endian (like all rationally thinking people who have had to deal with bit-wise numbers have come to realize).

However, biz people like big numbers. Bigger is better, winning is better (even if the contest is "who gets to clean the pig trough today) with these guys, no matter what.

You introduce smaller is higher to them, and they will never get past that.  Huh??

Hmm.  Some people rate women's looks on a scale of 1 to 10, where 10 is best.  (I'm not that shallow, of course).  Some people rate things on a scale of 1 to 100, where 100 is best.

In Sports Analogies, "We're Number One!" is best -- the idea being competition has rated all the teams from number 1 -- the best -- down to the 'last team', the worst.

I'd reserve zero for 'no-value-assigned', myself, whatever else you decide.  The idea of zero being "highest value" does not appeal to me.

When rating options, research has found that 5 options is the best number to ask of people, where 5 is best and 1 is least.  "1==Strongly Disagree, disagree, neither agree nor disagree, agree, strongly agree".  That gives you 3 for a nice 'undecided' figure in the middle.  7 options adds these meaningless "disagree a little" or "agree a little" options that nobody can tell from 'agree' or 'disagree'.

Mathematically (and programatically) it makes sense to have the higher priority have the larger number.  Then you can use simple >= or <= comparisons to verify which is highest priority without further math or confusion.  1..255 is a nice range that fits in a byte.

Intel once had a real-time OS with priorities that fit in a byte, where 1 was the higest priority, 128 was a 'round-robin' priority (or 'default' priority), and greater than 128 was an "as you can get to it" priority.  I know this contradicts my earlier point, though.

You should make it your number one priority to explain this clearly to your users.

On the topic of rating women, over here in the UK, on the scale of 1 to 10, we would say "I'd give her one..." to signify our highest 'interest' level!

Priorities for tasks, 1 is highest priority; things you'll do first. I'd never go higher than 10 on this- my tasklist has items floating at 7 and 8 and they're practically in the "only if you hold a gun to my head and I'm really bored".

Higher number = higher priority is something that many folks could understand easily. Sure it conflicts with "this is your number 1 priority." Pick one system, use it scrupulously. How to pick it? Flip coins, or have the evangelists for each scheme armwrestle. Something like that.

Don't use numbers when interacting with the user. Be explicit. For example:
- real time
- high
- above normal
- normal
- below normal
- low

There's no one way. I agree with dino, use real words and use  as few of them as possible. Priorities can be tough to get right if a lot of them are used.

Shades of Windows CE, v 2.0...

I had a feeling I'd end up with mixed results - thanks for confirming my suspicion.  I like Dino's idea - I'll see if I can get people on that wagon.

Thanks again.

My own experience with "normal" users indicates that most folks can't really use more than three categories effectively. So my recommendation is:
  High Priority
  Normal Priority
  Low Priority
In no case should you present Priority=0, 1, 2, 99 or whatever to an end-user. There's very likely to be some confusion if you do.

-Mark

MS Project uses higher numbers on tasks to signify higer priority (if that helps at all)

I did just think tho, does it matter. Can't this be a user decision. Im guessing you can sort on the priority field, so if a user likes low numbers for their priority, they will use low numbers and sort as such. And vice versa for high number users.

but then, some will get confused, so named labels are probably wisest

If you want to sort on named labels, it might help to prefix with a numbered priority. 1-high, 2-medium, 3-low.

Wouldn't it depend on which end is more likely to be open ended?  That is, if you're more likely to come up with something later on that is more important than any entries in the system, then you should have higher numbers be higher priority, so that you can start at 0 or 1 and have plenty of room to "grow."  Alternately, if you're likely to come up with things less important that what's already in there, you should do it the other way.

My two cents.

> However, biz people like big numbers. Bigger is better, winning is better (even if the contest is "who gets to clean the pig trough today) with these guys, no matter what.
> You introduce smaller is higher to them, and they will never get past that.  Huh??

I guess that's why those "Quality is job 1" programs never seem to do any good then.

Although actually I think they should be called "Quality is job 0.999999"..

As far as the OP goes, I think you've already picked the right direction which is not to expose the numbers to the user.

Agree with other posters to use words rather than numbers. However, if you use High/Medium/Low you often end up with a disproportionate number of Highs an no-one wants their favourite requirement labelled Low. A bit of psychology helps: I have used Critical/Very High/High with success.

Great tip Marcus.

why not make the list of priorities configurable at each installation?  then the values are in a meaningful order for your customer

How about decimal numbers:
1.0 real time
0.8 high
0.5 normal
0.3 low
0.0 idle

This fulfills both requirements: priority 1 is highest and bigger numbers mean higher priority.

The correct list of choices is this:

High priority:  Venti
Medium priority: Grande
Low priority:    Tall

In the world of embedded development & real-time operating systems, lower numbers are always higher priority (i.e. a priority 1 task pre-empts a priority 2 task).  If your customers are realtime RTOS savvy, that's what they'll expect.  If your customers are more business-oriented, I don't know what they like to see.

As you can tell -- because you asked :-) -- nobody is going to interpret this the same way.

My gut says if you want to use 1-5 (i.e., only a few numbers), call the priorities "1st", "2nd", etc. -- that sounds clearer to me.

The suggestion to use names is a good one.  I'd go so far as to use names *and* numbers.  (People are good at picking a number out of a list.)  Like this:

1 - Highest
2 - High
3 - Medium
4 - Low
5 - Lowest

If you simple used 1,2,3,4,5, there would always be confusion.  The goal is to eliminate any possible ambiguity.