Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Dave West on Jun 25, 2010
The iPhone4G loses reception if users hold the phone at its lower left corner. A problem solved, according to Steve Jobs, by "don't hold it that way;" or by using an iPhone case accessory. This is a trivial problem, but it raises again the issue of an increasing gap between technology and the interfaces necessary to use that technology. Not yet reported, but easy to anticipate, the higher resolution of the iPhone4 allows smaller controls to be packed closer together, creating huge problems if you have large fingers.
Hardware engineers continue to pack more processing power into smaller devices but the real barrier to increasing miniaturization arises from human abilities to interact with them. The mobile phone is where this conflict is most obvious. As Patrick Baudisch of Hasso Plattner Institute (and formerly at Microsoft Research) noted earlier this year:
There is a single true computation platform for the masses today. It is not the PC and not One Laptop Per Child. It is the mobile phone - by orders of magnitude. This is the exciting and promising reality we need to design for.
Interface problems include more than large fingers and skin conductance interfering with an antenna; you cannot use skills, like touch typing, on a phone, touch control is far less precise than even a mouse cursor, and you cannot use available interfaces in certain contexts (like touching while driving).
Some problems and potential solutions: (excerpted from Communications of the ACM, Feb. 2010)
In the future, the interface might be disassociated from the device entirely and moved into our bodies. Visual displays incorporated into the retina of our eyes, direct conductance "speakers" implanted in our ears, and haptic sensors incorporated into our fingertips.
Ultimately, the 'impedance mismatch' problem between our technology interfaces and human users will be decided more by the users than the technologists. Just as a new 'language' was invented to circumvent the limitation imposed of a phone number/letter pad (e.g. "c u l8tr"), users will find a way. It would benefit technologists to take into account the ingenuity of users and the affects of culture and everyday experience as both a constraint and an inspiration for design. It is inconceivable that in all the months leading to the release of the iPhone4G that none of the engineers ever held the phone at the lower left corner and experienced the loss of signal being reported by users. It is equally inconceivable that Apple engineers and designers did not expect that holding the phone in such a manner would not be a common experience among users. And yet - by virtue of the fact that this was not addressed in the antenna design - it appears that the inconceivable did in fact occur.
Requirements, quality and test management e-Kit
The WebSphere Liberty Profile for Developers: An Introduction
Introduction to WebSphere Liberty Profile
Want to know how software releases can be stress-free and happen with one click? Try Go free!
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Go: Agile Release Management Solutions. Go enables predictable, defect-free and timely software releases.
It's perhaps surprising this issue wasn't caught, but certainly not inconceivable. As someone once told me, the real testers are your regular users, not system testers, or acceptance testers. I was given an app and told it was ready for production. Fortunately we deployed it on a "test" production server, a soft launch. A user kicked the tires and said there was an extra tab when she moved through the form. The system tester had seen this, but used the mouse mostly, and never reported it. But when you are processing 100s of forms per day, you don't use a mouse since it's too slow, and an extra tab will slow you down or throw you off immensely.
I agree they should have spent more time with different test scenarios such as "does antenna work when I hold it in top right corner? top left?" etc, given that this was a new change. But you also have to understand the heightened development pace in getting a major piece of hardware and software out like this, in comparison, it would seem this is a minor issue given some of the considerable issues with other mobile devices, showstopper issues such as battery issues, etc.
Further, one of the advantages of a design like the iphone is that the interface is that there is that much less "impedance mismatch" than other interfaces, like mouse or ball driven ones on the blackberry. Waving your finger is much more natural, so I mostly disagree with this article. For example, one of the main examples, the smaller keyboard supported, is almost a non-issue due to the iPhone design. On a blackberry, you have tiny buttons, that seems problematic. On the iPhone, developers are free to make the buttons any size, or design an entirely new interface, since these are software buttons. There is no limit.
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
1 comment
Watch Thread Reply