SunQuest
 
       Practices
  Home arrow Practices arrow Page 5 - The Importance Of Interface Text (part...
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Actuate Whitepapers 
VeriSign Whitepapers 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
PRACTICES

The Importance Of Interface Text (part 1)
By: Deepa L, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 4
    2003-03-19

    Table of Contents:
  • The Importance Of Interface Text (part 1)
  • Form Versus Function
  • The First Date
  • Cheat Sheet
  • Matching It All Up

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    The Importance Of Interface Text (part 1) - Matching It All Up


    (Page 5 of 5 )

    Having set the boundaries and the process for the delivery of interface text, it is now important to understand the approach required. Developing interface text requires two areas of knowledge: knowledge of the domain for which the application is being developed, and knowledge of the principles of developing good interface text. I'll address the first one, domain knowledge, right now and leave a discussion of the principles behind interface text to the second part of this tutorial.

    I think you would agree that knowledge of the domain for which the application is being developed is essential - and by the time you are through with designing the application's labels and messages, you will have a thorough understanding of the processes which are being addressed by the application.

    The important thing from the perspective of interface text is to imbibe the verbiage of the users and to understand the changes that your application will bring to their workspace...and how the changed aspects are to be worded to retain association.

    What happens usually is that tasks otherwise manually performed by the users change drastically in appearance when they become application-enabled. Let's take a simple example: all workers in organizations submit vouchers for reimbursement of cash expenses. Enabling this in an intranet-based aoftware application would (most probably) require them to submit a form detailing their expenses for approval by the cashier, the cashier approving it at his/her terminal, and the amount getting deposited in the user's account as a result of the approval.

    There are two levels of change being introduced by the application-enabling of this process:
    1. There is now no voucher in existence. What the users are filling and submitting is an online form.
    2. The actions required to perform this task change. - The user no longer gives a voucher to the cashier - The cashier no longer signs his approval - There is no separate act required by the cashier to deposit the amount in the user's account - the deposit happens via automatic trigger.
    Now, if we were to consider the online and real-world equivalents for this task, we would have the following table:

    -------------------------------------------------- Real-world | Online -------------------------------------------------- Voucher | Expense form | Give voucher to cashier | Submit | Sign voucher | Approve | Dispatch cheque | NA --------------------------------------------------
    In order to reduce user confusion and quickly familiarize them with the new world, the application's interface should use the original term for the task, and the newer, unfamiliar online terms for actions related to the task.

    For example, here is a simple menu tree for the example application above:

    Main menu | |-- Vouchers |-- Submit |-- Approve
    Users know and expect that your application will change the way they do things. As long as your terminology is indicative and can easily be referenced against the old way of doing things, they will live with it, and probably learn to love the efficiency. But if your terminology is hard to understand, or makes them re-learn what they already know, they will hate you, your software and your organization. Making sure they pick door one, and not door two, is really the prime task at hand.

    In the next article, I will be continuing this discussion with a quick roundup of the principles behind writing good interface text, together with a series of examples that will illustrate my point. Make sure you come back for that!

    Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!
    DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

     

       

    PRACTICES ARTICLES

    - Finishing the System`s Outlines
    - The System in So Many Words
    - Basic Data Types and Calculations
    - What`s the Address? Pointers
    - Design with ArgoUML
    - Pragmatic Guidelines: Diagrams That Work
    - Five-Step UML: OOAD for Short Attention Span...
    - Five-Step UML: OOAD for Short Attention Span...
    - Introducing UML: Object-Oriented Analysis an...
    - Class and Object Diagrams
    - Class Relationships
    - Classes
    - Basic Ideas
    - Choosing the Right Team
    - Trees





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway