The second option I present makes a much more thorough attempt to inform the user before seeking consent. It starts with the standard basic agreement, which has the very basic necessities, and then moves on to a single window per expectation module (or, probably more likely, group of expectations, such as privacy-related expectations, given in the example window).
In Figure 4.7 we see a similar window to Figure 4.5, except that this time it is simply the basic agreement. The same basic competence test is set out (asking for date of birth and jurisdiction), and the language once more is simple to read and understand (once again it is important to note here that the text in the Figure is simply indicative of the sort of text required, and has been in no way tested for legal accuracy or viability). Accepting this window of the agreement would bring the user to the next step in the agreement.
The following step is where the bulk of the expectation waiving is done. Each expectation module, possibly encapsulating related expectations, shows a set of icons identifying the expectations, and a summary of effects of waiving those expectations. Below the summary, the full details of the effects is shown, with a checkbox for the user to agree to each section, and identification of how many steps there are left to proceed through. After agreeing to a module, the next module needed to be waived is presented, until all modules have been agreed to. In this way it is much easier for the user to see more information about the potential issues that might affect them. Finally, following the module acceptance, an extras window, as shown in Figure 4.6, would be presented, with the same potential benefits and drawbacks as discussed in the Two Step Agreement above. Only after accepting every step in the agreement would the installation of the software continue.
Ultimately these examples are just examples, but they should give a reasonable idea for how a practical application of this thesis to the problem of End User License Agreements would take place. As mentioned previously, the text would need to be written by someone with the knowledge of the jurisdiction law and accurate legal wording, but be as plain English as possible to facilitate the reading of it by people not legally trained. The user interfaces I have designed above are not perfect, but with the help of a trained user interface designer this should not be a difficult hurdle to overcome in a practical application to EULAs.
The multiple step example is better than the two step example in terms of informed consent, because it is less cluttered. This gives the user more useful information in easier to understand short statements, but is more likely to cause annoyance because of the number of windows requiring the attention of the user. However, as discussed before, the annoyance factor may be mitigated by the education of the users of the importance of giving informed consent for EULAs. The annoyance factor would also be tempered by the desire for the user to complete the installation of the software and use the software. Ultimately it would be beneficial to perform some trials to determine the limits of the annoyance factor as well as seeing how these models compare with the currently used models in terms of numbness and the differences in feelings of users about the quality of consent given and confidence in the developer or vendor of the software.
