This talk describes the ideas behind the TASAD project: "Temporal and situated aspects of data", but also will suggest a perspective on why this kind of project may be important in HCI. Thew project comes from asking what would be the best computational support we could offer people for managing accounts on a fairly small scale (personal bank accounts, research grant accounts, small businesses). Most such accounts are in fact managed using spreadsheets, but analysing what is really wanted and what spreadsheets standardly provide reveals a gap.
Some of this gap is because many users never quite notice what they are really trying to do with the spreadsheets. For instance, in almost all cases, people look at accounts (on spreadsheets) in order to compare what has happened with what was planned, in order to detect the need for corrective action if any. This means the fundamental user operation is comparison between two sets of numbers (planned and actual, income and committed expenditure). However many users do not design their spreadsheets to present this comparison (e.g. figures side by side, differences calculated), but instead spend their time turning sheets of printout.
Secondly, the subset of users who did clearly identify the real task then all have to re-implement solutions for it: it is not provided as standard by software producers. Clearly it would be better to design standard facilities right and provide them once.
Thirdly, some of the issues in fact require advances to be made in the underlying data modelling. For instance most accounts are functions of time: salaries are paid regularly, and often are incremented according to a known function. Currently everyone calculates this by hand: instead we should have functions of time as a built in facility. Other features needed in this domain include: fisheye presentation functions to control the presentation of detail, standard graphs of time functions (not the requirement in spreadsheets to select values for dozens of parameters to get a graph), granularity calculations to set the number format intelligently, not manually reset by the user for every cell, a tree drawing procedure to display the dependency tree (of how money totals depend upon subtotals, depending on monthly totals, etc.), built in logging to record when entries were made as well as when they refer to, data modelling of the issues of representing data acquisition failures (data missing or faulty), reco
A lot of quite mature computer science still fails to be used in practice. The gap is due to a kind of usability: it still requires programmers for every application, and only very big applications justify that. Another factor is, that users are often not fully aware of what they need, or rather of what the best practice in the domain (e.g. accountancy) actually is. Thus they are not even asking for the service which in fact they would benefit from. (Market driven seems to mean driven by ignorance in this case.) An important way forward may be to analyse domains with a large population of users, each of them economically "small"; to design and build solutions for these domains; but also to invest effort in communicating the existence and nature of these solutions: in effect addressing the need to educate users about the domain of work, and not just technical and interface aspects of software.