Interface requirements

From WikiEducator
Jump to: navigation, search

This topic describes the requirements related to the editor's interface. The interface requirements include:

  • ease of use,
  • accessibility,
  • reskinning,
  • multi-language support, and
  • customisation.

Ease of Use

  • One of the most significant impediments to the adaptation of reusable content is the complexity of the tools and processes. Currently, there has been no viable trade-off between ease of use and reusability without becoming locked-in to a particular technology. A key objective of this project is to break that barrier and deliver simplicity in authoring, editing, maintenance, reuse and adaptation of content while still securing 'true interoperability' at both the individual file and aggregation levels of content. This is possible by engaging the power of structured content, however, the tools available to date have only been suitable for the more technically minded and require a technical understanding that should not be required of the average user. The requirement related to ease of use, intuitiveness and simplicity of the interface means that non-technical users will be able to author, edit and aggregate structured content. In the future, customisations of this application will extend this capability to an increasing range of communities of practice across all educational sectors for both 'teachers' and learners.


  • Support for accessibility is an important consideration. While it is recognised that this is not a trivial task and make take several iterative phases of development, it is important that better tools are available to users with disabilities so that they are able to develop content with similar outcomes concerning reuse and adaptation. The authoring and aggregation tool resulting from this work will be progressively more able to support accessibility due to the flexibility of the interface and inclusion of the principles of accessible design from the outset. The content produced by the application will conform to accessible content requirements as a routine method, however, this may also take several iterations to build simplicity and convenience into the process and functions. This objective will not only assist in areas of accessibility from the disability perspective but also in terms of accessibility for mobility and the delivery of content to alternative technologies rather than continuing the assumption of learning content being accessed via a Learning Management System using a computer.


  • The interface of this application should support simple reskinning of the 'look and feel' by any user (probably via user configurable style sheets). A set of interface parameters will be user configurable via simple selections. There is a significant interrelationship between this functionality and accessibility, however, there is also value in terms of simple organizational branding.

Multi-language support

The application should support multiple languages in the interface as well as in the content. This should be a standard localisation approach with language "plugins".


  • Particular organisations may choose to customise interface functionality to accommodate local process and practice, the central and/or federated infrastructure that is contextually relevant, or simply to add new and useful functionality for their own purposes. These types of interface changes are related to changes in functionality so they are not intended to be end-user configurable. These changes would be implemented by technical persons with the relevant software skills. It is also hoped that developments of this nature would be contributed back into the broader community where relevant and possible but this should not be mandatory.

Road Works.svg Work in progress, expect frequent changes. Help and feedback is welcome. See discussion page. Road Works.svg