Cert nightmare

[frank sanzone]

Okay, I uploaded my assignment back in Dec. I took the test on 1/09. 4 weeks later there's no grade in certmanager. Sent an email, and they said they just uploaded my test on 2/04, and would expedite the grading of my test within 10 days. 10 days pass, no grade is posted, sent an email to sun directly..."i'll get back to you"...5 days later a grade is posted.
Surprise, I failed! I rcvd 0 points for the GUI, yet rcvd only a few minor deductions in the other areas. Anyone have any ideas why I would rcve a 0 for the gui only? The front-end was succesfully run in both a Linux and W2K environtments, following the directions in readme.txt, so I know the front-end worked. I also included everthing specified in the rqrmnts.(I'm verifiying now just to be sure)
How could they test the rest of the program, and give me only minor deductions if the gui didn't work? I've emailed sun, but it will be days before they get back to me, any thoughts someone could provide, would be much appreciated!
Thanks
Frank

[Mark Spritzler]

It might be possible that they made a mistake and put 0 in for the GUI instead of the real grade.
I hope that is the case.
Mark

[ravi janap]

Hi
If Sun does not give any reason whatsoever failing a submission, How does the candidate recognize the error, correct and resubmit it ?
I hope the examiners are more reasonable and give the exact reason for failing a submission. That would be helpful for the candidate since submission-resubmission costs lot of money.
Thanks
Ravi

[John Smith]

Anyone have any ideas why I would rcve a 0 for the gui only?

I also think this was just a mistake, I can't see how anyone can get 0 points for GUI. Just email them, I am sure they will fix it.
Eugene.
[ February 18, 2003: Message edited by: Eugene Kononov ]

[frank sanzone]

Here are the reasons they gave me. I don't agree with them because none of them were documented in the rqrmnts. Sure, I should have rcvd deductions if there were layout manager problems, which I could not reproduce on Linux or W2K, but to give me a 0!? I'll fight it as long as I can. Eventually, I'll probably just have to resubmit.
1. GUI has no menu bar or no file menu.
2. No pull downs for specifying origin/destination airport. (manual entry
text fields used)
3. Uses a drop down for seat selection for flights with manuy available
seats.
4. Layout is illogical. After resizing the JFrame turned into an illegible
mess right in the middle
of the screen. Layout manager problems.
5. Urgent notifications were not done with dialogs for example, when a user
tries to reserve too many
seats, or tries to quit. (GUI terminates without dialoging the user or
providing the opportunity to
cancel.

[John Smith]

1. GUI has no menu bar or no file menu.
2. No pull downs for specifying origin/destination airport. (manual entry
text fields used)
3. Uses a drop down for seat selection for flights with manuy available
seats.
4. Layout is illogical. After resizing the JFrame turned into an illegible
mess right in the middle
of the screen. Layout manager problems.
5. Urgent notifications were not done with dialogs for example, when a user
tries to reserve too many
seats, or tries to quit. (GUI terminates without dialoging the user or
providing the opportunity to
cancel.

Looks like it is becoming more difficult to pass, and more attention to detail is required. Perhaps the most surprising reason that they gave for failing you is "no pull downs for specifying origin/destination airport". I guess the textbox is no good anymore, it must be a combo box! The rest of their reasons are legitimate, and I think you should comply and resubmit. Still, the 0 points that they gave you was too harsh, I think.
Eugene.

[Mark Spritzler]

Originally posted by frank sanzone:
Here are the reasons they gave me. I don't agree with them because none of them were documented in the rqrmnts. Sure, I should have rcvd deductions if there were layout manager problems, which I could not reproduce on Linux or W2K, but to give me a 0!? I'll fight it as long as I can. Eventually, I'll probably just have to resubmit.
1. GUI has no menu bar or no file menu.
2. No pull downs for specifying origin/destination airport. (manual entry
text fields used)
3. Uses a drop down for seat selection for flights with manuy available
seats.
4. Layout is illogical. After resizing the JFrame turned into an illegible
mess right in the middle
of the screen. Layout manager problems.
5. Urgent notifications were not done with dialogs for example, when a user
tries to reserve too many
seats, or tries to quit. (GUI terminates without dialoging the user or
providing the opportunity to
cancel.

Unfortunately Frank, I would have to say that #4, and #5 are serious problems and enough to get more than half taken off. The other three are minor deductions. But added up I can see where they could deduct everything off.
On the bright side, you now know what areas are already perfect and which needs changing, so that your next submission will be much better. Use the above comments from them to heart and change your GUI accordingly. You will be able to find everything you need to change them correctly here in this forum. Like the Menus and Help.
Good Luck and I am sorry that you have to redo it, but think of it as an expensive learning experience. Sorry about that I had to throw in a jab there.
Mark

[frank sanzone]

Yes, I also think it was too harsh, but I doubt "the man" is gonna change his mind. I'll stop crying and make the enhancements they want to see. Hopefully I can convince them to let me resubmit w/o paying, due to the fact they initally lost my test and gave me the run-around. We'll see...

[frank sanzone]

Out of the blue, an upper cut from the bartender! Come on now, I'm a server-side guy with very little artsy-fartsy in me! Oh well, I guess I'll just have to become a little more well-rounded.
On another note, great site! Hindsight, I should have paid more attention to the gui threads. Guess I'll be doing that tonight!

[Kathy Sierra]

Howdy -- this one is a little tricky, but the core idea for the assessment is that you follow standard practices whenever possible, and that these standards do not have to be explicitly mentioned in the requirements. So that's why the menu bar and file menu are important and expected, for example, even though not specifically asked for in the requirements.
In general, standard GUI principles they're looking for include:
* Having a menu bar and file menu
* Having a logical and resizeable layout, without clutter, and with logical (non-arbitrary) groupings of components
* Using text entry fields where appropriate and pull-downs where appropriate. While there is no set rule for exactly what is and is not appropriate, in general -- any place where there is a high chance for error or where the user has to remember to type something in an exact way, use a pull-down (unless the choices are HUGE, invoking fuzzy logic again as to what 'huge' means, of course
And by the same token, do not use a pull-down when the choices are easier to enter and the number of choices is huge (so, for example, do not use a pull-down to enter a number between 0 and 100, or the days of a year, but the days of a month is probably acceptable).
* Use dialogs where appropriate, but not where inappropriate -- again, this can be somewhat subjective, but the idea is to use dialogs for 'urgent' notifications, but you're just as likely to get graded down for using too MANY dialogs for normal operations that are *not* considered 'urgent'.
I guess my tips would be to follow standard GUI conventions, and you should be pretty safe. Assuming you've followed the other requirements in the assignment, then following GUI standards is all the assessor is looking for. They aren't looking for something special.
It's the same issue with using design patterns and well-known solutions -- the assessors are VERY interested in you 'not reinventing the wheel'. You will be graded down, for example, for not using a well-known standard where one exists, EVEN IF YOUR SOLUTION IS "BETTER" (faster, more efficient, etc.).
Again, think: team player instead of brilliant individual programmer.
Not to beat a dead horse here, but perhaps the biggest problem we see with exam candidates is that they do TOO good a job --- coming up with solutions that solve more than the specification asks for, modifying the spec to make it 'better', using their own non-standard (even if better) techniques, etc.
There are no extra points given for doing something special, clever, novel, especially cool, more performant, if it isn't justified by the requirements and ESPECIALLY if it involves deviating from a common (or at least *known*) solution.
Think team player, not individual 'star', and you should be in good shape!
Of course, that goes against all my cowboy/cowgirl values, but that's the nature of the exam
cheers and good luck,
Kathy

[Mark Spritzler]

Not to beat a dead horse here, but perhaps the biggest problem we see with exam candidates is that they do TOO good a job --- coming up with solutions that solve more than the specification asks for, modifying the spec to make it 'better', using their own non-standard (even if better) techniques, etc.
There are no extra points given for doing something special, clever, novel, especially cool, more performant, if it isn't justified by the requirements and ESPECIALLY if it involves deviating from a common (or at least *known*) solution.
Think team player, not individual 'star', and you should be in good shape!

I love these types of comments, and agree 100%.
Mark

[Brian Blignaut]

Hi,
Not sure I agree with using drop downs for the origin/destination search, I mean it's not very scalable is it? How many search applications use combo boxes? Not many I have worked with.
Any comments?

[BJ Grau]

Scalable? Haha. Not much about this app is scalable.
If you use text inputs, the app will need to do string matching with wildcards, not just exact matches, to be effective. In the context of this assignment, where we are writing an app for a small company, the drop-downs might be more appropriate than implementing robust searching functionality.

[Eric Blische]

Hi,
Thought I'd try to clever with mine ... I start off by populating my departing and arriving combo boxes with all the known possible values, but am considering making my combo's editable ... because another API might support adding a new flight to the schedule whose 3-letter-acronym was not there at startup. Maybe out of scope, but I recall the requirement stating the user may "enter an airport...".
I did make "any" (or was it "all") an option, too because it seemed pretty clearly to be a requirement.

[Marc Peabody]

What search applications use combo boxes? A simple example would be job-search sites, right?

[Anonymous]

GLAD I read this thread. Good bullet points to consider for my app. I've got dropdowns already, and prepopulate them, but used getters on the service layer to get all the unique values for From/To at startup. This seems pretty scalable in that the addition of a new code in the db will appear at startup.

[Bo Thomsen]

Ahh! This probably explains why I only got 12/24 for the GUI.
I also had omitted the (superfluous) menu bar and didn't give a "When you pressed the Exit button, did you really, really mean that?" dialog :-)
I guess I should just have done like the rest even if I don't like it.
- Bo

[Anonymous]

so the menu would only offer File->Quit, and even then there would be a confirmation asking the user if they were certain?

[Bo Thomsen]

To be on the safe side, there should probably be several ways to Exit (or Quit) the application:
- "Exit" button somewhere.
- Menubar with File: Exit with accelerator and mnemo.
- Listening for window close (windows: upper right x or Alt-F4)
- Perhaps listening for Esc pressed in main window?
All these should lead to a "Do you really want to exit?" OK/Cancel modal dialog.

[Anonymous]

the thought of a browser asking me "are you sure?" everytime i wanted to quit is a bad one. sure, if i had made uncommitted changes in ms word, having the app check my certainty is warranted.
this scjd app doesn't have any state (beyond, perhaps, your having specified some seats desired and not having hit "book it"). it does not seem like a good idea to pester the exiting user every single time.
but hey, if the evaluators have made clear that not presenting a confirmation is grounds for reduction in points, who am i to refuse?
does anyone have thoughts on whether this ever-present confirmation dialog is (evaluation aside, just talking straight hci factors) a good idea?
[ March 12, 2003: Message edited by: Erick Reid ]

[Ben Ritchie]

Erick - I think you are right. IMHO you should get an 'are you sure?' prompt if you have unsaved data, otherwise it should be a 1-click quit. But then again, I'm just a server-side guy...

[Anonymous]

good to hear someone else thinks so. i'm a ui guy (not an hci guy -- that's for the experts).
i also thought the 1-item menu bar (File->Quit) was odd, but again, after reading about the candidate who got zero gui points, i shelved a few of my opinions.
an idea: if the ever-present "are you sure you're sure" dialog garners favor from the evaluators, how about making it into a stats update as well -- it can still make sure you're double sure , but it can also say "you booked 94 seats today", or something to that effect. i'd imagine travel agents use such things as performance metrics.

[frank sanzone]

Well, 3 months after it began, I finally passed with a 155! Sun graciously let me resubmit w/o having to pay the resubmittal fee. Thanks for all the great info everyone provided!

[John Smith]

Well, 3 months after it began, I finally passed with a 155!

155 after the initial fail?! What a comeback! Welcome to the club.
Eugene.

[Barry Gaunt]

And only 5 posts on JR!
I'm in line for SCJD next, so I'm very grateful to read these tips. Great news Frank. Stay around we're going to need your advice.

[Mark Spritzler]

Great job Frank. It pays to be persistent.
Mark