The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Searching Cache vs. Definitive List

An application I developed searches Active Directory. Unfortunately, it is deathly slow so every time a record is looked at I cache it in SQL server.

The search initially just looks at SQL server cache, but if the user can't find what he or she is searching for initially they can click on a link that says 'search all records' and search the whole definitive list of people in Active Directory (which takes up to 20 seconds sometimes).

The problem comes when I tried th hallway usability test on this.

After most people tried the first search (on the cache) and couldn't find what they were looking for they immediately gave up and didn't notice the little button that says 'search all people'.

Is there any way of making this obvious?
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 
Why not do it automatically? After not finding in cache immediately search the directory. (With a "working" indicator and a cancel button of course.)
sgf
Wednesday, June 01, 2005
 
 
Because it may well return results but not the ones the user is looking for.
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 
Then differentiate between the results (ie ones in the cache and ones not in the cache but pulled from AD).
Joe Send private email
Wednesday, June 01, 2005
 
 
populate the list with the cache hits first.
search the AD asynchronously, with a nice 'searching' animation (one of the few uses of animation that I find actually improves the user experience).

The downside: DOSing the AD server.

If AD server performanace is an issue, maybe looking at the AD infrastructure would be a better thing to address?  Bigger boxes, just more RAM, just more boxes, just fatter network pipes, what?  How can an AD query take 20 seconds or so???)
i like i
Wednesday, June 01, 2005
 
 
Unfortunately I can't DOS the AD server, and I need it to have as few hits as possible. Nothing I can do about the infrastructure.

This is more of a usability issue.
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 
A little more detail would help here...

What are they searching for?  Names?  Email addresses?

Why would the results from AD be "different" from the cache?

When you say "there might be results, but not the one's they are looking for" does that imply that the cached data gets out of sync with the AD data?

Any chance of just replicating the entire AD list of people to your database, say, every night while no one is using it?  You'd then have data that's no more than about 8 hours stale (assuming it's updated during business hours and re-synced after them).
Dave C
Wednesday, June 01, 2005
 
 
The data is resynced every time somebody looks at a record.

>What are they searching for?  Names?  Email addresses?

Names, addresses, job titles, etc.

>does that imply that the cached data gets out of sync with the AD data?

Yes. Caches get out of sync almost by definition. If you do a search for "software developer", some may appear, but the one you're looking for may not be in the cache.

>Any chance of just replicating the entire AD list of people to your database

Unfortunately not.
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 
How about two separate search buttons, one that is labelled 'Search (fast)' and another that is labelled 'Search (complete)'.  It isn't great as far as usability is concerned, but it is better than having a checkbox which the users are obviously ignoring.

Alternatively, search the cache first, then pop up a dialog asking the user if they want to search the AD.  That's annoying, but it would work.  Or search the cache first, populate your results, then automatically search the AD.  Someone else suggested this and I think you don't like it for infrastructure reasons.
Chris in Edmonton Send private email
Wednesday, June 01, 2005
 
 
Make the search faster. Maybe pull the data out of the server and index it with lucene and do searches on that instead.

Amazon and google made good because of a simple search idea, try to perserve that idea instead of making the difficult simple.
son of parnas
Wednesday, June 01, 2005
 
 
I'm not looking for technical solutions here.
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 
Here's my take.  =)

You can leave the option where it is now, it is convenient for those who "learned" the feature, i.e. your power users. Now for the casual users, you just need to "teach" the feature as soon as they need it. Assuming they will first leave it de-activated and do a cache only search returning few or no results, you can have a small info balloon or something (non-intrusive of course!) along the lines of "Too few results? The Exhaustive Search option takes longer but may deliver more results."---just so they don't give up as stated in your description.

An alternative would be a one-time-only message box with the same text and a "do you want to perform Exhaustive Search now?", but I don't really find the whole dialog box realm terribly user friendly, and so would argue against it.

My 2 cents.
mokka'logic Send private email
Wednesday, June 01, 2005
 
 
Actually, mokka makes a good point.  This may be a "learnability" vs. "usability" issue.  If its a web app, and the cache search returns no results, you could display a highlighted info box (not a popup) with your "Full Search (may take 1 minute or longer)" link.

Google does this (some items were omitted, blah, blah).
Dave C
Wednesday, June 01, 2005
 
 
Problem solved. I stuck it at the bottom, highlighted it in yellow and put a big border around it. Now it sticks out and people notice it.
Colm O'Connor Send private email
Wednesday, June 01, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz