Compellingly Beautiful Software
Products Programming Contact
Let's boil it down to essentials:
Very Rapid UI Development
Ease of Integration
Self-Assembling UIs
Reading feature checklists tells you something about a product, but to see how it works in practice, you might need other kinds of information. Here are some realistic scenarios that will help you understand what Slamdunk can do for you.
Or contact us to learn more.
John is responsible for three different inventory control applications for his employer's three divisions. The general form of these applications are all the same, but they each have a few distintive features, and of course the products in each inventory are completely different.
Even before he started building with Slamdunk, John had a base class for all of his applications, and subclasses for each of them, but now they are easier to maintain. Because a Slamdunk UI is based on a formal design pattern, he knows for certain where his maintenance changes will take effect, and what effect they will have. Glue logic has virtually disappeared from his code. Adding a new inventory item means deploying a domain model for that item, along with its Slamdunk UI description. His Slamdunk applications already know how to integrate the UIs for new models they have never seen before. Many specific parts of the UI are derived automatically from information implicit in the application, so John doesn't have to code them. The right components appear, and they just work.
Susan has been given an impossible task: build an application in which users don't just access, but interact with databases from vendors and consumers several layers up and down her company's supply chain. The managerial roadblocks have already been cleared, but when she talks to the IT departments of these other companies, they all say "Sure, we'll let you work with our data in our applications." What Susan needs, however, is something different: she needs to work with their data in her applications.
With Slamdunk, Susan's task is not impossible at all.
Along with access rights and schemas for these foreign databases, she obtains the domain models and Slamdunk UI descriptions for the data they contain. Most of the domain models come to her as Slamdunk descriptions that parallel the schemas; only a few are actually coded in Java. Because Slamdunk APIs are completely uniform, she doesn't worry about the UI coding practices of developers she does not know. Hardly any of the actual UI code is written in Java anyway: Slamdunk creates her components from abstract descriptions. Most of her efforts go into designing sensible transactions and interactions with this foreign data. When she needs a panel or dialog to display this data, the right one appears because the data needs it, not because she wrote a lot of UI control code. She spends no time at all replicating UIs that already exist elsewhere.
When her collaborators' databases change or their UIs are updated, most of Susan's maintenance work consists of replacing files in a directory. Changes unrelated to the functionality Susan actually uses have little or no effect on her code. Susan heard a long time ago that object-oriented programming was supposed to work like this. Finally, with Slamdunk, it really does.
Of course, this assumes that everyone in Susan's supply chain is already using Slamdunk. If a really tight supply chain is a part of your corporate vision, we can help you see it in reality.
Karnak Instruments designs exotic tools for manufacturing processes. Some of their user interfaces are very complex, so they adopted Slamdunk as their UI paradigm. They found it quite easy to incorporate their proprietary graphing component that helps them differentiate their products.
Karnak now produces five different instruments. Many of their customers own all of them, and are asking for an integrated control panel application that allows them to work with any of them, or even several at once, from a remote location.
Karnak's engineering team decides on their approach for remote control. A brising.com engineer helps by providing some objects that are not really a part of the Slamdunk library, but that are very useful and available to customers. Remote control is demonstrated for all instruments a few days later.
From the time remote control is demonstrated until the time the integrated control panel application is ready to ship is less than an hour. It would have taken less time, but the engineer stopped for coffee.
Yokohama Molecular Ltd., which sells semiconductor factory equipment, has noticed that many of its customers own Karnak products, and that they're very good. YML would like to attach these instruments to its large machines and integrate parts of Karnak's UIs into its own. A YML executive calls Karnak's CEO, and they agree to do this. Because YML also uses Slamdunk, it can use Karnak's UI descriptions, with only minimal changes to match YML's style. Karnak's UIs now appear with Japanese labels for Japanese users: only a translation file was needed to accomplish that. YML releases new software before the next big trade show, and both companies' sales take off.
Contact us to learn more.
© 2004 brising.com