|
Suppose you were starting with a clean slate, infinite amounts of money and the best brains in the universe. How would you design the user interface for building systems from parts? That is the objective of the second Bean Assembler workshop. |
Overview
For an introduction to what we are trying to build, see User Requirements Vision.
We're being very focused here, because the UI will make or break the BA's usefulness to do something that has not been achieved before - Allowing users and developers to assemble any system from parts. We are going beyond the current crop of IDEs, which force one to indulge in massive amounts of code if you venture beyond traditional database apps and applets.
The first iteration of the BA allows one to compose systems from parts, but all parameter edits are manual, and it is only a little more (about double) productive than code. It also cannot be done by a non-programmer. This is all very limiting. What we need is a better interface that shields the user from any hand editing and makes the whole process super simple, as easy as writing a letter to your Mom.
We see this topic as large, crucial and fun, so we are going for a serious 2 day workshop, in Atlanta, probably in late January. Dates are not yet set. Email this list with your preference for a weekend or a Friday/Saturday, and what your conflicts are.
To keep the quality high, this is an invitation only workshop. If you have not already been invited and want to participate, send this list a summary of what you can bring to the table and what you would like to do with the BA. If it's at all impressive, you're in. We're not an exclusive club - we just want serious problem solvers and not too many people. We will be limiting the group to 20, aka the small sharp team concept. Invited so far are Paul Reavis and company, some of the staff at Realm, Jack Bolles, Greg Kreis and Jack Harich.
To get results, we are requiring all those attending to have worked on their UI designs for a minimum of several days, and to present their ideas and UI at the workshop. Note you need not design the whole thing, just make a solid contribution in some area. The agenda is the first day for UI presentations, discussion and joint design, and the second day for decisions and voluntary assignments. This will allow many of us to move right into jointly producing the second generation of the BA.
Details
REALM Information Technologies in Atlanta has started to use the BA in its product, has registered jcon.org, has set up a site for it, is handling central internet source code management, is being very supportive, and wants me to continue to help them in product development. Paul Reavis at Pioneer Software in Athens wants to use the BA in the next generation of his product, and wants me to spend some time with them in design and issues. The JCON reusables are being reused and are moving to the open source model. Things are on a roll... Interestingly, both Realm and Pioneer are Linux shops, though the product usually runs on Windows. We are timing this workshop to suit the schedules of Pioneer and REALM, since both need the BA to improve and see the strong benefits of its underlying abstractions.
Jack Bolles has agreed to do some serious advance work and conceptually lead the UI design effort. Those of you who have attempted to design a product with functionality not found on the market will appreciate how tough this task is. Jack was a graphics designer before moving into development via Java. He will be coming down from Chicago for the event, and leaving the snow behind. :-)
As Jack Bolles puts it, "We will create a user-interaction concept coupled with general presentation guidelines" at this workshop. The goal is to decide on a high level UI design, so we can then start building it. We should bring not only our designs, but the requirements they are meeting, such as traits, use cases and risks. There is no need to bring a polished looking prototype.
Jack Harich will be working on a key feature, infinite extensibility. The idea here is to keep the BA System Engine very small and microkernel like, and allow unlimited amouts of add ons and customization. This can be achieved by using interfaces on all engine classes (to allow replacement) and providing hooks (such as events and properties) for additional functionality. This will require an engine rewrite, and must be done to support the new UI and associated concepts.
Paul Reavis and compatriots will be tackling an as yet unassigned area. Paul is currently on a 2 week vacation, cut off completely from the mundane world of email. For those of you unfamiliar with Paul's work, he has more experience with parameter driven apps and how to put 200,000 gif files on a ruggedized laptop than anyone I know of.
Greg Kreis has taken on the role of Creative Fomenter. ;-) He has provided the definition right here: Foment - transative verb - circa 1613 : to promote the growth or development of : ROUSE, INCITE. For those who don't know Greg, he had the original idea to start the JSL SIG, the list, and is the list maintainer. He's a rather creative mover and shaker....
The BA System Engine is a lightweight, application neutral framework suitable for microkernel use, such as the foundational layer for a Layered Architecture system design. It provides absolutely no application specific behavior. It doesn't even know the awt, databases or domains exist. It's small, with about 10 core classes, 10 core interfaces, and another 20 utility classes, plus some classes for providing parameters from text files or other sources. All it does is allow one to arrange reusable classes in a system hierarchy, set relationships, and configure the reusables. At run-time it starts the system root container, handles object creation, configuration and inter-object events, and automatically starts other containers when they receive an event. This is about 1% of a system's functionality, but tends to take about 25% of the code.
Domain frameworks are built on top of the BA, such as the Data Framework in the JCON reusables. Applications are built on top of domain frameworks or directly on the BA. The domain frameworks and applications are edited using the BA Editor and BA System Engine. Running an app requires only the System Engine.
The BA Editor is what we are designing. This lets the user reuse parts and edit the parameters that drive those parts and containers. It's also called the Param Editor, since that's all it does. There is no coding. If behavior cannot be expressed by parameter edits, the part needs to be redesigned or a new one created. Of course there will be lots of this at first. The Param Editor plays a crucial role in the software development process, as shown in the model for Change Process and System Architecture. The Param Editor is the tool that allows the user to easily change the system to suit their needs, so the BA is a solution to HyperChange.
Currently we edit nested text parameters using our own format. This needs to change to XML. We also need to have param types for each parameter container, a visual tree to edit them, and the ability to pick and choose container members, with validation and defaults. All this will allow easily and quickly editing parameters. This is a tough area.
This whole affair and the JCON resuables are part of the Atlanta Java Consortium concept. This is a small group of Java developers banding together to help themselves in a variety of areas, including fun, intellectual stimulation, networking and reusables. JCON stands for Java Consortium.
Inspiration
Once you've studied the current concept and interface of the BA, throw that interface away. Think new, creatively and pro-user. What is your dream interface?
Jeff Hawkins, designer of the breakthrough Palm Pilot, has this to say about UI design. As we all know, the Palm Pilot has succeeded because of it's extraordinary novel design, ease of use, power and reliability. It's Windows CE competition has failed to come close. This is an incredible product. A quote from the article:
| "At a time when PCs and software were steadily becoming more complex, the PalmPilot turned the model on its head by limiting itself to a few functions, which it did very well." |
Lego has released Mindstorms, a really cool kit for designing and building small robots. The UI allows you to drag and drop to program, and was codesigned with MIT's media lab. Rather sophisticated robots can be created, such as one that can copy an entire black and white page using a light sensor, motors and ink pen. It's designed for kids 11 and older, but AFAIK most buyers are adults. Hmmmm. (Couldn't find a good screen shot of the UI, anyone have a URL?) We have this quote from the site:
| The LEGO Group is committed to the development of children's creative and imaginative abilities, and its employees are guided by the motto adopted in the 1930s by the founder Ole Kirk Christiansen: "Only the best is good enough." |
Here's a Mindstorms review. Half way down the page is a too small UI shot. And here's the MIT Programmable Brick. It has a UI, but it's not on a screen. The brick is a physical part.
Sooner or later this was bound to happen - A Computer User's Manifesto.
If anyone has more inspirational UI URLs, let us know....
BA Key Features
(in approximate order of importance)
User Interface
Lets users or developers assemble systems of any kind from reusable parts.
Ultra easy to use, like Palm Pilot.
No design and runtime dichotomy. Editing a running system is normal development.
No code, parameters only. We use Declarative Knowledge to separate what from
how.
No freeform edits, all is look and choose, validated.
No training required to learn and use. No manual needed by 90% of users.
Can record Inspector method calls to program a part while system is running.
(1)
Tool reuse, such as part trees are for systems, libraries, storage, notes,
etc. (2)
UI conforms to user's needs, skills. (perhaps in later versions)
Other
Infinitely extendable microkernel. (Let's do this for the UI engine also.)
Application neutral, a good microkernel.
Parts have no required interfaces, but many optional interfaces.
Anonymous Collaboration
with a single general purpose event, a Message.
(1) This may ultimately be seen as the coolest BA feature. Here's how it works: Open the Inspector, which shows all the Messages, Properties and Methods for a part. Click on the Methods tab. Invoke a method by selecting it, entering or pasting arguments (if any) and double clicking on the method, which is invoked on the running system. At the same time the invocation is optionally recorded. Invocations can be deleted, edited and rearranged. This allows one to "configure" a reusable part with the equalivent of lines of code. The best thing is this all happens in real time. The entire system is WYSIWYG. Should we call this "invocationing" ? Click and code? Codeless coding? :-)
The again, this may actually be the worst feature we could provide, because it just encourages the procedural approach, with all the unencapsulated dependencies, bugs and incomprehensible reasoning of raw code. Telling a system exactly how to do something is working at a low level of abstraction. A better way for the user to express intent is Declarative Knowledge via parameters, where we tell the system what to do, at a higher level of abstraction. Hide all that code inside of reusable parts.
The status on this feature is incomplete. The Configurator is read only and does not yet record invocations. The rest is there. A container can play invocations. The Inspector can do invocations, but last time I tried it was broken, probably due to Swing mods. The Inspector even supports pasting parts and properties. There is lots of flexibility. The goal is to record invocations as fast as you can decide what you want the parts to do. This, as I see it, is one way "programming" of the future will be done. Another, as we have mentioned, is the use of Declarative Knowledge.
(2) Usability may be helped by giving all the tools (and basic parts?) friendly names....
Here's a document in progress, on Basic Parts. It also contains a list of Use Cases that may help in UI design. But beware - these are just one person's perspective. I need to put these Use Cases in a separate requirements document, but wanted to get this all out now.