Modes are bad. Therefore LeapMode is good. Customization is bad. Therefore allow no customization whatsoever. Icons are bad. Therefore, stick to text. Zooming Interface: ZoomingInterfaceParadigm (ZIP is something to replace applications, desktop, browsers, etc. All of the content is displayed on an infinite virtual plane. As you zoom closer, documents can be edited. Filesystems are bad. Instead, just provide an interface where the user can type text. If not the zooming interface, then perhaps the old CanonCat interface — one huge text with document separation characters. If it is easy to select text and print it — i.e. it is easy to mark the text between two document markers — then files are not useful.
Probably the most important thing to notice about this style is that the intent is to do something along the lines of an internal DomainSpecificLanguage. Indeed this is why we chose the term 'fluent' to describe it, in many ways the two terms are synonyms. The API is primarily designed to be readable and to flow. The price of this fluency is more effort, both in thinking and in the API construction itself. The simple API of constructor, setter, and addition methods is much easier to write. Coming up with a nice fluent API requires a good bit of thought. Indeed one of the problems of this little example is that I just knocked it up in a Calgary coffee shop over breakfast. Good fluent APIs take a while to build. If you want a much more thought out example of a fluent API take a look at JMock. JMock, like any mocking library, needs to create complex specifications of behavior. There have been many mocking libraries built over the last few years, JMock's contains a very nice fluent API