Textual Bloopers

1. By Benjamin Lopez Ruby Obando Textual Bloopers

2. Introduction • What makes an interface good or bad? Text! • A picture is worth a 1000 words (a little text might be better) • This are cheap problems and easy to correct • Problems originated in the development process

3. Unprofessional writing • Inconsistent Terminology • Unclear Terminology • Speaking Geek

4. Inconsistent Terminology • One of the most common mistakes • Programmer attitude (have better things to worry about) • Different terms for the same concept • Same term for the same concept

5. Inconsistent Terminology • Different terms for the same concept • Examples • Lack of agreement or communication between programmers • Different words in different context describe same thing

6. Inconsistent Terminology • Same term for the same concept • Sloppy terminology is less acceptable in software than it is in common chatting • Example: Pointer Cursor

7. Inconsistent Terminology • Design Rule: • Use radically consistent terminology. • Conceptual model • What concepts will be exposed to the user and what each concept will be called • Use message files

8. Unprofessional writing • Inconsistent Terms • Unclear Terms • Speaking Geek

9. Unclear Terminology • Terms could be consistent but they are still unclear in the sense that users can easily misinterpret them. Terms for different concepts are too similar Concepts are too similar Ambiguous terms

10. Unclear Terminology • Terms for different concepts are too similar Example: • Personal planner & personal Journal • User were confused • Makes the user to randomly select between them

11. Unclear Terminology • Concepts are too similar • Example: Find home by Location or by Map • Same concept: both are by location; they differ on how the location is specified • Example: • Recomendation: mergin some or all the concepts

12. Unclear Terminology • Ambiguous terms • Textual ambiguity can be further exacerbated when verbs are used as nouns.Example: • Example:

13. Unclear Terminology • Design Rule • Avoid similar terms • Avoid concepts that could get mix up • Test the lexicon on users

14. Unprofessional writing • Inconsistent Terminology • Unclear Terminology • Speaking Geek

15. Speaking Geek • Terminology is consistent, there is no misinterpretation…. but incomprehensible • Using programmers jargon • Turning common words into programmer jargon • Turning verbs into nouns. • Exposing terms from the code • Assigning arbitrary meaning to short, non descriptive terms.

16. Speaking Geek • Using programmers jargon • Why do programmers use jargon? • Lack of awareness – they just don’t realize • Inability to switch jargon off • Think that people that are going to use computers have to learn • Lack of time to think how to say it in other way • Because they expose technical concepts

17. Speaking Geek • Turning common words programmer jargon • Examples • UNIX: cat & man • Dialog = conversation = short for dialog box • Others: • string, object & client

18. Speaking Geek • Turning verbs into nouns. • Example: • The compile failed • Do a compare • Others • finish and edit

19. Speaking Geek • Exposing terms from the code • Examples Login Fail. Please re-enter your login information and try again Error Message : PWExecption when invoking constructor ‘Session(String name, String pword, String server, String url)’

20. Speaking Geek • Assigning arbitrary meaning to short, non descriptive terms. • In the past this help to minimizethe amount of typing the user had to do but it maximized the amount of learning • Point and click GUI removethe motivation for shortsingle word names

21. Speaking Geek • Design Rule • Know thy users • Learn about the intender users • Pay attention how they talk • Leave GUI components names out of the GUI • Use Create not new

22. Inconsistent Writing • Careless Writing • Unfriendly messages and labels • Misleading Windows

23. Careless Writing • Inconsistent writing style • Poor grammar, spelling, and punctuation • Misleading Text • Enter Id, Ok?

24. Inconsistent writing style Applications: • in text of built-in instructions • command names • setting labels • windows titles Most Common: • Naming some commands after actions (verbs) but others after objects (nouns) Example: “Show Details” Vs. “Properties”

25. Inconsistent writing style • Using terse, “telegraphic” language e.g. “Enter send Date: ” • Using the title capitalization for some headings but sentence capitalization (e.g. Database security) • Ending some but not all sentences with periods e.g. , in instruction or error messages

26. Inconsistent writing style PG software

27. Poor, grammar, spelling, and punctuation Many GUI-based application suffer from: • Poor spelling • Writing

28. Misleading Text Common places: labels headings, descriptions Instructions Recommended Patches: Faults: He pointed out that this may suggest to some customers that the other patches had not been tested.

29. Enter Id, Ok? • Enter Id, Ok? • Abbreviations should be in capital letters. • “Id” should be “ID” • “Ok” should be “OK” “ID” vs. “Id” “ID”: identification “id” is”the source of instinctual impulses.”

30. Avoiding Careless Writing Design Rule: • Use writers • Spell-Check all text • Think outside-in • ID,OK?

31. Unfriendly messages and labels • Clueless error messages • Misuse (or nouns) of “…” on command labels • Inconsistent use of colon on setting labels • Tooltips that say the same thing as the visible label

32. Clueless Error Messages • Message determined by low level code • Reason for error not passed up to higher- level code • Generic message components

33. Message determined by low-level code • Errors are detected by low-level service function which either displays: • Error dialog box directly • Passes the error up to the call stack • Higher-level functions display message without translation • Difficult to correct. • Example • GraphicsNotFoundException • Error 500 HTTP Web Server

34. Message determined by low-level code Example: Apple Safari browser: error message from JavaScript interpreter.

35. Reasons for error not passed up to higher-level code • Errors not properly passed from low-level utility functions that detect errors to high-level functions. Example: Loading a non-existent data file: “Error parsing data file. Data not parsed.”

36. Generic message components Unhelpful generic messages: “One-size-fits-all” • Error text messages • Dialog boxes Example: • Name contains invalid characters. • File missing or you don’t have access.

37. Generic message components Informative Error Message

38. Design Rule • Express the error in the vocabulary of the task domain. • Don’t just identify the problem, suggest a solution • Error message should focus on the solution. • Pass errors up to code that translate them for users

39. Design Rule • Parameterize messages and messages-bearing components • Different types of messages have different audiences. • Indicating user error (for end users) • Logging activity (for system administrators at user’s site) • Facilitating debugging and tracing (for developers)

40. Misuse and nonuse of”…”on command labels • Omitting ”…” • Omitted “…” on commands that should have it.

41. Overusing “…” • Append the Ellipsis symbol (“…”) to command labels that should not include it.

42. Design Rule • Ellipsis for any command that opens a window • True for all GUI platforms • It’s not arbitrary • What about graphical button labels?

43. Inconsistent use of colons on setting labels • How should labels be visually separated from there corresponding Settings? • A colon and a blank space • Blank space

44. Design Rule • What are the standards • Users of colon • Microsoft Windows • Don’t include colons on superordinate labels • A label serving as a superordinate heading for a group of settings should not end in a colon.

45. Tooltips that say the same thing as the visible labels • Displaying the same text in the tooltip (popup textual explanations ) as is already shown on the label of the control Solution: • If it’s simply redundant, don’t bother • If it’s an important job, then the tech writers should do it

46. Misleading window titles • Same title on different windows • Window title doesn’t match invoking command • Special Cases

47. Same title on different windows • Window title bars don’t identify specific windows. • Application with windows having the same name- that of the application

48. Programmer copied window code but forgot to change the title. • Programmer didn’t know title was in use elsewhere. • Programmer thought title fit both.

49. Design Rule • Every window should have a unique title • Message files can help Special cases: • Multiple windows represent same function applied to different data. • Multiple windows represent same function or data with different user options.

50. Window title doesn’t invoke match invokingcommand • Titles on windows or web pages • And labels on the commands • Menu item • Buttons • More examples: table 4.2 • Window Title: • “Choose Message” vs. “Message Browser”