The Aperi GUI Roadmap
Whither Goest Thou, O GUI?
Wherever Consoles Go the Aperi GUI Should Follow
There has always been a lot of interest in creating integrated, extensible administrative consoles for the presentation of status and launching control functions on managed devices. The idea is that unification can foster a consistent user experience as well as make life simpler for developers and deployers of administrative tools. The battlefield of system administration is littered with the corpses (and some zombies!) of attempts to create such consoles.
It seems unlikely that Aperi will be able to develop the current UI into a definitive administrative console on its own that will attract many contributors given the robust competition. Also, Aperi doesn't really want to be in the console business. We want to be in the storage administration business. We do want to provide appropriate and innovative UIs to our functionality, but we would be very happy to place those UIs into a nice safe framework provided by someone who really cares and has put a lot of thought into it (for recent work see COSMOS http://www.eclipse.org/proposals/cosmos/).
The question then is which console do you integrate with, and/or what UI framework do you use?  The very best result would be an implementation that used a very widely adopted technology to allow the greatest flexibility.
The Technology Arc of Administrative Tooling
I assert (without proof) that the direction of administrative tooling in the enterprise is clearly towards thin client web based solutions. The only thing preventing complete adoption has been the perceived need for fat client style interactions in graphically intensive applications such as topology exploration and interactive report construction and viewing. Recent, but widely adopted, advances in web application construction may have circumvented this issue making it feasible to consider web based solutions for a wider set of applications.
The Technology Arc of Web Applications
Several new web application technologies have emerged in recent years and are becoming widely adopted. Of particular interest are AJAX and JSR 168 solutions used alone, or in combination including JavaScript libraries and toolkits, such as the Dojo Toolkit, the Yahoo! UI Library, the Google Web Toolkit, Script.aculo.us, and DHTML Goodies. New standards bodies have emerged like Open AJAX and the Dojo Foundation. Many existing and proposed frameworks and applications based on these technologies are appearing everyday. Some of these applications are cutting deeply into the traditional fat client territory with graphically and data intensive application with zero install footprint.
The Technology Arc of the Aperi GUI
Step 1: Swing (V0.1/V0.2)-> Hybrid RCP SWT/Swing (V0.3)
Historically, Aperi has presented a one-off standalone console that could not be easily integrated with any other console. The majority of functionality is still implemented in Java/Swing with all new functionality implemented in Eclipse RCP (SWT/JFace). Eclipse RCP provides an extensible application framework with lots of great features, but isn't, of course, a console in and of itself.
Step 2: Hybrid RCP/Swing (V0.3) -> ?????where????? (V0.4 and beyond)
There are several issues at work:
1.	We would really like to redesign and reimplement the Aperi UI to better address the problem space of storage management as we see it now, as well as to better conform with modern design practices and take advantage of modern implementation techniques.
2.	We would like to be able to integrate the functionality of the Aperi UI into one or more standardized and widely used consoles rather than roll our own.
3.	Given my assertions about the direction of web based administrative tooling and the availability of new technologies we should be considering a web based solution.
The Plan from Here
It is probably too risky a proposition to consider abandoning the current fat client GUI and going whole hog for a web based solution, or any other solution for that matter, in the 07/08 timeframe. The legacy GUI, for what ever its perceived faults may be, is working as is and would take many man years to redesign and reimplement, and before we bet the farm on any new technologies some judicious prototypes should be constructed and evaluated.
So, what I am proposing is a multi pronged approach with staged introduction:
1.	Begin a top down, user centric redesign of the Aperi UI in technology independent terms (think task and/or goal oriented with neutral UI elements). This effort should result in a high level UI specification and fairly complete set of mock ups for demo purposes.
2.	Commission a series of prototypes that implement a vertical slice of functionality in what seem like the most likely UI technologies, so we can understand both the feasibility of the technologies as well as be better able to estimate the implementation effort for the design from prong 1 above.
3.	Search for and select some likely administrative console solutions that allow integration in terms of the technologies in question.
Obviously, in all technology considerations we are constrained to only consider those technologies available as open source under acceptable license terms.
As we converge on the new UI design and technology solution we can begin a staged introduction of functionality in the new framework. The functionality would appear along side of (in addition to) the legacy UI until such time as we had implemented enough function in the new framework to abandon the old. Obvious early deliverables would be: Report Viewing, Health Console, maybe some control functions (wizards).