Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

GUI Design

 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I am trying to create a design for the GUI, I am thinking about creating JDialog subclasses for each function, i.e. search, read, delete... etc and the list them on a tool bar on the main window together with the JTable.

This I think is fine but would take up quite a few classes, I don't know if it's better to create panels for each action and place them all onto the main window.

Does anyone know if Sun would give marks for a GUI with good amount of features or are they simply looking for a bare bones GUI and will ignore anything extra?

Any help is appreciated.

Thanx,

James.
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My instructions say:

"Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs."

I am not quite sure what they mean about a "framework". I can build a GUI but how is it going to be a framework?

If anyone has any comments please let me know..

Thanx for your help.

James.
[ June 24, 2004: Message edited by: James Turner ]
 
Marcus Beale
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs."


What that means to me is that when new features are added to your GUI it won't be radically changed. In fact it should change very minimally. A new menu will be added, or a new button. But the existing buttons and menus that the user has grown use to being in a certain location will still be in that location. So your application should have a framework that will support future functionality.

Another words, don't just put everything in one JFrame - make dialogs for connecting to the database and booking clients etc. Provide a Overview/Details approach. Provides actions that can be performed on detail record, but leave room for more actions to be placed here.

Originally when I read the quoted statement I thought Sun was asking us to create an automatic code update feature that would allow the clients to receive code updates, without overly disturbing the users or requiring new installs. I've since come to believe that this was not what was intended.

, Marcus
 
Eben Hewitt
Author
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did Bodgitt and Scarper. I wrote a little framework to handle facilitate the use cases. Use cases (such as Add Contractor or Search) switch out the main area of the application. I use reflection to discover the name of the class containing the main panel so I can manage it for different use cases.

I made abstract classes for panels and frames that handle a lot of the template code (like setting size or a title for the screen).

Each use case is implemented as MVC.

So to add a new use case, the programmer just needs to add a new JMenu (or new JMenuItem if it is related to Contractor stuff), subclass the abstract model, view, and controller and write the use-case specific code there.

Having done most of my work in the web world, where a framework means something like Struts, I have this view of what a framework is.

But I may have gone overboard. I had a lot of fun with it, and I don't believe that that is all necessary.
 
Eben Hewitt
Author
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To better answer your initial question, I made mine look like regular software looks. So while I don't know how they assign points, I like your idea of using a JToolbar with panels and layouts and the whole shebang if you have the time.

I used a JToolbar and a JMenu, because that's what real software looks like (a browser for example).

Perhaps I misunderstand, but I think a JDialog is great for, as Marcus says, booking the record. But I am not sure about using subclasses of that for the main areas. I like your panels idea better.

Here's why:
It's better practice for real world development.
It is more work, but it is more flexible which I think will be reassuring as the project goes on.
It encourages the other aspects of your project to be sophisticated (for example, it encourages you to think about clearly separating the View from the business logic).
It is a certification exam, so you're not just getting through it, but demonstrating that you can do stuff like use GridBagLayout and tooltips and JScrollPanes and whatever.

I agree with Marcus.
[ June 24, 2004: Message edited by: Eben Hewitt ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic