What, then, constitutes a normative expectation within information technology? There cannot be any sort of authoritative list, since each user experience is different, but I will outline some common examples of expectations found in the literature on information technology values and software design, and why they are appropriate for inclusion such that explicit waiving of these norms should be required. I will also develop from the norms I outline some guidelines for choosing appropriate expectations in information technology situations. The way to identify more specific normative expectations for the particular user group of interest requires assessment of the situation the user is in, as well as the problem being solved for the user. At any point where user input is required, or where software or hardware companies might be making a decision for the user, or where it makes assumptions about the user, the question ``what expected norms might this violate?'' should be asked.
Ryker et al. (1997) performed a study of IT expectations, looking at where expectations come from, whether through academic means (schools and journals, for example), television commercials, word-of-mouth (friends outside of work), past experience, co-workers, or IT support staff and vendors. The study identified three dimensions of user satisfaction: the product information, where information about the product needs to be reliable, relevant, accurate, complete, and precise; provider staff and services, which requires a good relationship, co-operative attitude, good communication, and rapid response to problems; and the knowledge and involvement of the user, with participation in design and development, sufficient training and support, and a good understanding of the computer system. The overall conclusion was that the most common source of expectations in information technology situations came from the vendor or from IT staff [Ryker et al., 1997], placing a large responsibility on the vendor to not only meet but also to responsibly influence expectations.
In coming up with the following set of normative expectations, I analysed a number of standards and suggestions for codes of conduct for software engineers and vendors by interest groups such as the Electronic Frontier Foundation; vendors themselves, like Black Hill Software; professional organisations, including the IEEE Computing Society; and academics, drawing out some of the common suggestions and expectations across these documents, which are discussed below. I also drew on the analysis of the case studies of Chapters 2 and 3 in order to identify some further normative expectations that could be considered reasonable for software users. The analysis of the standards and codes consisted of identifying the expectations recommended by each document for software development, finding the common recommendations across the documents, and evaluating their suitability for inclusion as a normative expectation. This suitability analysis relied on the requirements of the Manson and O'Neill theory, relying on the general background context for information technology project developments, the sorts of people that could be involved as stakeholders, and the sorts of reasonable expectations that they could have about software. Because these standards were developed based on internal research and expert consultation across such a wide variety of interest groups, vendors, and academics, I decided to analyse the resulting standards and suggestions instead of conducting my own empirical research into computer user expectations. Some of these expectations may seem controversial, but they are not necessarily appropriate for every situation, and can only be used as guidelines for any particular project since they are based on a few narrow sets of industry guidelines and case studies. In the same way, there are severe limitations presented by this set of expectations in that they are definitely not applicable to any particular situation; here I simply wish to give examples of the sorts of expectations that could be possible rather than a generally applicable list.