Modules of an iPhone
An iphone7, in a size of 138.3mm*67.1mm*7.1mm and weight of 138 grams, is portable while having a complex structure with no less than a hundred tiny items under its cover enabling it to handle difficult tasks.
At the first glance, it may seem difficult and even impossible for such a small device to operate so many parts at the same time. But Lidwell and Butler provide us with a good point to deal with this problem. They said that grouping elements can help us reduce the number of distinct elements thus make a complex system simpler, which is in other words, to get it modularized.
Baldwin gave us two subsidiary ideas about modularity:
- interdependence within and independence across modules
- abstraction, information hiding and interface
Actually, we can divide the hardware of an iPhone into modules like logic board, PCB diagram and so on, which are independent from each other. In this procedure, we need first narrow the number of the interactive points between the logic board and PCB diagram, abstracting complexity into simple modules. Then define the visible and invisible parameters of the architect and hide information inside of a module to form a complete modularity system. This time, the designer of logic board can just focus this item, free from worrying about PCB diagram. And in fact, he will barely know anything about what a designer in charge of PCB diagram is doing, as parameters for PCB diagram can only be accessed by PCB diagram designer to reduce unnecessary communications and simplify the whole process.
From the prospective of a user, when the logic board broken down, he can just check the board to see what’s going wrong and perhaps finally replace it with another one instead of a whole new iPhone.
By discussing the how to truly hiding information, we come to the form of design hierarchy which can make the relationship between visible and invisible parameters clearer.
(photo: Design Rules, Vol 1: The Power of Modularity)
This reminds me of the operation of a company, an ideal example for us to understand the principle of “the design hierarchy”. In a company, the president sets up a series of rules for all the employees. These rules is just like the “Global Design Rules” in “the design hierarchy” which should be not only known by the employees(“A-B Interface”, “C-D Interface”, “Module B” and “Module D”) but also obeyed and sometimes , new employees may have examinations to see how well they know about the rules. In this way, all the employees know the company’s rules well. Sometimes, the company may face a shortage in staffs thus hire some casual laborers and interns. In this case, these casual laborers and interns play a role as “Module A and D”. As they don’t have a long-term contact with the company, there’s no compulsory request for them to learn the specific rules of the company (although they may know a part of the rules like the working hours and how will they be paid from their team leaders or department managers). Everyday intermediate managers get directions from the president and allocate works to their subordinates and employees from different team or department are unlikely to know each other, let alone the works he/she is doing. In a well-managed company, the president do not need to spend his precious time on each employees, but an intermediate manager should ensure his subordinates know well of his orders.
Sadly, after reading so many materials, I’m still a bit confused about the concept of “interfere”. As Baldwin mentioned in Design Rules 1: the Power of Modularity, “An interface is a preestablished way to resolve potential conflicts between interacting parts of a design,” interface is visible for all designers involved.
Actually, the interface I’m most familiar with is “the users interface”. Take Wangyiyun Music, a music broadcasting app, as an example.
The designer has hidden nearly all the parameters from users and the only way for users to interact with Wangyiyun Music is through interface. The interface is like a entrance for users to get contact with the app, give it commands and get feedback; however, it also function as a window, too small for users to see how the staffs behind it works. In fact, considering the limit of one’s energy and time, users won’t bother to know how an app works, let alone the parameters and codes.
But if we look interface from the view of a designer, I wonder whether there’s a “designer interface” for designers; and if it does exist, is it look the same as user interface?
Richard N. Longlois. (2002). Modularity in Tech and Organization. Journal of Economic Behavior & Organization.
Baldwin, C. Y., & Clark, K. B. (2000). Design Rules, Vol 1: The Power of Modularity. The MIT Press.