VCL dead, Rad dead (4)

VCL is dead, Rad is dead

-- Topic that is not fully spoken in sd2c

<-- Previous section (insert)

Iv. Post-rad era: the interface is visible and can be described on the Interface
-----
The Rad process is directly related to the theory of rapid prototyping. This process requires users to view a product and try it out early. Connect
User Experience and validation of product prototypes to solidify user needs. This is an effective means to respond to changes in user needs.

The Rad process method has achieved remarkable results over the past 20 years, which is easy to see. If VCL is successful, either party
The reason for this is that it caters to this trend: We can quickly develop the interface to get a prototype that can be confirmed by users.
In my opinion, rapid evolution between components-products is a key factor in this process.

That is to say, developers can continuously develop based on a "componentized interface", such as enterprise business requirements. However
As a result of major changes, our reliance on the componentized interface has become a disaster. This includes two parts:
Changes in the form and technology of the interface. For example, the initial design is similar to componentization and Windows desktop standards.
Quickly changed to a concise, Mac-like interface; for example, the original use of gdi api, and later use of directui and so on.

The traditional approach is to determine the scope of the interface performance based on the development needs-This way the UI engineer is suffering, or it is determined based on the design
Develop and implement the technology-this requires higher development skills. Some of the latest ideas are also the ui I mentioned earlier.
The change is to discard the visual interface and adopt the interface descriptive method. Furthermore, the interface programmable model is used.

The interface's descriptive and programmable features are particularly evident on the web. We use HTML + CSS to describe a web
On the other hand, the interface programming is based on models such as DHTML or standard DOM.
Domain, that is, UED (user experience design ).

I mentioned at the D2 (Designer & developer frontend Technology Forum) Conference that when the interface is separated
The E2 + C2 problem occurs naturally. E2 refers to effect and experience, in which effect is Art
Designed to ensure, while experience is guaranteed by front-end development. Therefore, the experience can be divided into C2, namely, control and internal.
(Context ). The specific manifestation of C2 in the Web is JS and Dom, or as and objects in flash. While C2 acts
The theoretical basis of the program design system is that "Control + content" exactly corresponds to "algorithm + Data Structure ".

We say that the evolution of the "componentized interface" has become "interface descriptive", and that it has produced a new field.
What does it mean? The real problem is that when the application is complex to this scale, front-end and application development are no longer a field or a group.
Team or individual jobs. Furthermore, the current rad tool cannot ensure that multiple fields are under the same tool set.
Local work. You know, the "quick prototype" to achieve a stage goal is now more than a scale of Application Development 20 years ago.
Bigger.

In RAD tools, we cannot quickly complete a prototype product, which needs to be completed by cooperation in multiple fields. This is
It is the real dilemma of rad. We mentioned in the previous section that the UI staff uses Photoshop and the UED staff uses JS, while the developers are using
Delphi or. NET, which is the current situation. The direct problem with this situation is that no rad toolset can ensure everyone is happy.

So now, it is not easy to develop a prototype that satisfies the demand side. However, once we acknowledge that rad
This is not a panacea. if we allow the team to allocate some manpower to face the UI, or use a dedicated UED team to respond to customer needs, then we
We can see a fresh and beautiful day. We can directly convert the original PS
Interface, and then driven by an independent scripting language to quickly respond to user needs. This entire independent part is left
Other layers (such as B/S's s side, or U/C/S's c side) can be just an interface, or even purely abstract, unimplemented
Current.

Review the entire process, we emphasize the importance of UI independence, emphasize the interface description brought about by HTML + CSS, And the VCL
What is the difference in the visual aspect? Does this indicate that rad is dead? Not all, it can indicate that "the interface-Based Visual rad productization technology is dead ".
I must emphasize this in this section to show that there is no necessary, direct, and strong association between the death of VCL and the death of rad.
. In my opinion on the death of rad, VCL is just an introduction, not a credential.

However, opening up a new field from UI separation is like opening a phrase in the era of RAD tools. It shows a new mode.
The emergence of a new system, system, and framework splitting model has emerged. In this new era, the field has gradually become clearer,
Mature, we must face this era: the post-rad era. Its main features are: RAD tools, methods, and processes.
In, the responsibilities of relevant fields are gradually clarified, the dependencies between domain tools gradually become smaller, and the boundaries become clearer. To "integration between fields"
Replacing the rad tool to unify the development process.

Like the bricklayer knife and the woodworking plane, they can work in the same system. The key lies not in the homogeneity of tools, but in the maturity of the field.

Next section --->