Changes Are Coming To the GlassFish Admin Console

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

Let's start this discussion by listing what we want to get rid of.


The 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:
  • Less redundancy in serving multiple resources to the various frames - Since each frame is bascially its own document, various resources are requested by each frame. Specifically, since each frame uses the same JSF component set, each frame requests the various Javascript and CSS files, for example, resulting in many, many duplicate trips to the server. If we can cut down on the number of trips back to the server, we'll see a lighter, snappier UI.
  • 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. :)

Tree navigation

For years now, we've used a tree on the left side of the page for navigation. It works well enough, I suppose, on the client side, but maintaining the tree has issues, primarily that it's slow to create. Since it is so slow, so we put in a frame (see above : ) to avoid recreation as much as possible. Moving to a lighter-weight solution will remove the need for a frame.

What we'd like to add

Example of the proposed UI changes

Example of the proposed UI changes

If we get rid of the tree navigation, we obviously need to replace it with something. We have several ideas as to what can replace the tree, and what can be added to improve further the user experience in the console.


The direction we're heading is a menu bar, the horizontal application menu bar type. This gets us a way to organize the navigation options, but also greatly reduces the amount of real estate the navigation aid consumes (the tree takes a large chunk out of our usable space, especially at lower resolutions). We're also considering changing how things are grouped. Currently, the tree is grouped largely by objects: applications, JNDI entries, connection pools, etc. What we're considering is moving to a more action-oriented grouping: deploy, configure, edit, etc.

Desktop Paradigm

In my experience, when interacting with the console, I often have to work in different areas. Take creating a JDBC resource. Currently, I have to create the connection pool, then navigate to the JDBC resource page. To help reduce the amount of navigation needed for common tasks like this, we're experimenting with a window-based interface -- not multiple windows, but those fancy DIV-based "windows" that so many sites have these days. Our ultimate goal, should be implement this particular change, is to allow multiple open windows, allowing the user to work in several area "simultaneously." Our initial plan is to support only one window at a time, given our time frame, but this will get us moving in the right direction.

Dock Bar

In addition to having multiple windows, we've kicked around the idea of a Mac OS X-like dock bar. Exactly how it would work hasn't been decided yet. One proposal is that it is just like the Mac dock bar: certain aplications (which would be windows, in our case) are opened automatically and are always in the dock bar, while some windows are avaiable in the dock bar, but not yet opened, as well as any minimized windows. The other proposed approach is closer to the Windows task bar in function, where the dock would contain only windows that have been opened via the menu bar and minimized.

Searching and Tagging

In the course of discussing all this, the idea of searching, which was raised initially as a possible feature for v2, came back up. Let's say you need to create a JMS destination, but you're not sure where all of the JMS-related options are in the console. With the search feature, you would be able to enter the phrase "JMS" into the search bar and see a list of options you can click, which will open the appropriate window. To complement the search, we're also discussing the idea of "tagging" the windows. Let's say, for example, the every Monday morning and do the same tasks, such as monitoring, checking logs, etc. Using this proposed feature, you would be able to tag each of those windows with, for example, "monday" and then, each Monday morning when you get to work, you can simply search for "monday" and see every window you need to visit. This has the potential to be a huge timesaver.


Of course, if we add features like tagging, we'll need somewhere to save it, so we're investigating the use of the Preferences API. This would allow for a per-user set of preferences that would follow him/her from one browser/workstation to another. It would also allow us to do such things saving window locations, so you won't have to constantly rearrange windows. We would also be able to customize the task bar or a common tasks page, remembering frequently entered values, etc.

What we'd like from you

As I stated at the top, we on the admin console are very aware of the fact that users love our console. It's a very powerful and usable addition to GlassFish, we think, and market research seems to bear that out. With that in mind, we don't want to make sweeping changes that our users don't want, need, like, etc. We'd also really like to make sure that we integrate as many changes as possible (and make sense ; ) that our users would like to see. So, then, what do you think? Are the ideas I listed above heading in the right direction? Is there something you'd like to see us do? Is there something you'd rather see us NOT do? Now is your chance to affect the admin console that GlassFish will have for the foreseeable future. You can join the discussion on our mailing list or on IRC (#jsftemplating on where our team is almost always on. Speak now, or forever hold your peace! :)

I think the changes you listed are good. You don't want to change too much on what is an already great console. I for one don't like change.

Posted by brian on December 16, 2008 at 03:33 AM CST #

Why not do it in JavaFX?

Posted by Java Developer on December 16, 2008 at 03:59 AM CST #

Since you've made some mock-ups, why not host them on (or elswewhere) and lets us point-and-click ourselves? Optionally, create a set of screencasts with different approaches. Select a set of use cases (create a connection pool, create a cluster, monitor some aspect of the appserver, deploy an app, etc) and mock them up them using various approaches.

We've received a ton of great feedback on what we already have, so I have to agree with brian, along with your comment, that we have to be cautious in how we improve the user experience. That being said, there is always room for improvement. Lets go through some iterations with community feedback. One concern is the potential re-training involved for larger organizations with large deployments. We can point them to your screencasts/mockups and get some feedback. I can facilitate those conversations. Along with community feedback, we'll get to a great solution.


Posted by John Clingan on December 18, 2008 at 03:17 PM CST #

Java Developer,

JavaFX has actually come up in our discussions. While that might be an option down the road, right now, we just don't have the expertise on our team, not to mention the time, for something like that. As a team, we know JSF really well, so we'll likely stick with that for the foreseeable future.

Posted by Jason Lee on December 23, 2008 at 01:27 AM CST #

John, that's a really good idea. I'll see if we can get something like that fixed up over the break or early next year. We have a very rough prototype (from which that screen shot came), but is the actual GlassFish Admin Console, so to use it, we'd have to give public access to a GlassFish instance. If that instance is there only for that purpose, that's not a problem, but we don't have anything like that set up at the moment. :P

Posted by Jason Lee on December 23, 2008 at 01:29 AM CST #

One thing that would be nice is a clickable option to be able to make a clone of a connection pool when creating a new one (so all you have to change is the name and the login or whatever). You can copy configs when making new clusters, so why not JDBC resources as well?

Also, focus on the username form field on the login screen would be nice (SUN Java Web Server admin does it) :-)

Other than that, functionality-wise, I agree with losing the frames. Also some of the options are hard to find unless you know where to look (like tuning HTTP pools, etc., JMS options are in two places - under the config AND under resources, etc.)

Posted by misschatter on December 23, 2008 at 05:24 AM CST #

Post a Comment:
Comments are closed for this entry.

Jason Lee


« June 2016