[thelist] information architecture question (non technical)
Phil Turmel
pturmel-webdev at turmel.org
Tue Dec 12 14:17:52 CST 2006
Matt Warden wrote:
> thelist,
>
> This question does not require any specific technical knowledge to answer.
>
> Suppose you are trying to present summary level data about tasks.
> Here's a quick rundown of the characteristics of the tasks:
>
> 1) Each task is assigned to a single worker (and only workers -- not
> supervisors, etc.)
> 2) Each task has a task type
> 3) Each task has a number of days until it must be completed (I am
> calling this "criticality")
>
> The idea is to display a summary of tasks assigned to a worker, broken
> down by task type and criticality level (levels are "past due", "0-10
> days", "11-20 days", "20-30 days", "> 30 days").
>
> This is relatively easy.
>
> The problem is that there also needs to be a display of the same
> summary for portions of the organization. So, for example, a manager
> manages two units of three workers, each led by a supervisor. So:
>
> manager
> |____Unit 1 Supervisor
> |_____ Worker 1
> |_____ Worker 2
> |_____ Worker 3
> |____Unit 2 Supervisor
> |_____ Worker 4
> |_____ Worker 5
> |_____ Worker 6
> |____Unit 3 Supervisor
> |_____ Worker 7
> |_____ Worker 8
> |_____ Worker 9
>
> The summary for the manger should be the sum of all the summaries of
> the units below. The summary of each unit should be sum of the summary
> data for the workers in that unit. The number of levels could be
> anywhere from 1 to 6 or 7. All of the data does not need to be shown
> at the same time, but it is important to convey the data in a way that
> makes sense (i.e., it needs to be clear how Unit 3 Supervisor gets her
> total).
>
> I currently do have a solution, but I hate it....
Matt,
It seems to me that you should format the summary for each supervisor
the same way you format for a single worker, with counts for each type.
Then include links up one level, and links to subordinates, as needed.
I'm picturing something like this:
Heading for mgr/supervisor name & dept/unit name
+==========+==========+==========+==========+==========+
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
Link up one level
Link to subordinate #1
Link to subordinate #2
Link to subordinate #3
Link to subordinate #4
A worker display would be identical, but without subordinate links. And
it might list individual keywords for tasks instead of counts of tasks.
For a printable report, I would expand slightly, to something like this:
Heading for mgr/supervisor name & dept/unit name
+==========+==========+==========+==========+==========+
| Subtotal for Subordinate #1 |
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
| Subtotal for Subordinate #2 |
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
| Subtotal for Subordinate #3 |
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
| Subtotal for Subordinate #4 |
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
+==========+==========+==========+==========+==========+
| Total for dept/unit name |
| Past Due | Current | 10 - 19 | 20 - 29 | 30+ |
+==========+==========+==========+==========+==========+
| ## type | ## type | ## type | ## type | ## type |
| | ## type | ## type | ## type | ## type |
| | | ## type | ## type | |
| | | ## type | | |
+==========+==========+==========+==========+==========+
As for generating these values, the big DBs have big advantages: MSSQL
can do recursion with Common Table Expressions [1], and Oracle can
return hierarchies with the CONNECT BY clause[2]. There's a patch for
PostgeSQL to support the Oracle syntax[3]. Most everyone else is stuck
with multiple UNIONS of multiple INNER JOINs, or games with hashcode
columns and adjacency sets. Bleah!
[1] http://msdn2.microsoft.com/en-us/library/ms175972.aspx
[2]
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14200/queries003.htm#i2053935
[3] http://gppl.moonbone.ru/
HTH,
Phil
More information about the thelist
mailing list