From the overview:
In the Eclipse Platform a Perspective determines the visible actions and views within a window. Perspectives also go well beyond this by providing mechanisms for task oriented interaction with resources in the Eclipse Platform, multi-tasking and information filtering. In this article the concepts behind perspectives are examined. The process for perspective definition, extension and instantiation will also be covered in detail with coding examples and sample scenarios.
A perspective is a visual container for a set of views and editors (parts). These parts exist wholly within the perspective and are not shared. A perspective is also like a page within a book. It exists within a window along with any number of other perspectives and, like a page within a book, only one perspective is visible at any time.
When I first looked at this it seemed very attractive and I thought it had the potential to solve some of my then client's issues surrounding "beginner" screens and "expert" screens.
My second thought was that this might provide a way to iterate the UI. The concept of iteratively developing a user interface has been the subject of much discussion on the XP list and has it's own mailing list.
One of the biggest issues of concern is UI churn if you have a fairly rapid release cycle. It seems that perspectives could alleviate this churn by adding new perspectives that support the new features of the release and only change or remove the pre-existing perspectives when absolutely necessary. Of course this introduces some other problems such as informing existing users about the new perspectives and how to start using them, but it seems manageable.
From the technical side my biggest concern is since perspectives are not aked into any UI framework that I'm aware of (besides Eclipse) my team would have to build the plumbing. Iterating into a perspectives framework could be challenging and selling the value to the product owner might take some doing.
Anyone out there doing something like this?