Changes Are Coming To the GlassFish Admin Console
By Jason Lee on Dec 16, 2008
GlassFish isn't just an application server. It's a community. For that reason, we on the admin console team want to take some time to run some ideas by the user community. For the GlassFish v3 final release due in the middle of next year, we plan to redesign the admin console. Since the admin console is usually high on the list of differentiators, we are approaching these changes very cautiously, as we don't want to ruin a good thing. Our goals are to make the console lighter and faster, and use a more modern design. Our plan, then has several parts, which we'll look at individually.
Table of Contents
- What we're removing
- What we're adding
- What we'd like from you
What we're removingLet's start this discussion by listing what we want to get rid of.
FramesThe general concensus amongst web developers these days is that frames are no good, and we agree, so we're going to get rid of them for several reasons:
- Better UI experience - Having frames either breaks a lot of things, or makes them difficult or awkward. For example: Printing a page in a frameset ie harder than it ought to be. Extra care must be taken when using the mouse wheel to scroll to make sure you're over the correct frame. The use of the back button sometimes doesn't do what you think it might. Screen real estate is wasted on the the frames' scrollbars, etc.
- Opportunity for bookmarkable URLs - One of the big problems with frames is that they make it difficult to link easily to a specific page. Sure, the user can right click on the frame, open that frame in a new tab and then get the correct URL, but that's not user friendly at all (in fact, it's as un-funny as its namesake comic strip!). If we remove the frame, the page you're on is the location bar at the top. Copy. Paste. Done.
- Reduce implementation complexity - JSF only caches a certain number of pages for you, so if you don't use a frame for while (the header is the best example of this), it's server-side state may no longer be cached, which will cause the application to throw an exception. If the pages don't live in a frame, there's no chance for the view's state to be purged from the cache.
- Don't need to worry about the artificial boundaries that frames impose (menus overlapping frames, JS across frames, etc). - Our UI choices are a bit limited, especially in the tree navigation and header frames, as content from the frame can't extend beyond the frame's boundaries. It is either clipped, or the frame displays scroll bars. For that reason, we have to make sure our content fits inside the frame, or increase the frame size when we need more room. It makes for a less than ideal user experience, and some pretty ugly code, so it has to go. :)