OpenLLM-France/wikimedia huggingface dataset:
# Sport Innovation/Goal-line Technology/Football, Technology and the future

The technology in football debate has been raging for quite some time now. Disallowed goals and allowed non-goals are the key factor in the debate for the introduction of goal-line technology into football. The fact that FIFA are testing nine different goal-line technologies and have discussed its possible inclusion in the 2012–13 English Premier League proves to be positive [1]. However, there is also concern for other factors such as unseen handballs and offside players [2]. The have been recent cases of both such issues which have both resulted in goals [2] [3].
Although it may take a significant amount of time, eventually football will have technology the can determine if a goal was really a goal or if it wasn’t and if players are offside [4]. Both technologies able to determine the afore mentioned are able to do so instantaneously [1]. However, technology used to establish if a player handballed is not instant [5]. Due to the fact the technology is not instant, the technology is not likely to be implemented, as it does not meet the strict testing criteria developed by FIFA.
Ultimately, the decision is up to the International Football Association Board (IFAB), who establishes the football rules and is the only one that can change them [6]. However, it is clear that the introduction of technology in football has the potential to reduce human error and to make goal-line controversies, such as Frank Lampard’s disallowed goal at the 2010 FIFA World Cup in South Africa, a thing of the past [7].

## References

[1] Conway, R. (2011, November 24). Premier League could use goal-line technology in 2012–13 season. Retrieved November 29, 2011, from http://news.bbc.co.uk/sport2/hi/football/15866363.stm
[2] World Cup 2010: Luis Fabiano admits 'handball goal' against Ivory Coast. (2010, June 21). The Guardian. Retrieved November 30, 2011, from http://www.guardian.co.uk/football/2010/jun/21/luis-fabiano-brazil-world-cup
[3] Ankers, G. (2011, August 5). Arsenal's Robin van Persie backs technology for goalline and offside decisions. Retrieved November 30, 2011, from http://www.goal.com/en/news/9/england/2011/08/05/2606085/arsenals-robin-van-persie-backs-technology-for-goalline-and
[4] McKeegan, N. (2007, December 13). The Adidas intelligent football. Retrieved November 29, 2011, from http://www.gizmag.com/adidas-intelligent-football/8512/
[5] Hytner, D. (2009, November 20). Furious Irish demand World Cup replay after controversial handball. The Guardian. Retrieved November 30, 2011, from http://www.guardian.co.uk/football/2009/nov/19/republic-of-ireland-france-world-cup
[6] Fifa may implement video replay technology, says Sepp Blatter. (2010, January 24). The Guardian. Retrieved November 30, 2011, from http://www.guardian.co.uk/football/2010/jan/24/video-replay-technology-sepp-blatter
[7] Goal-line Technology – Getting it right. (2010). Retrieved November 29, 2011, from http://www.wipo.int/wipo_magazine/en/2010/04/article_0001.html
# Sport Innovation/Goal-line Technology/FIFA Testing Criteria for Goal-line technologies

FIFA have released the criteria they have developed in order to determine each of the nine technologies accuracy, reliability and instantaneousness [1]. The nine technologies will be evaluated using a pass or fail assessment system with 100% accuracy required. The four criteria include:
* The technology applies solely to the goal-line and only to determine whether a goal has been scored
* The system must be accurate
* The indication of whether a goal has been scored must be immediate and automatically confirmed within one second
* The indication of whether a goal has been scored will only be communicated to the match officials (via the referee's watch, by vibration and visual signal) [2]
During phase one all of the technologies will be tested with varying levels of lighting, speed of the ball, different angles of trajectory[3]. Not only with the technology be tested with regards to the ball going through the goal posts but the ball will also be tested to determine if players will have the same control of the ball embedded with the technology as one without [1].
Phase two of the testing will be more intensive and will take in various elements such as climatic conditions and receptiveness of referees' watches, which would receive the verdicts from the technology [1].
The findings from the testing will be presented by Empa to the International Football Association Board (IFAB). Those who meet the criteria will be voted on by the board which is comprised of the Football Association (FA), the Irish FA, the Welsh FA, the Scottish FA and FIFA. Each of the FA’s have one vote while FIFA who will act on behalf of the rest of the world, has four votes. The decision to implement one of the GLTs must be approved by three-quarters of the IFAB member [4].

## References

[[1] Conway, R. (2011, November 24). Premier League could use goal-line technology in 2012–13 season. Retrieved November 29, 2011, from http://news.bbc.co.uk/sport2/hi/football/15866363.stm
[2] Nine systems to be tested in goal-line technology trials. (n.d.). Retrieved November 28, 2011, from http://www.soccerex.com/industry-news/nine-systems-to-be-tested-in-goal-line-technology-trials/
[3] FIFA to run tests on nine goal-line technology systems this autumn. (2011, 21 July). Retrieved November 29, 2011, from http://www.guardian.co.uk/football/2011/jul/21/fifa-goal-line-technology?INTCMP=SRCH
[4] Jackson, J. (2011, 24 November). Goal-line technology to be in place for 2012–13 Premier League season. The Guardian. Retrieved November 28, 2011, from http://www.guardian.co.uk/football/2011/nov/24/goalline-technology-fifa-ifab-rochdale?INTCMP=SRCH
# Usability for Nerds/Self-explaining interfaces

Self-explaining user interfaces are preferred if they can be implemented without too much complication. A drop-down menu is a good example of a self-explaining interface.
A bad example is a desktop shortcut in Microsoft Windows 7. This square, which just looks like an empty space, is actually a shortcut that you can click on to view the desktop. It is not obvious that this little square actually has a function - or what that function might be. A user looking for a shortcut to the desktop is very unlikely to find it.
An icon or pictogram is intended to be self-explaining, and it works well if it is easy to understand or the meaning is generally known.
But an icon or pictogram is useless if incomprehensible or easily misunderstood. This pictogram means Remember, but it may be misinterpreted to mean Emergency room.
This icon, named Control Center 3, opens the software for controlling a scanner. This is not obvious to the user.
While a self-explaining button or icon can be useful, it should not be so conspicuous as to be disturbing or importunate.
← The user should be in control · Predictability →
# Usability for Nerds/Software

* Interaction schemes
* Help
* Error Messages
* Response Time
* Keyboard Shortcuts
* Mouse Effects
* Scrolling
* Default values
* File Organization
* Internationalization
* Installation and Uninstallation
* Copy Protection
# Usability for Nerds/Predictability

Imagine that you are writing a complicated text. Your screen looks like this:
Now you want to write something more. What happens when you start writing, let's say by pressing the A key? The highlighted text is deleted and replaced with the new text! I am sure all beginners have made this mistake. A novice user would certainly expect the A key to write an A, not to delete text. Even the most experienced users sometimes make this mistake when they are not looking at the screen and have forgotten that there was something highlighted. The problem here is that the behavior of the A key is not always the same. If there is no highlighted text then it just writes an A. If there is highlighted text then it deletes the text and replaces it with an A. You cannot expect the user to look at the screen all the time, so everybody can make mistakes when the same key doesn't always do the same thing.
Of course, there is an idea behind the principle that you can make corrections by highlighting the unwanted text and then just writing something else. But it only saves you one keystroke, the Delete key. And the consequence is that you may inadvertently lose a big piece of text that you have problems recalling. (There may be an undo function which can restore the deleted text, but if you don't discover the mistake immediately, it may be too late).

## Avoid modes!

There is a similar problem with the CapsLock key. A letter key produces a capital letter when the CapsLock is on, and a small letter when the CapsLock is off. Technically speaking, the keyboard can be in two different modes: CapsLock on mode and CapsLock off mode. The meaning of the keys depend on the mode. Older systems may also use NumLock, ScrollLock, and Insert keys to produce different modes, but the use of these is avoided in most modern systems because modes always cause usability problems. The CapsLock key still lives because there is no good alternative. When modes are unavoidable then the mode should be displayed in a very conspicuous way on both keyboard and screen, for example by giving the cursor a different shape or color.
← Self-explaining interfaces · Transparency →
# Usability for Nerds/Provide alternative ways out of a situation

If you have read the page The user should be in control, then you are probably already convinced that there should be more than one way out of any situation. The list below gives typical examples of options that a user might want to have in a critical situation:
* Proceed to next step
* Return to previous step
* Undo last operation
* Undo more than one operation
* Redo undone operation
* Cancel operation
* Save data and interrupt operation so that I can resume later
* Help about this step
* Help about program in general
* Leave program
An operation that cannot be undone may be preceded by a warning such as "Are you sure you want to delete this?". However, such warnings should be used as little as possible, because users tend to ignore warnings if they come too often.
← The design of a button should reflect its importance · Surveys, Questionnaires, Forms and Option lists →
# Usability for Nerds/Preface

Bigger companies that produce gadgets, appliances, software or other technical equipment often have a division of labor where engineers and programmers develop the technical functionality of the product while designers or marketing people design the user interface. These two groups of people often have difficulties understanding each other because they have very different ways of thinking. Often, smaller companies and open source developers have no access to expertise in user interface design at all.
This Wikibook is intended for engineers, technicians, programmers and others who construct and develop technical things and who want their products to be user-friendly. This should be useful for the following reasons:
* Usability is important for most technical products, both hardware and software.
* Technical developers need to take usability into account if no external expertise in this topic is available.
* Technical developers need to understand the fundamental principles of usability in order to cooperate with designers about the design of user interfaces.
* It is good to think usability into the design at an early stage rather than making adjustments later.
* Usability often involves very technical details that designers know nothing about, e.g. how to make a dialog box with standardized behavior.
This book is based on a course in man/machine interface that I taught at the Technical University of Denmark in 2000, with later additions and updates. I have published it here as a Wikibook so that others can make additions, corrections and updates. Agner Fog.
What is usability? →
# Usability for Nerds/Recommended literature
## McCormick, Ernest: Human factor in engineering and design. McGraw-Hill 1976.

    Theoretical textbook about input/output devices, ergonomics, cognition, psychology.

## Newman, W M & Lamming, M G. Interactive System Design. Addison-Wesley 1995.

    Textbook with the main focus on user psychology and cognition, including user study, modeling user activity, and systems analysis.

## Hoa Loranger and Jakob Nielsen: Prioritizing Web Usability. New Riders 2006.

    Handbook for web designers.

## Nielsen, Jakob. Usability Engineering. Morgan Kaufmann Publishers 1993.

    Good textbook with the main focus on computer interfaces. Practically oriented and easy to read, though I would like to have more examples and illustrations.

## Norman, Donald A. The Design of Everyday Things. Doubleday 1988.

    Entertaining book packed with examples of good and bad designs. This book can convince anybody about the importance of user-friendly designs.

## Yvonne Rogers, Helen Sharp, and Jenny Preece: Interaction Design. Beyond Human - Computer Interaction. Wiley 2011.

    University-level textbook. Theoretical but easy to understand.

## Dix, Alan, et. al. Human-Computer interaction. Pearson Education 2003.

    Textbook with a mostly technical focus.

## Raskin, Jef. The Humane Interface. New Directions for Designing Interactive Systems. Addison-Wesley 2000.

    Theoretical book on human/computer interface and cognitive psychology with detailed discussion of commands, displays, cursors, icons, menus, etc.

## Shneiderman, Ben, and Plaisant, Catherine. Designing the User Interface. Strategies for Effective Human-Computer Interaction. Fourth ed. Addison Wesley 2004.

    Comprehensive university-level textbook on the design of human/computer interface.

## Pearrow, Mark. Web site usability handbook. Charles River Media 2000.

    Handbook for web designers.

## Badre, Alberg N. Shaping Web Usability: Interaction design in context. Addison Wesley 2002.

    Web design with focus on the social and cultural context.
This list is not completely up to date. You may search for newer literature.
Recommended web sites →
# Usability for Nerds/Open standards

All technical products that have connections with other products need a standardized interface. For example:
* A water faucet must fit into a standardized threading or fitting.
* A television needs standard plugs, standardized signal levels and standardized data formats.
* A text processor needs to store text files in a standardized format which can be read by other text processors.
* A printer needs standardized plugs, standard paper sizes, standardized commands and text encoding, and preferably a standardized ink or toner cartridge.
* Anything connected to a computer network needs standardized plugs and protocols.
* Any piece of software needs to fit a standardized operating system.
There are different kinds of standards and different levels of standardization:
Secret factory standard. The product is intended to be compatible only with other products from the same company. Competing companies need to hack or reverse-engineer these products in order to make something compatible. An example is the old format for Microsoft Word documents.
Proprietary standard. The standard is owned by a company and protected by patents or copyright restrictions. Other companies must pay a license fee for making compatible products. Example: the Postscript printer file format.
De facto standard. A de facto standard develops when various companies tend to make their products compatible with existing products from other companies. There is no official agreement, but neither is there any attempt to protect the schemes by secrets, patents or copyrights. Example: Hewlett-Packard Printer Control Language for laser printers.
Official standard. The standard is endorsed and maintained by an official organization. All technical details are specified exactly and published. Example: the HTTP protocol and the HTML language for the World Wide Web.
Open source. A software product is developed by volunteers and the software as well as the complete source code is made public without severe copyright restrictions. Anybody can improve or modify the product and anybody can make compatible products. Example: The Linux operating system.
Users need compatibility. Secret and proprietary standards are shunned by consumers because it makes them dependent on only one or a few producers, and they risk that development and maintenance of the products be discontinued.
An advantage of the open source principle is that errors and problems can always be fixed, while producers of proprietary software sometimes cover up their bugs or tell the users to just update to the next version (which has other bugs). The disadvantage of open source is that there is no economic incentive to improve the product and its usability.
← Standardization · Convincing decision makers →
# Usability for Nerds/Software/Copy Protection

Producers of commercial software have a very reasonable wish to protect their product against unauthorized copying. Many different methods have been invented, but unfortunately all these methods have usability problems as well as problems of distinguishing between legitimate and unauthorized copying. Some methods are listed below:
Original disk is tampered with. A compact disc supplied as part of the software product is tampered with in a way that is not easily copied, e.g. a specific part of the data layer is removed. Problems:
* The user has to insert the disk every time the product is used.
* The user cannot make a legitimate backup copy.
* This method requires direct hardware access or a special driver that may be incompatible with future hardware or operating systems.
* Does not work in network systems, unless one dedicated machine has a special driver or other software which would allow remote identification via network.
Hidden information is stored on the computer. Problems:
* This information may be lost when the user updates hardware or operating system.
* The user may have more than one computer.
* May be incompatible with future operating systems.
A fingerprint of the computer hardware is stored. Problems:
* Lost when the hardware is updated or repaired.
* The user may have more than one computer.
* May be incompatible with future operating systems.
A dongle. A dongle is a little piece of hardware that has to be connected to the computer. Problems:
* Requires direct hardware access or a special driver that may be incompatible with future hardware or operating systems.
* Must be moved all the time if the user has more than one computer.
* The dongle may be stolen, misplaced or damaged.
* Difficult to protect against theft.
* May be incompatible with other dongles or other hardware.
* The number of dongles that can be attached to a computer is limited.
* May not work in network systems.
Printed manual. A manual is more difficult to copy than software. Problems:
Registration. The users fear that they may receive spam mail.
Serial number. The user has to enter a serial number when the program is installed.
Hotline. Only legitimate users have access to support and service from a hotline.
License server. A serial number or other key to access is stored on a central server. Problems:
* Only useful for organizations with many users.
* Depends on reliable network access.
Free updates. Legitimate users get free updates and bug fixes.
Most copy protection schemes contain combinations of these methods. However, most software producers are now using a serial number only or refraining from using any copy protection at all because of the severe usability problems and technical problems they entail. Shareware and freeware products are gaining popularity for similar reasons.
← Installation and Uninstallation
# Usability for Nerds/Recommended web sites

Special Interest Group on Computer Human Interaction.
    This organization has chapters in many countries. Their website has an extensive bibliography and many links to various resources.
Web Content Accessibility guidelines.
    Technical recommendations for handicap-friendly web design from the official World Wide Web consortium.
Usability.net.
    Lists of organizations and other resources.
Jacob Nielsen
    Home page of a web design guru.
www.baddesigns.com.
    Learn from others' mistakes - and get a good laugh! A wonderful collection of simple things that are difficult to use.
Interface Hall of shame.
    Examples of bad designs of software interfaces.
← Recommended literature
# Web Application Security Guide/Intro

This guide attempts to provide a comprehensive overview of web application security. Common web application security issues and methods how to prevent them are explained. Web server and operating system security are not covered. The guide is intended mainly for web application developers, but can also provide useful information for web application reviewers.
The checklist gives a short summary containing only the individual guidelines. It is recommended to take the time and read the full version, where the guidelines are explained in detail, especially if any questions arise.
Most web application developers probably (hopefully) already know some or even most of the points mentioned in this guide. However, there will probably be something new for every developer. Remember, as a developer it is your responsibility to develop your application securely, and a single mistake may be enough to allow an attack.
# Web Application Security Guide/Further reading

A similar guide can be found at https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines.
OWASP provides good information about many web application security issues, with a large list of vulnerabilities to learn about and avoid.
# File inclusion and disclosure

If the names of files that are to be included or sent in response to a request are coming from user input (e.g. in menu systems or download scripts), attackers may be able to request files that they are not supposed to. If user-supplied names are used for inclusions, this can even lead to code execution on the server.

## To prevent this type of attack

* Do not take file names for inclusions from user input, only from trusted lists or constants.
** If user input is to be used, validate it against a whitelist. Checking if the file exists or if the input matches a certain format is not sufficient.
* Avoid having scripts read and pass through files if possible.
* If you read and deliver files using user-supplied file names, thoroughly validate the file names to avoid directory traversal and similar attacks and ensure the user is allowed to read the file.
* Ensure the application runs with no more privileges than required.

## Rationale

If the attacker is able to upload a script file and get a part of the application to include it, he can execute arbitrary code. As this poses an extremely great risk, it has to be carefully avoided. Thus, only the strictest kind of verification (checking against a whitelist) is appropriate for this task. If files are to be offered for download, simply putting them in a directory and letting the web server handle the rest is often the best choice: Not only is it faster than having a script read the file; it also avoids risky interpretation of user-supplied file names. In some cases, this is unavoidable, e.g. if a script is needed to enforce that only logged-in users can download files or to set special headers (see next section).
In that case, make sure you correctly perform the access checks that make the script-based approach necessary and that you thoroughly validate the file names to stop the attacker from downloading files he is not supposed to download. You especially need to make sure that the attacker cannot specify other files than intended, especially not outside of the intended directory, e.g. by using the “..” pseudo-directory name. (Note that a “../” can be encoded in many ways!)
Running the application with limited privileges (usually done by limiting the privileges of the web server or script interpreter) limits the impact of such (and other) issues.