Useware
This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. The reason given is: the article reads like a manual. (April 2024) |
Useware is a term introduced in 1998 to encompass all hardware and software components of a technical system designed for interactive use. It focuses on technological design in relation to human abilities and needs. A promising method[1] to design technical products is to understand human abilities and limitations and tailor the technology to them.
Today, useware necessitates its own development needs, which are sometimes greater than those in classical development fields.[2] Therefore, usability is increasingly recognized as a value-adding factor. Often, the useware of machines with similar or equal technical functions is the only characteristic that sets them apart.[3]
Useware engineering
[edit]Similar to software engineering, useware engineering implies the standardized production of useware by engineers and the associated processes (see Fig. 1). The aim of useware engineering is to develop interfaces that are easy to understand and efficient to use, tailored to human work tasks. Additionally, the interfaces represent machine functionality without overemphasizing it.
Therefore, the objective of systematic useware engineering guarantees high usability based on the actual tasks of the users. However, it requires an approach that comprises active and iterative participation of different groups of people.
The professional associations GfA (Gesellschaft für Arbeitswissenschaft), GI (Gesellschaft für Informatik), VDE-ITG (The Information Technology Society in VDE), and VDI/VDE GMA (The Society for Measurement and Automatic Control in the VDI/VDE) agreed in 1998 on defining useware as a new term. The term "useware" was intentionally selected in linguistic analogy to hardware and software.
Consequently, useware engineering developed in a similar way to the development of engineering processes (see Fig. 2). This reinforces the principal demand for structured development of user-centered user interfaces, as advocated by Ben Shneiderman.[4] After many years of function-oriented development, human abilities and needs are brought into focus. The only promising method to develop future technology products and systems is to understand the users’ abilities and limitations and to aim the technology in that direction.[1]
The useware development process involves the following steps: analysis, structural design, design, realization, and evaluation. These steps should not be considered in isolation but rather as overlapping stages. Maintaining continuity throughout the process and employing appropriate tools, such as those based on the Extensible Markup Language (XML), helps prevent information loss and breaks in media.
Analysis
[edit]Understanding that humans have varied learning, thinking, and working styles is crucial when creating a user interface. The first step is to analyze users, their tasks, and their work settings to figure out what they really need. This analysis is key to designing an interface that's focused on both the user and the task, treating humans and machines as partners in interaction. Techniques like structured interviews, observations, and card sorting help get a full picture of users and their behaviour, which is essential for grasping their tasks, user groups, and work environments fully. Engaging multiple experts such as engineers, computer scientists, and psychologists is crucial, particularly in the analysis phase, to generate task models for documentation and interface design, which inherently include a functional model of the process and/or machine.[5]
Structure design
[edit]The results of the analysis phase inform the structuring phase, where an abstract use model[6] is developed based on this information, which is platform-independent. This use model serves as the foundation for the future user interface, providing a formal representation of use contexts, tasks, and information required for the machine's functionality. Modeled using the Useware Markup Language (useML) within a model-based development environment, the use model defines the basic structure of the interface.[7]
Design
[edit]During the structuring phase, a hardware platform for the useware must be chosen in parallel. This selection considers both the environmental demands of machine usage, such as pollution, noise, and vibration, and the users' requirements, including display size and optimal interaction devices. Additionally, economic factors play a role. For extensively networked models or those comprising numerous elements, adequate display size is essential for visualizing information structures. These considerations are influenced by user groups and usage contexts.[8]
Realization/prototyping
[edit]During prototyping, developers need to choose a development tool. If the selected environment allows for imports, the developed use model can be brought in, facilitating the creation of the user interface. This typically involves refining dynamic components and dialogue design. Often, there's a disconnect between the structuring and fine design phases. The current array of development tools offers a broad range of notations. Developers must represent the useware through prototypes, such as paper prototypes or Microsoft PowerPoint prototypes.
Evaluation
[edit]Continuous evaluation throughout the development process enables the early detection of product issues, thereby reducing development costs.[9] It's crucial to assess not only design aspects but also structural elements like navigational concepts during evaluation. Research indicates that 60% of all usage errors stem from structural deficiencies rather than poor design. Consequently, the evaluation phase must be viewed as a cross-sectional task throughout the entire development process. Therefore, integrating users into product development is paramount.
References
[edit]- ^ a b Albach, Horst (2007). "Herz, Dietmar; Weinberger, Veronika (Hrsg.): Lexikon ökonomischer Werke. 650 wegweisende Schriften von der Antike bis ins 20. Jahrhundert". Journal of Business Economics. 77 (6): 697–698. doi:10.1007/s11573-007-0049-9. ISSN 0044-2372.
- ^ "Useware-Systeme für internationale Märkte". Useware-Engineering für technische Systeme. Berlin, Heidelberg: Springer Berlin Heidelberg. 2004. pp. 142–164. doi:10.1007/3-540-35034-9_4. ISBN 978-3-540-20647-7. Retrieved 2023-09-23.
- ^ Meixner, Gerrit (2011). "Mobile Interaktionstechniken in der Fabrik der Zukunft". Atp edition - Automatisierungstechnische Praxis. 53 (12): 48. doi:10.17560/atp.v53i12.359. ISSN 2364-3137.
- ^ Nielsen, Jakob (1987). "Book review: Designing the User Interface: Strategies for Effective Human-Computer Interaction by Ben Shneiderman (Addison-Wesley, 1987)". ACM SIGCHI Bulletin. 18 (3): 85–86. doi:10.1145/25281.1044310. ISSN 0736-6906.
- ^ Hofmeister, Wernfried (2007). "Mehrschichtiges Edieren als neue Chance für die Sprachwissenschaft". Edition und Sprachgeschichte. DE GRUYTER. pp. 73–88. doi:10.1515/9783110938869.73. ISBN 978-3-484-29526-1. Retrieved 2023-09-23.
- ^ Zuehlke, Detlef; Thiels, Nancy (2008). "Useware engineering: a methodology for the development of user-friendly interfaces". Library Hi Tech. 26 (1): 126–140. doi:10.1108/07378830810857852. ISSN 0737-8831.
- ^ Jung, Christian; Müsebeck, Franziska; Barisin, Tin; Schladitz, Katja; Redenbach, Claudia; Kiesche, Martin; Pahn, Matthias (2022). "Towards automatic crack segmentation in 3d concrete images". e-Journal of Nondestructive Testing. 27 (3). doi:10.58286/26620. ISSN 1435-4934.
- ^ Görlich, Daniel; Thiels, Nancy; Meixner, Gerrit (2008). "Personalized Use Models in Ambient Intelligence Environments". IFAC Proceedings Volumes. 41 (2): 13785–13790. doi:10.3182/20080706-5-kr-1001.02334. ISSN 1474-6670.
- ^ Bias, Randolph G. (2005). "The View from the Other Side of the Table". Cost-Justifying Usability (2nd ed.). Elsevier. pp. 613–621. doi:10.1016/b978-012095811-5/50022-5. ISBN 978-0-12-095811-5. Retrieved 2023-09-23.
Further reading
[edit]- Oberquelle, H. (2002): Useware Design and Evolution: Bridging Social Thinking and Software Construction. In: Y. Dittrich, C. Floyd, R. Klischewski (Hrsg.): Social Thinking–Software Practice, S. 391–408, Cambridge, London: MIT-Press
- For further information see the Useware-Forum 17 March 2009