2. Observation: -3 different sections for the post office. Mailing/collecting items, paying bills and mailing out big/bulky items. the queue for paying bills and general enquiries are usually the longest despite having 3-4 counters open. Some people are getting impatient and paid by using the AXS/SAMS machine provided nearby. I saw postmen collecting all the mails to be sent out, promoters trying to promote insurance.

3. a) what is the item/service?

-paying bills and mail out items

b) who uses it?

- public who need to make general payments and post out items either locally or overseas.

c) When do they use it?

- usually when payment is about to due they will make the payment whereas for postage, usually because of some online business that they are doing or even gifts or presents for/from overseas.

d) how did they use it?

- Firstly, they will queue up accordingly. There will be 3 different sections in the post office. One for mailing or collecting mails, the other is for bulky mails and lastly, payment of bills and general enquiries. Once their turn is up, for people who is mailing out item, they will either have to choose normal postage or registered mail. The difference between this 2 is that reg mail can be tracked and usually encouraged for online sellers who selling their stuff at a higher price. Shall item go missing or did not reached the buyer on time, they can check with the post office about it. For mailing out bulky items, the procedure will still be the same. As for making payments of bills, they will have to wait for any counters which is available and make payment either by cash or net or credit cards (if applicable).

e) is it wasy to figure out the functions and purpose?

-YES, as there are signs to show clearly which queue should they join and the service are fast and efficient.

f) is it clear for user to interact with it?

-In this case, it’s the service with the counter staff. It’s easy for user apart from the sign and the queue that they have to follow, they can also approach the friendly staff for assistance shall they have any enquiries.

g) does it take human behaviour into account?

-To a certain extend they do

h) is it logical?

-Yes as people have to queue for their turns.

i) is it safe?

-Yes as there’s no signs or ways that users can get hurt while queuing or when talking to the staff

k) how flexible?

-It is not that flexible as each queue is for that one purpose only. Postage will be one queue, posting out bigger items is naother and lastly paying for bills and general enquiries.

l) can people with special needs use it?

-The queue for all counters are very narrow. I do not think that it’s possible for the disable people esp those who’s on wheelchair to queue. As far as my observation goes, i did not bump into any handicapped people but i believe that the staff will give privilege for those people with special needs and assisting them with their payments/postage. Apart from that, i did saw some staff just standing around the post office to answer or help people who is unsure on which queue that they should join.

m)which aspect do u think the item satisfy?

-social, mental.

The visual feedback is given in real time, according to the user’s choice. The music rhythm serves as a visualization parameter of the style’s icon, creating multiple sonorous visualizations. You control the visualization through wiimote controls, while audible feedback is given through wireless headphones.

http://3bits.net/synclost/

The goal of this project is to question the top-down categorization and evaluation of music by the music industry and its sales charts by using Twitter as an alternative ranking system.

http://www.alimdardesign.com/twitterlyrics/demo.htm

The authors used the New York Times API to parse through all articles written in 2009. Using key words that dealth with characteristics of each governmental agency, they displayed their frequency usage in comparison with one another. The colors on the right rings are representative of their colors from the left.

http://www.pitchinteractive.com/usbudget/

• Always use cute icons, buttons, and graphics. Everyone loves big red hearts, pink bunnies, and yellow smily faces.

• Don’t be afraid to experiment with colors!

• Your application should play fun sounds while operating to keep the users entertained.

• Never, ever, under any circumstance use the OS-native graphical controls or widgets. Users get bored of the same old buttons, text boxes, and stuff.

• When possible, disable window management and use unusual, oddly placed graphics for the windowing functions such as the window close option.

• When writing your own controls or widgets, make absolutely sure they look and feel nothing like the OS-native widgets or anything else the user might expect. Otherwise you might accidentally make the user think that your application is actually designed for their OS.

• Use your own creative ideas on how a “save as” dialog should look and work. Built in ones are always too limiting.

• It is important that the user should never be able to tell the difference between a checked and unchecked check box or option box.

• Always use obscure or poorly drawn graphics for your tool bar buttons, and never put text on them.

• Avoid including a preferences or options dialog. Instead, let the user use the standard OS provided text editor or an editor of their choosing to edit text configuration files. .

• Users need time to think about what they are doing and get coffee. Your application should always take at least 5 minutes to load even on the fastest available computer.

• Make sure an accidental double-click on a single-click item does something really nasty or unexpected.

• Tool tips are the perfect way to display critical information.

• To get the most screen space, force your application to always run maximized.

• Always make the default positions of floating properties windows cover something important.

• Use the most exotic fonts you can find.

• Your application’s user interface should be flexible and customizable to the point where if the user accidentally sneezes on the mouse or keyboard they will have to spend the next half an hour setting things back.

• Let a 5-year old draw your graphics, including your corporate logo.

• File browsing dialogs are not needed, users can easily remember and type in long file paths.

• Design your application so it requires the user to set their tiny monitor to 10512*7430.

• Always crash at a critical step and then display a fake apology to the user.

• It is a mistake to make use of application hooks in the native desktop environment such as new file templates, file associations, or program menu icons.

• The exception to the above is placing icons in the system tray. Place as many icons as you can in the system tray and make sure that the user can not remove them.

• If your program implements keyboard shortcuts be original and make them completely different from any other applications.

• Rent extra UI space in your application out for advertising. Advertising benefits the users and your wallet.

• Never underestimate the power of nudity.

• Don’t forget to embed a hidden video game as an “easter egg”.

Application Help: How to make a help system that is impervious to usefulness.

• There is no need to include a manual with software. These days users are smart enough to figure out this kind of thing on their own.

• If you do include documentation, there is no need for printed manuals. Users love staring in to a 17 inch light bulb all day.

• Always put your installation instructions on the CD-rom rather than in a printed manual to save paper. The instructions should be installed with the rest of the program so they are not accessible until it is installed.

• Keep help files simple. Only state the bleeding obvious about any given topic.

• There is no need to use consistent terminology.

• For program error, warning, question, and information messages, explain what is going on to the user in the most technical terms. They really need to know and learn this stuff because it is important. As part of the message dialog include a help button that opens the help file and displays exactly what the message just said.

• Display as many information and question messages as possible in as many different places as possible. Except before critical irreversible operations such as wiping the hard drive.

• It is acceptable to use “Engrish” throughout your application. All your help file are belong to us.

Making the web do things it has never done before
(and should never do again).

• Always build a web browser in to your application. For best results make your own web browser.

• Always hard code hyperlinks in to your application. Then make sure that the links don’t work two months after the application is deployed.

• When you launch a web browser, never use the user’s default browser. Always launch the crappiest one available (I.E.: IE) (See above, you should write your own).

• Always use hyperlinks instead of buttons. Hyperlinks are cool.

• Be sure to include a throbber graphic in every window of your application.

• Applications should look like web pages because the web is the embodiment of usability.

• All modern applications are required to automatically sign users up for spam.

OS Specific tips

• For a great first impression during your OS setup, never set the video to a refresh rate that works with user’s monitor.

• In fact, your OS should never, ever set the proper refresh rate for the monitor. Eye strain is good. In fact, whenever possible set it to a refresh rate that the monitor can’t handle at all. If the user does manage to set a higher refresh rate, make sure it is non-standard so they have to fiddle with the monitor sizing and positioning. Bonus points for finding a refresh rate that makes the monitor blow up.

• When packaging a GUI or operating system make sure the same functionality is available in at least a dozen different places in unrelated programs.

• Include three of every kind of application program. (four or more if possible).

• Install all possible advanced utilities and mindless junk that the typical user will never use.

• Uninstallation options are out of style, don’t include any. If you do need to include them make sure they always choke on dependencies.

• It doesn’t matter if your file manager / desktop shell is slow and sluggish. Go ahead and integrate it with your web browser. In fact, integrate it with several web browses while you are at it.

Application design for the ultimate user experience (in hell)

• Begin coding the guts of the program immediately. Designing the UI can come later in the development process.

• Don’t waste time writing efficient code. GUIs don’t need to be responsive and it is easy to make users upgrade to the latest 10,000,000 terahertz CPU and who doesn’t need another zillion gigabytes of ram?

• You can implement features half way. Your users will forgive you. (And if they don’t, screw them anyway). Or you can always make them upgrade to the next version.

• You don’t even need to finish your software, if someone else has a problem with it they can fix it themselves.

• It is safe to ignore the overall purpose of the application you are writing. Just make it do what you want.

• There is no need to do any kind of user testing or research. Programmers always know the best way to design a user interface.

• Let the users dictate design and implementation decisions, after all they know what they need.

• If this is a corporate environment, always design the user interface the way the boss wants it. After all, that degree in user interface design he has is how he got to be the boss right?

• When porting your application to another OS platform, there is no need at all to modify the way your application looks or behaves.

• Always hard code all references to the file path your application must run in. The user will never have a need to install anywhere else and you will never run in to naming conflicts.

• Sue anyone who makes a UI even remotely like yours. That’s what the legal system is there for right?

• Always use bizarre, scary sounding code names for the name of your application. For best results it should be an acronym for something that doesn’t make any sense, and the acronym should be recursive.

• Never remove old, obsolete, buggy, or nonsensical features from your application.

• Pre-load your (now huge) application at system startup. It doesn’t matter if it slows down the rest of the system, it is important that your application, which most users only use only occasionally, start the fastest. .

• Add all possible features to your application. Even those that already exist in the OS. In fact, your application should eventually become an OS.

http://toastytech.com/guis/uirant.html

Stark Wall Interactive – Library