Sep 28
In the fun application that I have been talking about, we keep running into issues like the slow tree. They all come down to one thing. Noone thought about success, and how it would handle size.
When you are running on a dev machine and have 3 test users, it may make sense to have one “Users” tab that has on it:
- list all users
- list all special users
- add user form at the bottom
However, when you get popular and have a million registered users or so, this page becomes REAL slow, and what if you just wanted to add a damn user!!!
Obviously, we went in on the new system and have ‘add user’ as a separate action, and instead of listing all of the users admins go in and search for what they need.
September 28th, 2006 at 11:43 am
I’ve noticed more and more that the typical dev cycle now involves creating the simple interface first, using it and then refactoring as time passes, and I’m just fine with that. As you pointed out, during the testing and initial rollout a user list (paginated of course) *is* the easiest interface to understand, and in most cases it is also the easiest to implement. As the list grows refactoring is critical to adapt to the (hopefully) growing user base.
Anyhow, being a skilled refactorer is going to be increasingly important (as if it isn’t already extremely important already), and having languages which are terse and easy to refactor are is also going to be more and more important. And this is not refactoring at the method level I’m talking about, but refactoring at the functional level.
September 28th, 2006 at 12:04 pm
How about add paging to your list users screen?
September 28th, 2006 at 8:20 pm
If you want to provide a generic solution, set a threshold (say 500 instances). Below that the system uses client side paging, beyond it calls a SP which handles the paging. That is the way I generate apps. In that way a client has control over the threshold on an object by object basis and I don’t nee to write custom code when a collection starts to grow!
Best Wishes,
Peter