1. MULTIMEDIA TECHNOLOGY AND APPLICATIONS CHAPTER 7. MULTIMEDIA SOFTWARE DEVELOPMENT TECHNOLOGY

2. 2 I NTRODUCTION Multimedia development is a project-based process. Well-developed plan for multimedia product will save time money multiple modifications The rule of thumb for development is 80% planning and 20% production. 80% planning + 20% production

3. S OFTWARE ENGINEERING DEFINED Software engineering is “multi-person construction of multi-version software” What is the relationship between the size of a program & the time it takes to develop it? Real world software projects involve teams of developers What’s the relationship between program size and the number of people involved? Is it linear (N developers == N time speedup)? Or is it exponential (N developers = N N speedup)? How does multimedia affect the life cycle?

4. A SOFTWARE PROCESS REQUIRES RESOURCES… What is the moral of the story (about project managers and resources)?

5. WATERFALL MODEL Cascades from one stage to the next only after previous stage is complete Gravity only allows the waterfall to go down; it’s very hard to swim upstream

6. R APID PROTOTYPING MODEL A prototype is a partially developed product that enables customers and developers to examine some aspect of a proposed system and decide if it is suitable for a finished product. Allow time for prototypes and improved versions Multimedia authoring tools facilitate prototyping

7. S PIRAL MODEL The spiral model is a software development process combining which elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.

8. O BJECT - ORIENTED MODEL The Object-Oriented paradigm assists the programmer to address the complexity of a problem domain by considering the problem not as a set of functions that can be performed but primarily as a set of related, interacting Objects. Such as: Text, Audio, Video, Graphic, Image Objects, Attributes, Operations Trends: Spiral model + Object- oriented developing

9. Quiz! What are drawbacks of Waterfall Model? Can prototypes alleviate these drawbacks? Why or why not? Why do many software development shops prefer spiral models? How does multimedia affect the process? Does this discussion motivate you avoid just hacking? Why or why not?

10. U SER INTERFACE System users often judge a system by its interface A poorly designed interface can cause a user to make catastrophic errors Poor user interface design is the reason why so many software systems are never used

11. U SER C ENTRED D ESIGN Software development should focus on the needs of users Understand your users Design software based on an understanding of the users’ tasks Ensure users are involved in decision making processes Design the user interface following guidelines for good usability Have users work with and give their feedback about prototypes, on-line help and draft user manuals

12. 9/5/2015 Lec ture 5 12 T HE IMPORTANCE OF FOCUSING ON USERS Reduced training and support costs Reduced time to learn the system Greater efficiency of use Reduced costs by only developing features that are needed Reduced costs associated with changing the system later Better prioritizing of work for iterative development Greater attractiveness of the system, so users will be more willing to buy and use it

13. U SABILITY VS. U TILITY Does the system provide the raw capabilities to allow the user to achieve their goal? This is utility Does the system allow the user to learn and to use the raw capabilities easily ? This is usability Both utility and usability are essential They must be measured in the context of particular types of users

14. A SPECTS OF USABILITY Usability can be divided into separate aspects: Learnability The speed with which a new user can become proficient with the system Efficiency of use How fast an expert user can do their work Error handling The extent to which it prevents the user from making errors, detects errors, and helps to correct errors Acceptability The extent to which users like the system

15. D IFFERENT LEARNING CURVES

16. U SABILITY P RINCIPLES Do not rely only on usability guidelines – always test with users Usability guidelines have exceptions; you can only be confident that a UI is good if you test it successfully with users Base UI designs on users’ tasks Perform use case analysis to structure the UI Ensure that the sequences of actions to achieve a task are as simple as possible Reduce the amount of reading and manipulation the user has to do Ensure the user does not have to navigate anywhere to do subsequent steps of a task

17. U SABILITY P RINCIPLES Ensure that the user always knows what he or she can and should do next Ensure that the user can see what commands are available and are not available Make the most important commands stand out Provide good feedback including effective error messages Inform users of the progress of operations and of their location as they navigate When something goes wrong explain the situation in adequate detail and help the user to resolve the problem

18. USABILITY PRINCIPLES Ensure that the user can always get out, go back or undo an action Ensure that all operations can be undone Ensure it is easy to navigate back to where the user came from Ensure that response time is adequate Users are very sensitive to slow response time They compare your system to others Keep response time less than a second for most operations Warn users of longer delays and inform them of progress

19. USABILITY PRINCIPLES Use understandable encoding techniques Choose encoding techniques with care Use labels to ensure all encoding techniques are fully understood by users Ensure that the UI’s appearance is uncluttered Avoid displaying too much information Organize the information effectively

20. USABILITY PRINCIPLES Consider the needs of different groups of users Accommodate people from different locales and people with disabilities Ensure that the system is usable by both beginners and experts Provide all necessary help Organize help well Integrate help with the application Ensure that the help is accurate

21. USABILITY PRINCIPLES Be consistent Use similar layouts and graphic designs throughout your application Follow look-and-feel standards Consider mimicking other applications

22. SOME ENCODING TECHNIQUES Text and fonts Icons Photographs Diagrams and abstract graphics Colors Grouping and bordering Spoken words Music Other sounds Animations and video Flashing

23. UI D ESIGN PRINCIPLES UI design must take into account the needs, experience and capabilities of system users Users should be involved in the UI design process and UI designs should be refined through prototyping There are cognitive factors, such as the size of short-term memory, which user interface designers must be aware of

24. UI D ESIGN PRINCIPLES ( CONTINUED ) An interface should be based on user-oriented terms and concepts rather than computer concepts For example, a book-keeping system in a hospital should use terms such as patient profile, case record etc. rather than directories, file identifiers, etc. The system should display an appropriate level of consistency Commands and menus should have the same format, command punctuation should be similar, and so on

25. UI D ESIGN PRINCIPLES ( CONTINUED ) The system should not surprise the user If a command is executed in a known way (in some familiar context), a user should be able to predict the operation of comparable commands. E.g., ‘delete’ and ‘remove’ are somewhat synonymous in the sense that they are both concerned with erasing something The system should provide some resilience to user errors and allow the user to recover from errors This might include an undo facilities, confirmation of destructive actions, 'soft' deletes, etc. Some user guidance should be provided Help systems, on-line manuals, etc.

26. I NFORMATION DISPLAY FACTORS Is user interested in precise information or data relationships? How quickly do information values change? Must a change be indicated immediately? Must user take some action in response to a change? Is there a direct manipulation interface? Is the information textual or numeric? Are relative values important?

27. D ATA VISUALIZATION Concerned with techniques for displaying large amounts of information Visualization can reveal relationships between entities and trends in the data Examples Weather information collected from a number of sources The state of a telephone network A model of a molecule displayed in 3 dimensions

28. C OLOR USE GUIDELINES Don't use too many colors Use color coding to support user tasks Allow users to control color coding Design for monochrome then add color Use color coding consistently Avoid color pairings which clash Use color change to show status change Be aware that color displays are usually lower resolution

29. U SER GUIDANCE A user guidance system is integrated with user interface to help users when they need information about the system or when they make mistakes User guidance covers: System messages, including error messages Documentation provided for users On-line help The help and message system may be integrated

30. E RROR MESSAGE DESIGN Error message design is critically important. Poor error messages can mean that a user rejects the whole system Messages should be polite, concise, consistent and constructive The background and experience of users should be the determining factors in message design

31. U SER DOCUMENTATION As well as on-line information, paper documentation should be supplied with a system Documentation should be designed for a range of users from inexperienced to experienced As well as manuals, other easy-to-use documentation such as a quick reference card may be provided

32. U SER I NTERFACE D ESIGN Easy to learn? Easy to use? Easy to understand?

33. T YPICAL D ESIGN E RRORS Lack of Consistency Too much memorization No guidance / help No context sensitivity Poor response Unfriendly

34. G OLDEN R ULES Place the user in Control Reduce the user’s memory load Make the interface consistent

35. © Some of the pictures and text are from internet online free resource and wikipedia