16
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.
Frames
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
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.
Menus
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.
Preferences
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 irc.freenode.net) where our team is almost always on.
Speak now, or forever hold your peace!
Technorati Tags: glassfish, v3
Popularity: 16% [?]
These changes sound great. I hate the frames too and the tree is slow, kludgy and tough to use. Not sure that I would use tagging right away, but I can envision it’s utility. I think that the community could provide better guidance on creating Realms and how this can be part of a security solution that is simple and robust. Let me know if an example is needed to clarify this statement.
THX
-Michael
December 16th, 2008 | #
Although the idea is great, I would recommend you guys to keep the old admin console as well if possible , so that people can try new console for some time and then gradually shift to the new one.It may not be possible for everyone to quickly start using the new one .:razz:
December 16th, 2008 | #
Just so long as its intuitive… I.e. I dont need to read a manual to work out how to use the console and find what I need to. I’d also suggest an enhancement on the current console: Can you somehow have a pop up or something next to each field that tells you what the MBean path / asadmin setting is for that field. Often I want to script changes I did in the admin console and want to quickly be able to see what asadmin command to use. What would be even cooler is to be able to record a series of changes in the console and then spit out a bash script with the asadmin commands to automate those settings on a fresh install.
December 18th, 2008 | #
I like the proposal, but I am wondering if it will really reduce the complexity. The current frames and arrangement make the application very intuitive. I would hate to have to search for things that I could easily see in the tree before. I never really noticed any “slowness” in the tree rendering and found it the easiest way to navigate to what I needed. Placing those items in a menu system has a tendency to add complexity when looking for something.
December 22nd, 2008 | #
@Paul, I love that suggestion. I was already going to make the suggestion for the admin console team to continue improving the asadmin tool (because it is essential for fellow administrators), but having coordination between the UI and the command line tool is a great idea that I hadn’t considered.
December 23rd, 2008 | #
I am in complete support of both the removal of the tree in favor of a menu bar and the keyword search for locating pages similar to the preferences screen in Eclipse and IntelliJ. However, I am not keen on the windows idea. Personally, I find having to manage windows (whether they be inline or real popups) to be tedious. If there are multiple logical steps that need to be performed, I would much rather see wizards or breadcrumb navigation. Since there are so many options available, I would rather focus on one small task at a time. If it is really necessary to perform a lot of work, it should be scripted (with asadmin) anyway.
December 23rd, 2008 | #
Sreekanth, I see your point and can certainly sympathize (having come from the end user world myself : ), but there’s a lot left to be done on the console for the final release, and we just don’t have the resources to do two consoles for the (expected) JavaOne release.
December 23rd, 2008 | #
Paul and Dan, having the console show the asadmin equivalent is a really cool idea. I could be wrong, but I’m pretty sure that has been requested before and there might even be an issue filed for it (if not, feel free ; ). Obviously, I can’t commit to something like that for this release, but that’s certainly that can be added later if it doesn’t make this next release. One of the really nice things about the way we’re going about building v3 is that we’ll be able to upgrade individual parts (the console, JSF, the JEB container, etc) via the Update Center as soon as updates are available instead of waiting for a whole new server release. Time will tell how much other teams make use of the capability, but I think we’re planning on using that as much as makes sense.
December 23rd, 2008 | #
John, Part of the complexity we aim to remove is in the code itself, so it’s not directly visible to end users. You might see it, if you know what to look for, in things like the slow tree (which you say you’ve not noticed, which is a really good thing. Perhaps we’re just too sensitive to that
, or perhaps some features we can’t implement because it would take too much work to make with the tree in the time we have, etc. One option with the menu is to replicate the structure of the tree in a menu. The menu will be much lighter weight on the page, so rerendering it won’t be nearly as costly. The option we’re looking at most seriously, though, is grouping the menu commands by actions (deploy, configure, monitor, etc) rather than by objects ([enterprise|web] application, connection pools, JMS destinations, etc) like the tree is now. Hopefully, we can get a prototype up soon so people can poke at it and give us some feedback as early in the process as possible.
December 23rd, 2008 | #
Dan, with regard to windows, to more I think about, the more I’m inclined to agree with you. From a development perspective, it would certainly make things easier, and removing the need for “window” controls, the dock bar, etc. we gain a little more screen real estate. I’m obviously just one man on the team, but I’ll mention your comment to the others and see what they think.
December 23rd, 2008 | #
I agree that Paul’s idea is very good. I visited a large Sun customer last week, and one thing they like about WebLogic is the ability to point and click through the admin console, and it will build a script as-you-go which can later be replayed (automated via CLI). Veritas Volume Manager+filesystem GUI had a similar feature (may still have). While I don’t want to feature-creep, if we want to have the smarts of putting asadmin commands next to a task, then aggregating them into a command file doesn’t sound too hard. Then again, I’m not the one writing the code having to catch all the edge cases
As you mention, food for thought as you refactor the GUI, but not a requirement for this release.
Also, the comments on this post and the other make me nervous about too radical a change (and moving to a menu system would be radical for many users). We will really need some kind of screencast or hands-on mock-up that folks can try. I wonder if we can have the tree and the menu for v3, and move to menu in v4?
If you haven’t already done this, send a post to the GlassFish User’s alias linking to these blog entries.
Anyway, good thread.
December 23rd, 2008 | #
FWIW, I’m not a fan of overlapping windows for these things because of the cost of managing them manually. Tiles, or tabs, or wizards, seem better solutions for these focused tasks. It does seem like very little time to do a change of this sort before J1… – eduard/o
January 17th, 2009 | #
Eduardo,
I think I’m with you on that. The more I’ve thought about it, the less I like the windowed approach. I’m going to send an email to… somewhere (admin@?) suggesting we skip that. Thanks for the feedback.
January 20th, 2009 | #
I think you should use as much screen real estate as possible. Thus in the example presented I would suggest to reduce the white areas and to allow the user to quickly click away (or hide) unnecessary areas. Maybe like in Netbeans where windows can have a fixed area or be minimized to the side of the screen.
About datasources and pools (and things like this): I am not so fond of multiple windows – especially if one must scroll in each of these. But it should be possible to switch easily from one task to the other without loosing any information entered in the other window. Say I have to choose a connection pool to create a datasource and I realize that I’ve forgotten to create the pool. Now it would be nice to quickly create a connection pool and afterwards automatically get to the datasource creation wizard again. This would fit nicely to the action oriented approach you have mentioned. BTW: The action-oriented approach sounds like a very good idea to me.
Th Mac OS X dock bar on the other hand. Well it depends what it is used for. But I would be very careful with this. If there is no very good reason for using it – leave it. It is not about eye candy but about ease of use. In an operating system the dock seems to be a good idea – but what is it used for: To start commonly used apps, to show which apps are in use at the moment and sometimes to display some information about these apps or what these apps stand for – like the number of new mails or the current date and the like. I do not see anything resembling this kind of use for an app server. Action-oriented forms in itself? I cannot see it. But maybe it is only my lack of imagination
But if anything like this is coming and assuming that you want to use either a Windows-like task bar or a Mac OS X-like dock, I would go for the dock!
Despite of these remarks I like most of the proposed changes. Especially getting rid of the frames and the possibility of reduced response times by getting rid of the tree (even though I liked the tree).
January 21st, 2009 | #
Wolfram,
Thanks for the feedback. Things are still in flux at this point, so we’ll have to wait and see what makes the final cut. Most of the feedback we’ve gotten has been with regard to the windowed approach, but we’ve actually started getting some lamentations with regard to the death of the tree. Personally, I have nothing against it, but it has some technical issues we’d like to avoid, and certainly some performance issues. Maybe we can fix both of those with removing the tree. We’re still working through issues like that.
January 21st, 2009 | #
Wolfram, wrt screen real estate, it was our intention to make the windows expandable to use the full screen (bigger than before b/c there would be no tree in the way). We’re now considering making that the only mode instead of allowing parallel tasks to be performed (via multiple windows). We’re still exploring…
wrt the “dock”, the idea was to provide a quick-launch bar for frequent tasks. This would be customizable so that you can add your own favorite things. Also, if we did go with a multiple-concurrent task approach in this release (or the next), the dock would contain icons for the current tasks. Monitoring widgets, or other gadgets would also be possible via our extension API… although we weren’t focusing on this as a primary motivation for a dock. Not sure if any of the above reasons justify adding the dock or not… which is where we welcome your opinions!
To clarify “tree performance” problem, the performance problem is during the initial page load after logging in. We then keep the same tree visible until you logout or close the browser. We update this tree via fast Ajax calls when new instances or other objects are added. So after the initial rendering of the tree, there really is NOT a performance problem (in fact it is very fast client-side tree). However, if we do away with frames, we will be faced with redrawing the tree on every page request — this will be a performance problem. We might be able to do some things to optimize or even fix it, but it will be a big challenge at the very least.
The feedback everyone has given is great! Keep it coming! I hope we can have a runnable prototype very soon so more detailed feedback can be gathered from all of you.
Thanks! Ken
January 22nd, 2009 | #
For the app server to compete with other major vendors, some fundamental changes are needed. A dashboard for determining the health of the application servers and clusters is mandatory. The tree concept is a waste of space for this. The entire deployment process needs to be re-architected. Side by side versions of applications, deploying to an instance in a cluster, moving an instance in and out of a cluster for maintenance and/or configuration changes would make life cycle management a bit easier. The ability of captuing configuration changes and applying all at once, instead of screen by screen. Actually display error messages on the screen instead of in the server.log when a configuration is set incorrectly (eg redirect_n for a listener). Separate CLI authentication and web interface authentication and allow the authentication to use LDAP. This then allows the admin console to conform with most corporate security requirements. Its a stretch for the admin console, but not being able to force an instance to stop/start is annoying. Having to access a host to use kill to shutdown an instance is a night mare (prod we have 50+ app servers).
I’ll be interested in seeing whether the interface is evolutionary or revolutionary. There is a huge opportunity to improve the interface greatly. In saying that, we use N1 SPS for provisioning and managing the app server instances. As long as any functional improvements are included in the CLI, then I’ll be happier.
February 10th, 2009 | #