I was sitting beside an American Airlines pilot on a recent flight from Minneapolis to Chicago. He asked what I did and I replied my standard “I work for IBM as a software developer”. He replied that he had a computer at home but that he rarely used it because he wasn’t good with computers.
Ummm, don’t you fly an airplane, and isn’t and airplane one of the most sophisticated computers there is? (Anyone else here worried or is it just me?) Of course, he just didn’t think of the airplane as a “computer” since the computer is embedded within the overall system. The complex computer system inside the airplane was hidden by a much simpler user interface. I’m not suggesting that flying an airplane is easy or that the controls for an airplane are easy to learn. But for this trained pilot, flying the airplane seemed easier than using his home computer.
The same could be said for an iPod or today’s automobiles. Both have sophisticated computer systems inside that are hidden by a much simpler user interface. I firmly believe that hiding, or even getting rid of the user interface, is a great way to reduce the complexity of our software applications. This is one of the reasons why I’m a big believer in Web Services – having the computer systems talk to each other instead of having people in between. Or using scanners and RFID to input information instead of manually entering it.
At the same time I’ve always held the opinion that this doesn’t apply to me since I’m writing application development tools that are targeted to computer programmers. However, I’m finding it harder and harder to convince myself of this. Why shouldn’t we strive to create development tools that have just as much functionality but with as little “complexity” as possible. It’s a lofty goal but not an easy task. First we would need a good definition of “complexity” and I’m not about to tackle that in this posting.
One area where this often comes up is with preferences pages (it came up earlier today as I was working through some new features for the RSE). When designing new functions there are times when something could be done two or more different ways. Often the result is to add a new preference and allow the user to choose. At first glance this appears to be a good thing since it provides the users with additional flexibility. However, flexibility usually adds complexity.
Instead of adding a new preference, perhaps the design needs to be reworked to come up with a better solution that doesn’t require additional preferences. This is not an easy thing to do and can take considerably more time than the original design did, but in the end everyone benefits.
As for my airplane ride, we were just about to take off from Minneapolis and the pilot (the one flying the plane) came on the radio and said we couldn’t take off because the radar was down in Chicago. He didn’t say why, but I’m sure adding a new user interface option wouldn’t have helped :)
As I awoke this morning, I cast my gaze onto a set of pleated curtains and came to realize that I was looking at an array of pleats. As an array is a programming concept, I started pondering why our children are not given lessons about stacks, queues, lists, and hierarchical trees, how to recognize them in the world that surrounds them, and how to use them to organize their lives. Are these not as important as the different types of simple machines, such as levers, wheels, axles, and pulleys? And if our children are aware of these concepts, wouldn’t they expect to find them in a programming language?
Read the rest of this entry »
The other day while watching a Mac versus PC advertisement, I was reminded of other historical comparisons such as Betamax versus VHS and OS/2 versus Windows. Today we have their equivalents such as PS3 versus XBox, Blue-ray versus HD DVD, and the list goes on. For each technology or product, its success depends on the growth of an ecosystem and an entire industry built around a set of supporting products. One only has to look at the phenomenal number of accessories that have been created for the iPod. Whenever a person chooses one product over another, that person buys into a particular ecosystem and is limited to purchasing items that are compatible with it. Therefore the availability, cost and potential value of a system is weighed against those of other systems. So what about the System i and RPG?
Read the rest of this entry »
Hi, my name is Edmund Reinhardt and I live with my wife and four kids in two wooded acres on the Niagara Escarpment.
Unlike some of my co-workers, my history does not go back as far as hardware design, but my grade 10 data processing course did use punch cards.
While at the University of Toronto, I hung out at the Human Computer Interface and Graphics Lab. I will concede that one motivation was the better hardware. In the beginning this consisted of 80 line terminals versus the regular 40 line ones, but by 1987 this included Sun workstations. But another part of my motivation was that I am interested in human beings as well as computers . The interface between computers and humans seems to be where the interesting problems are (as well as the cool graphics). At university I spent time browsing the internet which in those days consisted mainly of ftp. Someone was compiling a document listing all of the services available on the internet and I remembered painstakingly printing out the pages of information and putting them into a binder. We sure have come a long way since those days :-)
I started with IBM in June 1989 and I have been working on one form or other of DDS tooling ever since. I started with SDA on the green screen and then went on to DSU on OS/2. I ported that to the 32-bit OS/2 API and then led a team to rewrite it for Windows. That is how CODE Designer for CODE/400 came about. I worked on WebFacing from almost the beginning. I led a small team in writing the initial middle tier runtime as well as the conversion from DDS to JSF.
I then wrote then DDS object model in Java that is used for WebFacing conversion as well as for the outline view for the JLpex editor. In version 7 this same DDS DOM is used to enable the Screen Designer Technology Preview.
I intend to write posts about WebFacing, DDS tooling in WDSc, the Screen Designer and tips for effective use of the Eclipse platform.
Outside of work I am a lay pastor at a small Anabaptist church and am involved in various ministries. I didn’t realize that Brian Farn was a fellow clarinetist. I guess it just goes to show how useful blogs are for bringing out the truth and connecting people. I look forward to doing a lot more of that in the coming posts.
It is quite often to hear customers complain how complicated it is to use a specific feature or a product in general. I think many factors contribute to this, like:
a). The inherited technical complexity
This happens when problems to be resolved are very complicated. It is not always easy to find a simple and elegant solution. However, how to use a feature and how to implement it are different issues. A complicated implementation can be simple to use if unnecessary complexity is hidden from customers. For example, use intuitive user interface or add intermediate layers to do things underneath etc.
b). Primary use cases not clear
The user cases basically describe how customers interact with the feature. What are the primary user cases ? Who are the target users? Without clearly defined user cases in place, developer may lost focus and put more effort on advanced functions and introduce extra complexity for all customers.
c). ‘Simple’ may have different meaning for different customers
Customers are different with their skills level and background. A simple solution for some customers maybe a complicated one for other. Early UCD evaluation and customer feedback will help to justify and revisit the design.
d). Outside dependencies
Component and Product level dependency may cause significant complexity in installation, setup and integration if the interfaces are not well defined.
“Can you make it simple?” — a good question for myself and it always deserves a good answer.
Well, this is my first post. No picture. No video. Click “Publish” in wordpress dashboard and it goes to Web right away.
Simple enough :)