Can you develop a mobile phone UI with Flash?
In this post, I try to show that it is not possible to fully develop a phone's UI with Macromedia Flash.
Can you fully develop a mobile phone UI with Flash? It's a question that manufacturers and designers often ask these days. I have been struggling with that one for some time. So let's give it a try.
Today, most manufacturers develop their UI directly in C, using widget components (a widget is a small piece of code that can be reused). But UI are becoming more complex to develop and can have many variations (see for instance Vodafone 3G phones and more recent VS1 & VS2), so this takes more and more time and resources; new approaches are needed.
Macromedia Flash is basically a way to create sophisticated graphics on a screen. It is based on a model that separates a file, describing the graphic result to produce, and a graphic engine that reads the file to execute it. The file itself is produced with an authoring tool such as FlashMX that now includes a mobile version of Flash. The good thing is that Flash does not just produce monolithic animations (a nice movie), but allows the creation of interactive graphics with objects such as buttons, menus, etc... and can also include scripting to handle actions from the "external world".
Does that feature make it a good candidate as the fundation of a phone's UI? I don't think so.
Every development tool is based on a model that offers a level of abstraction and a conceptual representation of the reality to describe. To answer this question, therefore, is to confront the model and the reality (ie. the requirements of the job to be done).
The conceptual representation with Flash is that of animated vector graphics. The model is the description of the screen with basic elements that are graphic objects. Flash is what I would call an universal model in the sense that its ambition is to do 100% of the job; it does that in a
graphic centric manner. In addition, Flash is a high-level model in the sense that it proposes a high level of abstraction (graphic concepts) as opposed to C for instance.
But it is very difficult (meaning costly and inefficient) in Flash to "escape" from the model if some function can not be implemented with the basic offer. Of course, Flash can be scripted and extended by external libraries, but trying to do things that are natively handled by the model may lead to a large bulk of script code: is the original model still useful then ? To take an analogy: you can go from London to Heathrow by metro and then take a plane to Dublin, and still claim you went from London to Dublin by metro.
My sense is that on a PC as well as on the mobile phones, Flash is the perfect tool to create stand-alone "cartoon-centric" applications but one should not believe that the easyness to create the graphic part is still there to implement a complex application logic.
Why so? I can think of a few differences
- First, on the Web, the "UI" is only a window onto a functionally limited world. However sophisticated, a Web site is always a subset of the total available features of the PC platform. It is used to interactively exchange information between the user and the external world. On a mobile phone, the objective of the UI is different. It is used to represent the complete platform with all its functions. To give a try at technospeak, I would say that on the Web, the job to be done is more limited horizontally than on a mobile phone.
- Second, the Web works with a sand box, in an extremely confined environment, with minimal interaction with the underlying platform. The job to be done is limited vertically. On a mobile phone, however, the situation is different. The very purpose of the UI is to integrate to the underlying stack and platform; the successul integration is key to the overall performance. A fully integrated mobile phone software may always be seen as a kind of "big and monolithic" application that needs to be reliable, maintainable and that must be developped by large and multidisciplinary teams. In that sense, the UI is the visible part of an iceberg that cannot be easily splitted.
- Third, in the past, the UI was specified by the developing team: it was code centric. Today, modern UIs are more and more specified by the telcos and the marketing team. Their culture is a graphic culture and they define the applications in a graphic centric manner. Even if the temptation is high to consider that the graphic part of the software is ruling: this is not compatible with the reality of the phone's internals.
When the job is both horizontally and vertically limited, a universal and high-level model can work, because the universe is finite, which makes it easy to know whether the model will apply or not. So indeed you can perfectly develop the client side of a full Web site with Flash and be happy with it.
On a mobile phone, the job is not limited, either horizontally or vertically: the UI must represent all the phone's functions, and be tightly integrated to the platform. At some point, the high-level universal approach loses its efficiency as each step become more costly to implement as the
model is stretched further. You don't actually go to Dublin by metro. What happens is that the part actually written in Flash will be overwhelmed by scripts to "patch" the limitations of the model. Any universal model will reach inefficiency at certain point, and with Flash it will be when one wants to go beyond the purely graphic parts of the UI. This has been confirmed by some mokups made by manufacturers and research centers (see IBM)
This is a problem of course, because the era of programming UI purely in C, a low-level universal model, is more or less over. But one thing is clear: the UI cannot be programmed only with a high-level universal model; that, by the way, means that pure XML-based alternatives are a dead-end I think.
So there are three solutions:
Can you fully develop a mobile phone UI with Flash? It's a question that manufacturers and designers often ask these days. I have been struggling with that one for some time. So let's give it a try.
Today, most manufacturers develop their UI directly in C, using widget components (a widget is a small piece of code that can be reused). But UI are becoming more complex to develop and can have many variations (see for instance Vodafone 3G phones and more recent VS1 & VS2), so this takes more and more time and resources; new approaches are needed.
Macromedia Flash is basically a way to create sophisticated graphics on a screen. It is based on a model that separates a file, describing the graphic result to produce, and a graphic engine that reads the file to execute it. The file itself is produced with an authoring tool such as FlashMX that now includes a mobile version of Flash. The good thing is that Flash does not just produce monolithic animations (a nice movie), but allows the creation of interactive graphics with objects such as buttons, menus, etc... and can also include scripting to handle actions from the "external world".
Does that feature make it a good candidate as the fundation of a phone's UI? I don't think so.
Every development tool is based on a model that offers a level of abstraction and a conceptual representation of the reality to describe. To answer this question, therefore, is to confront the model and the reality (ie. the requirements of the job to be done).
The conceptual representation with Flash is that of animated vector graphics. The model is the description of the screen with basic elements that are graphic objects. Flash is what I would call an universal model in the sense that its ambition is to do 100% of the job; it does that in a
graphic centric manner. In addition, Flash is a high-level model in the sense that it proposes a high level of abstraction (graphic concepts) as opposed to C for instance.
But it is very difficult (meaning costly and inefficient) in Flash to "escape" from the model if some function can not be implemented with the basic offer. Of course, Flash can be scripted and extended by external libraries, but trying to do things that are natively handled by the model may lead to a large bulk of script code: is the original model still useful then ? To take an analogy: you can go from London to Heathrow by metro and then take a plane to Dublin, and still claim you went from London to Dublin by metro.
My sense is that on a PC as well as on the mobile phones, Flash is the perfect tool to create stand-alone "cartoon-centric" applications but one should not believe that the easyness to create the graphic part is still there to implement a complex application logic.
Why so? I can think of a few differences
- First, on the Web, the "UI" is only a window onto a functionally limited world. However sophisticated, a Web site is always a subset of the total available features of the PC platform. It is used to interactively exchange information between the user and the external world. On a mobile phone, the objective of the UI is different. It is used to represent the complete platform with all its functions. To give a try at technospeak, I would say that on the Web, the job to be done is more limited horizontally than on a mobile phone.
- Second, the Web works with a sand box, in an extremely confined environment, with minimal interaction with the underlying platform. The job to be done is limited vertically. On a mobile phone, however, the situation is different. The very purpose of the UI is to integrate to the underlying stack and platform; the successul integration is key to the overall performance. A fully integrated mobile phone software may always be seen as a kind of "big and monolithic" application that needs to be reliable, maintainable and that must be developped by large and multidisciplinary teams. In that sense, the UI is the visible part of an iceberg that cannot be easily splitted.
- Third, in the past, the UI was specified by the developing team: it was code centric. Today, modern UIs are more and more specified by the telcos and the marketing team. Their culture is a graphic culture and they define the applications in a graphic centric manner. Even if the temptation is high to consider that the graphic part of the software is ruling: this is not compatible with the reality of the phone's internals.
When the job is both horizontally and vertically limited, a universal and high-level model can work, because the universe is finite, which makes it easy to know whether the model will apply or not. So indeed you can perfectly develop the client side of a full Web site with Flash and be happy with it.
On a mobile phone, the job is not limited, either horizontally or vertically: the UI must represent all the phone's functions, and be tightly integrated to the platform. At some point, the high-level universal approach loses its efficiency as each step become more costly to implement as the
model is stretched further. You don't actually go to Dublin by metro. What happens is that the part actually written in Flash will be overwhelmed by scripts to "patch" the limitations of the model. Any universal model will reach inefficiency at certain point, and with Flash it will be when one wants to go beyond the purely graphic parts of the UI. This has been confirmed by some mokups made by manufacturers and research centers (see IBM)
This is a problem of course, because the era of programming UI purely in C, a low-level universal model, is more or less over. But one thing is clear: the UI cannot be programmed only with a high-level universal model; that, by the way, means that pure XML-based alternatives are a dead-end I think.
So there are three solutions:
- You use a universal, but low level model for the UI layer: this means reverting to pure C programming, not much future in this.
- You use C for the UI layer but implement high-level models for limited jobs (vector graphics, MP3, etc.) With this approach, Flash is used as a vector graphic component part of the overall UI layer. This is the common approach today, and it remains costly: programming is still in C and integration of components is costly.
- You find a high-level meta-model that is able to combine high-level (Flash players) and low-level components (C code)
posted by BB | Permanent link
0 Comments:
Post a Comment
<< Home