Better way to implement a dynamic hierarchy

Question

Just a bit of a background, I write business apps and have never been concerned with user experience. If the application works then that's what is shipped. I have been starting to change my thinking as I had to use my software and found it unpleasant to use. There was nothing wrong with it, it made sense and it worked, but it was very tedious to use. That's what started me reading ux blogs and getting the brain thinking. There has to be a better way.

Now to the point of the question, I have a new project for a mining department that needs to budget work against a source location (where the dirt/coal is picked up from) and destination location (where it is dumped) and a material (various types of dirt and coal)

On a mine site there can be many locations, anywhere from 1000 to 30000 depending on the mine, but for the purposes of budgeting in any one month they could use say 20 to 50 locations. Destinations are far fewer in number anywhere from 10 to 100. Materials fewer again anywhere from 3 to 20 depending on the mine.

Now for any given combination of location, destination, material a budget/estimate needs to be stored. Basically the site plans to move 10,000 tones of coal from this location to that destination for the month of June 2012.

For the UI, I see that I need a treeview structure that contains the location, destination, material combination. Below is a rough mock of the tree structure. To the right of the tree I will have a list of start and end dates and quantities that will show when a material is selected in the tree.

Location30 
    Destination5
        Material2
        Material3
    Destination8
        Material2
        Material6
Location443
    Destination5
        Material1
        Material2
        Material3

Quantity view will look like (it will have its own new/edit/delete buttons) that get assigned to the selected material in the tree view.

Start date   End date       Qty
1/June/2012  30/June/2012   10000
1/July/2012  31/July/2012   12000

Normally my first thought would be to get the user to add each possible combination to the tree view one at a time using a add button to show a form that has the three fields with a save and cancel. Which is a really uncool way from a user point of view but very easy and quick to implement from a dev point of view.

But how do I let the user build the tree list from 30000 locations 50 destinations and 20 materials in a way that makes for good ux?

I have thought about adding 3 toggle areas beside the tree view one each for location, destination and material. When the location toggle one is clicked, a list of locations is displayed where the user can then drag multiple locations onto the tree at once. The same goes for destination and materials (destinations dragged onto locations and materials onto destinations. Now while that does seem to me a lot better than my original plan, it still doesn't feel like its the best way.

To make things a little more complicated I can see some users would like to work with material as the first node like material->location->destination instead of location->destination->material and possibly but less likely other combinations.

Does anyone have any better ideas, pointers or tips? or even a totally different idea that would make it awesome for the user? I will be using C# and WPF.

Answer 1

Perhaps you could use a more decoupled way of thinking. We have a similar solutions on our side solved with tags, e.g.

You could "tag" a location as coal mine and you also have tagged your materials like this. Every material used at a coal mine is also tagged as "coal mine". Than you can simple find all combinations by tag relations.

Other idea. If you think about how users will start filling up the database, than an upload/import tool could help a lot. Uploading a simple csv file with a predefined structure may help to get hundreds of locations into the database really quick. And most customers can simple export stuff like this from other tools. Because mostly they already have those structures somewhere.