Simple GUI question: The specs says: the user should be able to select the origin and destination of flight... 1. Does it mean I need to use comboBoxes to let the user SELECT the airports, or text Fields will be OK? 2. Do I have to add other conditions, such as the carrier, or the day? Thanks
Hi, from a user point a view, what do you prefer: a list where you can see all the flights? Or a textfield where you have to type a code that you might not know? I did use a combobox! All real applications that I've seen uses that. /Enrico
hi Leonardo , well i guess u must have been pretty much convinced by enrico's answer. i'll give you one more positive aspect of using combobox. if you use a textfield. then the user is going to type his criteria find string. so u will have to do a lot of validation there. if you use a combobox, the power of generating the combobox will be in your hand. and belive me that makes a developers life like u and me a hell lot easier
i think text field is better, because in real world case, there are so many airports, the select list could easily grow very long, say, 100+ items, which is not good i guess. also, in real world case, we normally use location names instead of airport codes in such booking systems because not many people are familiar with airport codes. the best approach might be having a textfield and a "code lookup" button. if the use knows the code, he can just type in, if not, he can click the button to fetch all the codes.
Originally posted by Siddharth Mehrotra: hi Leonardo ,
and belive me that makes a developers life like u and me a hell lot easier
The real answer here is that we should use what the customer (end user) specifies in the GUI design sessions. Unfortunately, we aren't given a clue to what the customer (read person who pays the bill) wants. We can use best practices and think that using a list selection box is the best answer, but if the customer wanted a text entry field, than a text entry field is what he gets.
Thanks all of you guys. You give me more idea about this assignment and real things.
Joined: Aug 21, 2001
but still, as per the assignment and also in real world computing, i think it is a bad practioce to make a user type some cumbersome piece of string like the criteria find , or some code's (even through we might have a code lookup) and make his search. the best solution in that case maybe that, we fetch the data in a collection and depending on the size of collection shpow up the GUI. if the number of elemets is more like say 100, then we can post that adat on a lookup window , otherwise dump it into a combobox
Hi all, actually there are about 9297! tree letter codes for the (important) airports around the globe. AAAAnaa, French Polynesia AABArrabury, Queensland, Australia AACAl Arish, Egypt AAEAnnaba [El Mellah], Algeria AAFApalachicola, FL [Apalachicola Municipal Airport], USA ... to ZXARota [Rota Naval Station], Spain ZXDSan Isidro, Dominican Republic ZXESculthorpe, United Kingdom ZYLSylhet [Osmany/Shylet], Bangladesh ZZUMzuzu, Malawi ZZVZanesville, OH [Zanesville Municipal Airport], USA The funniest thing is that ANY also is a vaild airport 3lc: ANYAnthony, KS [Anthony Municipal Airport], USA What about that? My idea was to provide a text field (for power users) and a lookup button for ordinary users. Think the 'any' thing I'll handle with a check box (enable/disable) criterion. Cheers, Horst! PS. I'd benefit from that lookup thingy too, cuz my girl friend's a flight attendant and I often have to lookup where she's staying.
Joined: Nov 09, 2001
Originally posted by Siddharth Mehrotra: but still, as per the assignment and also in real world computing, i think it is a bad practioce to make a user type some cumbersome piece of string like the criteria find , or some code's (even through we might have a code lookup) and make his search.
Having worked as a developer for a major airline carrier based in Dallas, Texas, USA (can you guess who I'm talking about?), the entire set of commands are in fact all text entry. This system has been around for years. Whatever the user wants is what we should design, IMHO. It makes no difference how hard it is for us developers - the customer (end user) rules.