Didier's Blog

This example violates one of my "prime directives" of good UI design. Why does a user need to know that an apparently arbitrary number (30) represents sales? Instead, why not offer the user a pull-down of the different departments and let the back end (ADF, AS, or whatever makes sense in the application) make that association for the database? I am forced to use Oracle Apps T&E and the design methodology in the example just makes me nuts because it slows usage down to a crawl. Since time is money, why not make it as easy on the user as possible? Now, I have no claims to being a super web designer, so if there's some technical reason why it must be done this way, I'd sure like to hear it. It might save my walls from all the head beating I've done waiting on T&E to draw screens.

Hi Brian,

I don't see anywhere in my post a recommendation about the usage of this design as part of the best practices.
You are preparing my next sample, however, where I use a list for the department.

Concerning the UI design principles, it simply depends on the end users who will use your application.

When I'm ordering a book an Amazon, I don't want to know that "AM" means "American Express", "VS" "VISA", ...
I just want to select the credit card from a list.

However, in the application I'm using daily for support, I just know that "ASG" means a new Service Request was assigned to me, "1CB" means the customer called back.
I know these by heart and I don't want to select them from a list (that would be far too long I fear).
And if there is any doubt, the 'lookup field' displays the value in "understandable" terms, and there is often a list of values window associated with.
A lot of our customers develop applications as these, as we get many questions about these "lookup fields".
It just depends on the level of knowledge of the data the end users, and how often they use the application.

Thanks for your comment.
Regards,

Didier.