Robust Design: Sandbox Principle
Before diving deeper into the fault tolerance robust design principle, I will present three other robust design principles. This post will address what I call the Sandbox principle; although, I have heard other people use the term walled garden in a similar fashion.
Sandbox in this context refers to my experience as a parent of small children playing at the park. The park was large and there were plenty of dangers to watch out for (including rattlesnakes), but when the children were playing in the sandbox area, it felt like the urgency of protecting the children eased up a bit. The environment was reasonably well controlled and the sandbox was designed to minimize the types and severity of injuries that could occur while in the sandbox.
Apple products seem to favor the sandbox design principle to great success. For example, the Mac OS’ graphical interface constrains what kind of requests a user can make of the system. You cannot make the system do anything that the graphical interface does not explicitly support; this in turn enables Apple to tout that they are more reliable and stable than Windows systems despite the fact that the Windows system enables users more options in how to specify a task request. In this case, fewer choices contribute to higher reliability.
The iPhone implements constraints that contribute to stability and suggest a bias towards static and deterministic operations. For example, you can only open eight web documents in Safari at a time on a second generation iPhone –as if the web pages are held in fixed, statically allocated buffers. If you never need more than eight web documents open at once, this limit will not affect you except to contribute to more predictable behavior of the overall system. If you need more than eight web pages open at once, you will need to find a work around using bookmarks as temporary page holders.
The iPad does not support Adobe Flash Player. Morgan Adams shares an interesting perspective on why this is so:
“Current Flash sites could never be made work well on any touchscreen device, and this cannot be solved by Apple, Adobe, or magical new hardware. That’s not because of slow mobile performance, battery drain or crashes. It’s because of the hover or mouseover problem.”
This statement and accompanying details supports the sandbox principle of limiting the system options to ensure an optimal experience and reducing the complexity that would be required to handle degraded operating scenarios.
Lastly, Apple’s constraints on how to replace the batteries for the iPhone and iPad minimize the risk of the end user using inappropriate batteries and equipment. This helps control the risk of exploding batteries. The new iPad has a “Not charging” message when the charging source on the USB port is inappropriate. This suggests there is a smart controller in the charging circuit that evaluates the charging source and refuses to route the charge to the battery if it is insufficient (and possibly too fast or high a charge scenario – but I am speculating at this moment). This is a similar approach to how we implemented a battery charger/controller for an aircraft project I worked on. This is yet another example of high reliability techniques finding their way into consumer products.
Do you have any comments on this robust design principle? What are some other examples of products that employ the sandbox design principle?
To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts. I encourage you to read all of the posts for the robust design series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned with regards to robust design practices here. I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to participate in a guest post, please contact me.
Previous post in the Robust Design series:
2010, March 29: Robust Design: Fault Tolerance
2010, March 22: Robust Design: Ambiguity and Uncertainty
2010, March 15: Robust Design: Best Guesses
2010, February 10: Robust Design : Good, Fast, Cheap – pick two
2010, February 4: Robust Design
Dale Shpak commented:
Dale Shpak commented:
William Ketel commented:
William Ketel commented:















